> -----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]
