munged together from multiple posts... > 1) The development of the XSLT will be done by whom? > Normally you want to separate the presentation from > the development. XSLT is a very strong tool but can > be considered almost a programming language. So you > either teach web designer's XSLT, or you have a > programmer convert the HTML into XSLT. Tools are on > the way which should help solve this issue.
i have never used XSLT in a production environment, just played with it, so all opinions below should be taken into that context... 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? with XSLT you just hand them the schema that all of the data will be generated against and they decide how the actual display will look. i would much rather teach my designers simple transformations than worry constantly about whether they ate my tags containing my java code. > 2) Performance. XSLT is interrupted, and is executed > each time. It is my understanding that there is an > initiative underway to create compiled XSLT (I believe > they are called translets, but I've not kept in touch > with that arena). > > Neither of these answer the "can you" question. They > address the "should you today" question. I am not say > don't do it. Just be aware. ... > We've found that XSLT works very well when your primary > objective is to deliver static content (flat files, or > cache-able catalog-like non-changing stuff) to different > clients requiring different formats. > > When the content is dynamic (read from a database in > response to a request and bean-ified for presentation), > then using XSLT to further transform that data degrades > performance too much. You're better off using straight > Java to do the transformations at the point of > "beanification". where are ya'll doing the transformations - server or client side? my take on xml and xslt vs. jsp vs. cocoon is on the order of... 1) xml is a text document 2) cocoon is essentially xml with java code which is 3) similar to what a jsp is (html with java code). but... 4) jsp's don't have to be inside of an html file, they can be inside of any text file... 5) and since xml is text... 6) you can create a jsp that is xml with java code in it... 7) that references a stylesheet... 8) that is downloaded by the client app... 9) which does the transformation so the server isn't over- loaded with the transformations. am i missing something? is this an overly simplistic view of life? or an overly complex one? rjsjr tgif - it's only 4pm CDT so i haven't hit the good stuff yet but a nice, cold Big Red will tide me over until a dinner of cabrito and negra modelo rolls around... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
