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