Cart
[Home] [By Thread] [By Date] [Recent Entries]
This is an interesting question. I worked on a similar project where we had to make a similar choice between JSP/Servlet versus XSL. Once you go over the learning curve of understanding the nuances of XSL, writing stylesheet felt natural and "right" thing to do from a programming perspective. It definitely was less number of lines of code. I didn't run any benchmarks, but I would venture to say that XSL solution will be better performing than JSP's. I guess, I have faith in several optimizations build into transformers.(open to comments, otherwise). While writing XSL, it almost reminded me of how I had to make choices between whipping out 4 lines of perl code versus designing a set of java classes to solve a problem. It was clear that perl code was more like "write only" (it was faster to write a new perl script, then try to understand and debug somebody's old script) and hence, java solution was the right thing from software maintainability perspective. However, in the case of XSL versus JSP/Servlet, its hard to argue one is more maintainable than the other. I would say it depends on the skill levels on the project. Having said that, debugging tools for java world are quite mature compared to XSL. As Mike suggested, would love to hear from more people who were in same boat and the choices they made. --Naren -----Original Message----- From: Leigh Dodds [mailto:ldodds@i...] Sent: Thursday, March 07, 2002 7:02 AM To: Mike Champion; xml-dev@l... Subject: RE: JSP or XSL? > ... > JSP seems to me like roughly the same design pattern as XSLT: you > start with a template and fill in the empty spaces by with some code > (procedural in JSP, declarative in XSLT)... I don't think it's as clear cut as that. If you write JSPs that consist of great chunks of Java code then you're not really taking best advantage of the technology. Once you move into producing JSP tag libraries, then your JSPs can become much more declarative -- at least from the perspective of the tag library user. The dirty code used to implement those tags is nicely hidden as it should be. And as it is in the implementation of an XSLT engine. There's a nice developerWorks article on this: http://www-106.ibm.com/developerworks/library/j-jsptags.html?n-j-12131 > I would be very interested in seeing a few non-trivial problems of this > sort being addressed both ways, with the solutions shared/critiqued, > so that we can all get a better handle on the guidelines for when a > JSP (or ASP, or PHP, or "DOM code filling in an XML template") approach is > more effective, and when a pure XSLT approach is more effective. > Has anyone done something like this before? Sounds like another decision tree Mike! :) Some things to consider: - who is authoring your JSP pages? If it's a web developer, give them declarative tag libraries, not chunks of code. If you're just spitting out XML for later processing, then maybe tag libraries aren't such a strong requirement. But even so you get benefits from reuse. Cocoon XSP is used in this way. It's for data generation, rather than presentation. - what are your JSP pages doing? Design patterns for web architectures [1] suggest that the shouldn't be doing more than presentation tasks, i.e. implementing the View of an MVC architecture. JSP pages are basically Template views [2]. XSLT is a Transform [3] View. - where does the data come from? Is it being pulled into a template, or pushed in from outside? If all the data is presented to the page, and it merely formats it then that's a push approach. The page is then coupled to the data generator which has to provide all required data. If data is pulled in as required, then that's the opposite. There's less coupling (just location, and format). In reality a mixture of the two is likely. Cheers, L. [1]. http://www.martinfowler.com/isa/index.html [2]. http://www.martinfowler.com/isa/serverPage.html [3]. http://www.martinfowler.com/isa/transformView.html ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
