Hi All,
Seems a bit of the "silver bullet" scenario is going in the discussion of
XSLT versus Struts approach, someone has correctly said "there's no silver
bullet".
You are required to use your judgement based on your experience on which
tool/technique to use for what situation for optimal results. Again I don't
claim to know all but here' my 2 cents on some of these off the top of my head:-
XML/XSLT
Pros
----
i. Multiple rendering formats for multiple channels/devices.
HTML/WML/...
Cons
----
i. Usually very slow for complex page with lot of transformations
Struts
Pros
-----
a. Cleaning up very complex navigations into more manageable and
maintainable structure.
Cons
----
a. It's in bed with JSP rendering, and lot of the add-ons can't be
utilized generically such as in the case of XMS/XSLT
Again technologies tend to evolve over time, just like Servlets was the
"thing to do" when all you had was CGI, and Struts improvised on Servlets to
make the hard wiring and navigation of the controller servlet into more
managable XML configuration. And now there's JSF/Shales/Spring Framework and
God knows what else... so take your pick and mix and match for best results!
There no silver bullet is what I'll still say... with time everything changes.
Regards,
Dharmendra
ps: have a good day!
-----Original Message-----
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 18, 2005 4:28 PM
To: 'Struts Users Mailing List'
Subject: AW: Struts with XSLT
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 18. August 2005 22:11
> An: Struts Users Mailing List
> Betreff: Re: Struts with XSLT
> Ever heard of translets? But even if you call XSLT processor
> for every request, I D-O-N'T C-A-R-E. This is not a software
> problem, this is a hardware problem. And even expensive
> hardware in the end of the day comes cheaper than money spent
> for software workarounds. Your experience with zillions of
> concurrent customers may tell you different things, I try to
> respect that ;)
Well, there are actually some hardware requirements, like max. amount of RAM
you can use effectively on linux and so on.
But, by the way, who said, the software development with XSLT/XML is faster
then with JSP/JAVA-Objects? I highly doubt it :-)
>
> > > Keep it if it works. Don't forget that modern browsers can accept
> > > XML and have built-in XSLT processor. So, you can send your
> > > serialized bean data as XML with linked XSLT stylesheet
> with linked
> > > CSS stylesheet.
> >
> > Now this is an urban legend :-) Each browser support it
> it's own way.
> > Not to mention each version of the redmond browser supports ist own
> > extensions. None of them are compatible.
>
> Umm, MSXML or whatever it was called, has an old XSLT implementation.
> MSIE 6.0 XSLT processor is much better. And it is around for
> 5 years, so customers with MSIE less than version 6 should be
> simply not supported. Heck, they probably already have bought
> a new car since they installed MSIE 5. Now it is time to
> change oil in their computer too.
I'm not even sure, that 6.0 sp1 and 6.0 sp2 have the same xslt processor. My
experience with microsoft tells me, that 7.0 will differ. Not to mention
mozilla and opera. And what about the coming google browser?
>
> > > > * Perhaps it's still a little early to say exactly how
> > > Struts 2.x will
> > > > turn out but will the idea of view technology independence
> > > be maintained?
> > > > * If Struts 2.x doesn't (essentiall) force us to use
> > > something akin to
> > > > JSF will XSLT still be a viable option?
> > >
> > > You can do it in Struts 1.x too. Instead of forwarding to
> JSP page
> > > just stick XML (or XML/XSLT already processed into HTML) into
> > > response object and return null from an Action class.
> > > Apparently, you would use ActionForm for input only with request
> > > scope, and store your app data somewhere in the session or in
> > > database.
> >
> > Actually it's better to write out the dom object (if you
> have one, but
> > you should, if you seriously want xslt/xml).
> > I would also look into rendering with SAX, it could
> probably give you
> > 40-50% more performance then dom rendering.
>
> Did not quite get that. If you want to work directly with
> DOM, then you probably need to return XML, that is what Ajax
> components usually do. If you return server-side-processed
> HTML, then what DOM are you talking about? Well yes, browser
> will create DOM based on HTML received, but you do not alter
> DOM *directly* from server.
>
> Oh, you did not mean browser DOM? You meant to return XML
> containg app data from server-side DOM? Then how does that
> correlate with your dismissal of client-side XSLT processing?
I must have misunderstand what i read, mea culpa :-)
But funny things, with resin, a jsp which is rendering xml is faster then
xml written out by servlet, which is faster then xml written out by the
action (The JSPWriter in resin is highly optimized). What i ment with DOM,
was not "writing xml" somehow, but leting your business logic return
dom-objects instead of "whatever-we-might-call-it" normal java objects. On
the other hand, it would mean transmitting overhead on the net between
webserver and business logic. But if you use an XML DB on the other hand...
Ok, let's say, you have to test it out :-)
> Also, try StAX. I have not run any perfomance tests myself,
> but they say it is faster than SAX. At least, not slower. And
> is easier to use.
> Get one from Sun's JSWDP 1.6, don't use JSWDP 1.5, it
> contains a serious parsing bug. Had a problem and it took a
> while to realise that it had been in fact not my fault this time ;)
Notched, thanx.
>
> Michael.
>
Leon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
