I aggree that it's very difficult to debug and is non-portable, but our experience was that we could never find a server environment with adequate performance. The performance issue outweighed the portability and support issues for us. Of course, we're talking about an intranet application where we had pretty good control over the browser environment. That's the only case I would recommend that.
Greg > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 14, 2002 9:40 AM > To: Struts Users Mailing List > Subject: RE: xml-xslt v jsp > > > > > > Client-side is non-portable and leads to tailoring the app to > a particular > browser-implementation. In addition, bugs are virtually impossible to > recreate since you have no control over the client environment. > > Keep it server-side. > > > > > > "Tandon, Pankaj" <[EMAIL PROTECTED]> on > 05/14/2002 10:42:41 AM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > 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]> > > > > > > > > -------------------------------------------------------------- > ------------- > This e-mail message (including attachments, if any) is > intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential > and exempt from > disclosure. If you are not the intended recipient, you are > notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication > in error, > please notify the sender and erase this e-mail message immediately. > -------------------------------------------------------------- > ------------- > > > -- > 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]>
