|Graham Smith||Aug 18, 2005 7:12 am|
|Don Brown||Aug 18, 2005 8:01 am|
|Graham Smith||Aug 18, 2005 8:31 am|
|Craig McClanahan||Aug 18, 2005 9:31 am|
|Mark Benussi||Aug 18, 2005 9:36 am|
|John Martyniak||Aug 18, 2005 12:07 pm|
|Michael Jouravlev||Aug 18, 2005 12:32 pm|
|Graham Smith||Aug 18, 2005 12:42 pm|
|Leon Rosenberg||Aug 18, 2005 12:44 pm|
|Leon Rosenberg||Aug 18, 2005 12:52 pm|
|Graham Smith||Aug 18, 2005 1:05 pm|
|Michael Jouravlev||Aug 18, 2005 1:10 pm|
|Luiz Godoy||Aug 18, 2005 1:21 pm|
|Leon Rosenberg||Aug 18, 2005 1:27 pm|
|Eduardo Ribeiro da Silva||Aug 18, 2005 1:32 pm|
|Dhar...@ubs.com||Aug 18, 2005 2:10 pm|
|Peter Maas||Aug 18, 2005 10:41 pm|
|Mitchell, Steven C||Aug 19, 2005 5:29 am|
|Craig McClanahan||Aug 19, 2005 2:52 pm|
|Subject:||AW: Struts with XSLT|
|From:||Leon Rosenberg (stru...@anotheria.net)|
|Date:||Aug 18, 2005 1:27:21 pm|
-----Ursprüngliche Nachricht----- Von: Michael Jouravlev [mailto:jmi...@gmail.com] 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 ;)