Someone else could probably do a better job than me, but... 1) If transforms are done on the client, processing is distributed. The server does not have to process transformations for all of the concurrently connected clients. DOM processing takes a lot of memory and overall application performance improves if that processing is distributed to client machines. In practice, transforms that took several seconds using Xalan running under Tomcat were instantaneous in MSXML running in IE on the same box.
2) Your server already has to be a workhorse because you are taking data from Java objects and building an XML document from them. XSLT just adds another layer of processing to the same data. If that processing can be pushed off to the client, server resources are freed up. In our experience we found that performance was dramatically affected as concurrent users were added. The same type of system performed much better under JSP. There was simply less processing involved. > -----Original Message----- > From: Tandon, Pankaj [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 14, 2002 9:43 AM > To: 'Struts Users Mailing List' > Subject: RE: xml-xslt v jsp > > > Can you please explain WHY server side XSL transforms shd be more of a > performance (resource) hog than client side? > > Thanks > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 14, 2002 10:36 AM > To: [EMAIL PROTECTED] > Subject: RE: xml-xslt v jsp > > > > isn't teaching a designer XSLT to modify a schema into > > HTML easier than teaching them to not break your java > > code inside of a jsp? > > > No, it's not. XSLT *is* a programming language and you have to know > XPath to really do anything practical with XSLT. I would never try to > teach designers XSLT (who define "programming" as doing cool > stuff with > DHTML) That is not to say that they are stupid. They have their own > area of expertise in an area in which I cannot perform. XSLT > is geared > to a programmer's mindset. You have loops, conditionals, etc. If > designers ever look at source code, they will recognize Java > because it > looks similar to JavaScript. If they're not proficient with it, they > will leave it alone. XSLT will be a whole new world for them. > > Now, I would argue that if you have Java code in your JSP, you should > try to get it out using tags. The cases when Java code is in the JSP > should be rare. A well-designed tag library will be much easier to > train designers to work around than XSLT. > > > i would much rather teach my designers simple > > transformations than worry constantly about whether they > > ate my tags containing my java code. > > > Simple transformations are few and far between in my experience. XSLT > is a great language. But it is not simple, not nearly as simple as a > well-designed JSP tag, IMHO. > > > where are ya'll doing the transformations - server or > > client side? > > > I've done both. It's been a year or so, but server-side > transformations > were dogs for performance. Client-side works fine, but you have to be > able to control the browser. For IE, you have to make sure > the user has > the right version of MSXML installed. For Netscape, can Netscape do > XSLT at all? Seems like version 6 can, but I don't know. > Bottom line. > If you use XSLT you will have to address performance issues. > > Greg > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
