On 8/18/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > > * Should I just stop fighting city hall and abandon XSLT in > > favour of JSP? > > Yes :-) Really. We did it a year ago, and gained A LOT of performance. Not > to mention that XSLT > is much less powerful then jsp (custom tags, etc). At least as long, as you > are using an existing renderer.
Examples? Custom tags, you say? Parameterised templates are at least no worse. Also, XSLT can be used with any host system, be it Java or .NET. Portability, is what this is called? ;) > > No. XML/XSLT is more flexible than JSP and has been supported > > bunch of other markup tecnhologies like XML, XHTML and XPath > > for a long time. > > And are very much slower to. 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 ;) > > 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. > > > * 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? 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 ;) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
