The Best of Both Worlds: Integrating JSP/JSF and XML/XSLT

Discussions

News: The Best of Both Worlds: Integrating JSP/JSF and XML/XSLT

  1. This article shows how JSP and XML technologies can be used together to build elegant and scalable applications. With milestones such as JSP 1.1, Struts 1.0 and JSTL 1.0, server-side Java technology has progressively evolved; the article looks at this evolution and then examines Model 2X, which combines JSP and XML processing to improve the flexibility of the presentation layer.

    Read 'Integrating JSP/JSF and XML/XSLT: The Best of Both Worlds'

    Threaded Messages (54)

  2. XSLT performance[ Go to top ]

    And what do you think about XSLT performance ?

    Dmitry Namiot
    Coldbeans
  3. XSLT performance[ Go to top ]

    And what do you (Dmitry Namiot) think about XSLT performance ?
  4. XSLT performance[ Go to top ]

    Without the special tricks (cache, design) it is a big pain.
    So at the end of the day the complexity for your system can even grow.


    Dmitry Namiot
    Coldbeans
  5. Thorough info on XSLT performance[ Go to top ]

    It would be interesting to be able to compare various XSLT suites, with different JDKs, and even items like XSLTC.

    Hopefully we can good feedback from folks that have used XSLT (please don't just say "it is slow" ;)
  6. XSLT performance[ Go to top ]

    In one of my projects, I used XSLT transformations to generate HTML. I used the SAXTransformerFactory.FEATURE of the transformation engine. This feature enables a transformation engine to behave like a Content Handler of a SAX parser. Anyway, I first converted my JavaBeans to XML in such a way that instead of building a DOM from my JavaBeans, every element fired an event and the event was handeled by the transformation engine. I also kept all my compiled XSL stylesheets in a cache and used them in an pipeline aproach. The result was satisfactory in terms of performance. For small transformations it took 50-75 ms. (I was using Saxon 6.5.)

    But it was a killer for very big documents like 7Mb documents. For that kind of transfromations it took 100-120 seconds :-( Then I tested the transformation performance with MSXML 4.0 (msxsl.exe) and it took < 7sec. It was huge a difference. Since I was already passing the XMl doc to a Web Service to generate Excel files, executing the transformation also on the MS site was a huge gain.

    Last but not the least, performance of XSLT depends heavily on your XSL sytlesheets as stated in this thread.

    Thanks,

    Mustafa.
  7. I don't think we need to worry[ Go to top ]

    This site: http://upl.codeq.info
    makes an XSLT transform of a ~200K large XML document to HTML.

    The transform itself takes about 250 ms on a dual P3 600 MHz with 1/2 gig of ram (not the same as the hosting server).

    It is about 1/3 of the overall time response time for the server. Just using plain vanilla Xalan. Sure, 1/3 of the overall time is a lot, but what is the alternative? How much time would that take?
  8. throughput calculation[ Go to top ]

    Mats: "This site: http://upl.codeq.info
    makes an XSLT transform of a ~200K large XML document to HTML. The transform itself takes about 250 ms on a dual P3 600 MHz with 1/2 gig of ram (not the same as the hosting server)."

    FWIW - XSLT is typically single-threaded and 100% CPU-bound (including memory bus). If it takes 250ms, that means it will process 8 pages per second (2 CPUs x (1 second * (1000 millis / second) / 250 millis)). If think time is 10 seconds, that application will support less than 80 concurrent users (probably 60 in reality) ... on a dual CPU server. Not very good.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  9. True, but perfect for intranet apps[ Go to top ]

    True, however 60-80 concurrent users might be perfectly acceptable for intranet applications where flexibility, ease of maintenance, and speed of development might be more important. The complete separation of the presentation layer allows for the same app to easily be skinned, integrated into a portal, or serve html, wml, etc clients simultaneously. It also allows the web designers and programmers to easily work simultaneously and makes it easy for future integration requirements (the system could return xml in a certain schema to be used by another application - a poor man's web service).

    Again, not for everyone, but it does have quite a few advantages.

    Don
  10. The complete separation of the presentation layer allows

    >for the same app to easily be skinned, integrated into a
    >portal, or serve html, wml, etc clients simultaneously.

    Different devices need a different information architecture.
    You will not want to browse Theserverside.com on your
    mobile phone or a pda with its limited resolution the same
    way, like with a web-browser.
    There is no simple way of defining different xslt transformations for different devices that the content will
    be easy to navigate and look great.

    For a good user experience, its more like re-designing the
    whole applications ui. I doubt, that xslt will help you
    that much with that.

    Additionally you need completely different skill sets to
    turn static HTML pages into JSPs than for transforming
    XML via XSLT in HTML. The first is possible for an above
    web designer or average programmer.

    Third, i would like someone to show me some well
    structured XSLT which makes use of concepts like
    modularization or reuse and is easy to read and
    understand instead of the usual tricky XSLT spaghetti
    code...

    Thomas
  11. 1) Needs different skillset - Not true, we have been using XSLT for over 3 years and all our programmers picked it up in days, given Michael Kays book and examples from our own site of how we did things its really trivial to pick it up in the right enviroment

    2) Modularisation is achieved by creating templates which are in some cases the equivalent of JSP tags then these are included and called from the main XSLT template

    I would say that in general we layout our main XSLT templates in a procedural style which I personally have found the easiest to read and for other programmers or web designers to pick up.
  12. Perhaps I should have described XSLT has providing better support for other presentation formats, rather than giving the impression it would do everything perfectly. Of course it can't. However, it is easier to provide limited support for even something like a PDA than using many other presentation technologies. You don't have to worry about business logic in the presentation layer, you have the ability to serve up pure xml to allow you to build other applications on top of it in the future that can reuse the legacy code, and you can easily support similiar formats like one as a portlet and another as a text-only view.

    As for the ease of use of XSLT, I haven't noticed any problems. However, a well-designed application puts very little work on the XSLT's so much of the XSLT spec should not be necessary. As for modularity, this is one of the strengths of XSLT. Using imports, includes, and the ability to call templates with parameters (a bit verbose I admit), allows you to reuse code very easily.

    Again, no silver bullet, but my point is for intranet development that requires flexibility and expects the app to be used in ways not conceived during development, XSLT is a good match.

    Don
  13. The complete separation of the presentation layer allows for the

    > > same app to easily be skinned, integrated into a portal, or serve
    > > html, wml, etc clients simultaneously.
    >
    > For a good user experience, its more like re-designing the whole
    > applications ui. I doubt, that xslt will help you that much with
    > that.

    You are right that in some cases, especially when you are targetting devices as different as a desktop Web browser and a WAP phone, the application flow is very likely to be different. In many cases though, it will be the same or very similar. For example, generating HTML pages for desktop and PDA browsers. The main difference is not going to be the flow, but the screen real estate and the version of HTML generated. XSLT is perfect here.

    This also applies to changing the look and feel. In the real world, demanding customers constantly want changes. You may also want to brand an application that you are reselling to many customers. Doing so with JSP is going to involve days or weeks of work (been there, done that), and more likely will be proportional to the number of pages. With XSLT, I can create a new L&F in a couple of hours, and this independently from the size of the application. I can even switch at runtime.

    > Additionally you need completely different skill sets to turn static
    > HTML pages into JSPs than for transforming XML via XSLT in HTML. The
    > first is possible for an above web designer or average programmer.

    This is simply not true. You can use XSLT like you use JSP: simply copy your HTML into the XSLT template and make sure it is well-formed XML. Then, instead of scripting with Java or JSTL, script with XSLT (and don't tell me that an average Web designer can do much JSP).

    Also, look at this code sample from the article:

    <c:forEach items="${tableData.data}" var="currentData" varStatus="status">
        <c:set var="cellColor">
          <c:choose>
            <c:when test="${status.index % 2 == 0}">gray</c:when>
            <c:otherwise>white</c:otherwise>
          </c:choose>
        </c:set>
        <tr>
          <td bgcolor="${cellColor}">
            ${status.index}
          </td>
          <td bgcolor="${cellColor}">
            ${currentData}
          </td>
        </tr>
      </c:forEach>

    Looks much like XSLT, right? Well, this is in fact modern JSP. The difference? On the surface, pretty much none.

    > Third, i would like someone to show me some well structured XSLT
    > which makes use of concepts like modularization or reuse and is easy
    > to read and understand instead of the usual tricky XSLT spaghetti
    > code...

    Here you have a very good point. The answer is that in order to achieve true modularization with XSLT, includes, imports and the document() function are not enough. What you need are pipelines. This allows you to implement your presentation layer in an AOP / interceptor pattern way.

    The lack of a standard pipeline definition language is a huge void in the XML world. Cocoon has its own, but it is very limited. The W3C has a note about a pipeline definition language, but it is very incomplete. We think that with our XPL, we have what could be a good starting point for a standard. See our white paper about XML pipelines for more information:

      http://www.orbeon.com/oxf/whitepaper

    -Erik
  14. We use Oracles XDK.
    In our ++OWN++ benchmarks which are designed to only test what we need for our enviroment we find Oracle 3-5 times faster than Saxon and 10+times faster than Xalan/Xerces.

    We have used XML/XSLT for running a moderate volumne sight for the last 3 years and its works very well.

    Personally I feel most of the negative comments about XSLT poor performance are really related to poor (Xerces) implementations rather than fundementally an issue with XSLT.

    And although I dont really want to get into what the benchmarks really show as they are not a one size fits all type but we would see times for a typical very large page on a single processor Windows2K server as under 50ms and a typical web page could be about 4x faster
    Based on your calcs that 300-1200 concurrent users based on the "in reality" figure.
    Rob
  15. Oracle XDK[ Go to top ]

    "We use Oracles XDK."

    We wanted to as well, but despite what the marketing blurb says, it is an incomplete implementation of the 1.0 XSLT spec. (As you say, you only tested the bits you were using).

    For one, the show stopper for us, it doesn't support the document() function, so you can't feed in any secondary XML data streams.

    Saxon gives a much better trade off in terms of performance and functionality IMHO.
  16. Oracle XDK[ Go to top ]

    Sorry but disagree, it DOES support the document function, just picking of my desktop an xsl used in handling database schemas I find this ---
    <xsl:variable name="tablename" select="document(concat(concat(concat($properties/schema-directory,'/'),@name),'.sch.xml'))"/>

    This xslt file actualyl iterates over a list of tablenames in the main xml document and for each one loads an xml file and transforms it and outputs to a separate xml file -- this is all from within the main xsl file.
  17. throughput calculation[ Go to top ]

    <Cameron>
    FWIW - XSLT is typically single-threaded and 100% CPU-bound (including memory bus). If it takes 250ms, that means it will process 8 pages per second (2 CPUs x (1 second * (1000 millis / second) / 250 millis)). If think time is 10 seconds, that application will support less than 80 concurrent users (probably 60 in reality) ... on a dual CPU server. Not very good.
    </Cameron>

    You beat me to the punch with your comments - I agree completely.

    As a general rant, I see a surprising number of developers (and salesmen :-) who quote performance in terms of one request or one user. It's equally important to say "how much CPU does this component take out of the box for 10/20/40/80/160/etc users" and "is there a single-threading resource bottleneck (internal to the code, or external resource) which will throttle the results for a large number of users?".

    To me - if you're going to choose an architecture, always benchmark it with a proof of concept test before you bet the bank on it. I see entirely too many applications where "it works fine on my little development machine (says the developer)", and then eats 4x100% CPU on a 4-way machine at 15 users for the first release.

    Going back to what someone said about databases taking 10s or 100s of millis - yes, but your database can probably sustain that response time over lots of users. In other words, your database will scale so that response times go up gradually (or not at all) when you add users. Whereas a heavy interpreter involved in serving requests in your web tier can easily pin the server CPU on a few requests.

        -Mike
  18. I'm wrapping up a project I based on Struts 1.0 and stxx 1.1 (http://sf.net/projects/stxx). I used XSLT for my presentation layer for a number of reasons and it preformed quite nicely. Most of the transformations take less than 50ms with a few larger pages taking <200ms. The keys are to cache the compiled templates in memory, keep the XML sizes down, and use well-designed XSL stylesheets (ie avoid "//", etc).

    Of course it does use a bit of memory to cache the XSLTs, CPU time for the processing, and is slower than other presentation solutions, but I think, at least in my case, the flexibility was worth it. I think where XSLT will be more attractive is in setting up XML pipelines (ala cocoon) to modularize the presentation layer in an almost AOPish way. This allows you to use technologies like JSP, Velocity, etc to generate the XML and let the pipeline handle its transformation.

    Its not for every project, probably not even half, but where performance isn't the most important, it works out quite well.

    Don
  19. Hi,

    I am looking for guidelines to use XSL. What is good practice for this technology?
  20. Re: XSLT performance[ Go to top ]

    Their performance sucks. I checked a PetStore demo and it takes forever to load a page. Well, it can be just a low end hardware it runs at though.
  21. Re: XSLT performance[ Go to top ]

    I do not recommend using the online demo as an XSLT, Model2X or OXF benchmark. Performance depends on the load of the server, the bandwidth available, and the performance of the machine. For better results, try on a machine you can control. Also, the examples have not been specifically tuned for performance (I know we've heard that from Sun in the past and that it was a bad excuse ;-).

    Feel free to install and play with the sample code that comes with the article to get your own feel for performance. The implementation is not particularly optimized, but you have the source and the implementation is lean and mean.

    -Erik
  22. XSLT performance[ Go to top ]

    The truth is that, performance-wise, it is hard to beat JSP and scriptlets. After all, JSP engines translate your code into Java, then compile it into bytecode. No interpretation really takes place after the first compilation.

    On the other hand, most XSLT transformers are interpreters. There are exceptions, like XSLTC, which is unfortunately not quite mature yet. Compilation is certainly the way of the future. For the time being, our experience shows that XSLT performance is quite acceptable. Transformations, on a regular machine, take in the range of a few 10s of ms to a few 100s of ms with the latest Xalan implementations, depending on the size of the documents. Using XSLTC will give you easily a factor 2 improvement.

    It is important to consider that the roundtrip to a database can take several 100s of ms, and that you may need several of those for a given page. Also important is the type of application you are targetting. Building a small Web app with 10 users does not have the same requirements as amazon.com.

    The bottom line is that XSLT does incur a performance hit. Whether that hit is acceptable depends on your thirst for flexibility, the type of aplication you are building, and how much time you spend in your backend. Making tradeoffs between performance and flexibility or reliability is something we all do, otherwise we would still program in assembly language, not Java ;-)

    -Erik
  23. XSLT performance[ Go to top ]

    Has anybody tried using XSLT to generate the JSP pages? The pages would only be generated whenever there is a change in layouts, etc. This would give a compromise between flexibility and performance.

    I have not tried it but am currently toying with the idea for a project. I already have had some good experience with doing something similar for source code.
  24. Using XSLT to generate the JSP pages[ Go to top ]

    Has anybody tried using XSLT to generate the JSP pages?


    Yes. Resin has done that for years with its XTP pages.

    The *.xtp page is transformed by a stylesheet into a *.jsp page. JSTL and the JSP 2.0 specs should make the process even cleaner, since you no longer need to generate Java code.

    You don't actually need Resin to use the XTP idea. An ant task that called an XSLT processor on an .xtp page to produce a .jsp page would do the same thing and would work with any JSP engine.
  25. Has anybody tried using XSLT to generate the JSP pages?


    Yes, I have made a resarch and mini framework, but didn't have a chance to use it in production.

    The idea of preprocessing with XSLT (to generate JSPs)
    instead of postprocessing is great. Put static page layout in XML JSP template (meta JSP page), process it with XSL stylesheet and generate JSP in XML format. Then let servlet container do the rest of a job.

    XML JSP template + XSL stylesheet -> JSP page in XML format -> Java Servlet source -> Java Servlet class

    This way you get the best of both worlds, JSP performance and XSL flexibility.

    Regards,
    Mileta
  26. Using XSLT to generate JSP certainly has many applications. The point of the article though, is that JSF tag libraries and renderers (like BTW the Struts html tag library) end up generating HTML from Java code. We've come all the way from servlets generating HTML to JSP 2.0 + JSTL, a relatively clean combination from a syntaxic point of view, and now with JSF we're back generating HTML from Java with all the problems that implies.

    Nobody knows whether JSF will take off, but once version 1.0 final of the spec is out, commercial and open-source implementations and components will start appearing, and a number of people will use them. I think this is going to be the case based on the past adoption record of Sun/JCP technologies. JSP, for example, was initially quite a flawed spec for anybody familiar with XML. But compare this with the adoption of non-Sun technologies like XSP (an XML-clean version of JSP, developed for the Cocoon project)...

    If JSF and the JSP practices advocated by Sun (Model 2, use of JSTL, no scriptlets, use of tag files, use of the expression language) get further adopted, people will use tag libraries generating code through Java renderers more and more. Producing JSPs with XSLT does not solve the rendering limitations of the tag library model.

    Now if you chose not to use tag libraries to generate code, JSP generation makes perfect sense.

    -Erik
  27. Eric,

    You are right that JSF and it's renderers can cause problems because they directly generate HTML (or other markup) code. But, if you restrict yourself to use only a set of common JSF controls (including of course more complex ones like trees and grids) it is not a very big issue, especialy if these controls can be styled with CSS.

    If you use just JSP and JSTL (and meybe XSLT to generate JSP pages) you do not have that problem.

    Regards,
    Mileta
  28. Cocoon?[ Go to top ]

    I'm amazed that Cocoon hasn't been metioned yet..
    http//xml.apache.org

    It has a lot of unneccessary features in my opinion, but we've used in several projects here and things have gone quite smoothly.

    -Mike
  29. Cocoon?[ Go to top ]

    From reading the cocoon-dev list, it looks like they are making efforts to reduce the size of the core of cocoon and move much of the code out into "blocks". Once they can get the required dependencies down to a reasonable size and someone can find a easier way to use it (ie integration with struts perhaps?), it will only become more popular.

    Don
  30. Cocoon?[ Go to top ]

    Cocoon integration with Struts would be great, I think that Cocoon will always be haunted by Struts. They both have their advantages and disadvantages. Struts wins with the Controller, Cocoon takes the cake with the View. Developers will always be more comfortable working with the plumbing, so Struts is winning, but my bet is that cocoon is soon to catch up!
    -Mike
  31. Cocoon?[ Go to top ]

    <Mike Joslyn>
    Cocoon integration with Struts would be great, I think that Cocoon will always be haunted by Struts. They both have their advantages and disadvantages. Struts wins with the Controller, Cocoon takes the cake with the View. Developers will always be more comfortable working with the plumbing, so Struts is winning, but my bet is that cocoon is soon to catch up!
    </Mike Joslyn>

    There have been talks on the Cocoon mailing-lists about this. I paste below my post on the subject (talk about reuse):

    Struts was designed to be an MVC (Model/View/Controller) framework based on Model 2 (a hybrid servlet/JSP architecture, as opposed to 100% servlet-based or 100% JSP-based architectures).

    This means that for each Web page, you write an action class (that implements the MVC model) and a JSP page (that implements the MVC view). The MVC controller is the configurable Struts controller, that you usually leave alone. The model and the view can be modified independently. If you define the interface between model and view correctly, which comes down to defining what JavaBeans the model sends to the JSP, you can achieve a very good separation of business logic and presentation logic. This is what Struts was designed for!

    About the business logic: using Struts has nothing to do at all with whether you use EJB or not. You can implement your business logic directly in Struts action classes if you want, or delegate to your business logic components, including session EJBs. Struts, like Cocoon, is mainly a presentation framework.

    About the presentation logic: Struts provides tag libraries that make it easier to write JSP pages (by the way, a lot of the concepts present in those tag libraries have made it into JSTL, the JSP Standard Tag Library, that makes much of the Struts tag libraries obsolete). But the fact is that you don't have to use JSP with Struts, you can use an XML-based presentation layer if you want. So yes, it makes sense to use at least a subset of Cocoon with Struts. You may want to leave dispatching, form handling, and the interaction with the business logic to Struts, and use Cocoon to implement flexible XML pipelines handling the look and feel, multiple device support, etc. You can even use a combination of both JSP and XML pipelines if you want. Have the JSP generate bare-bones HTML or XML, plug a Cocoon generator to parse the JSP output, and off you go.

    Why use Struts and Cocoon instead of using 100% Cocoon? Well, whether you like it or not, many people and companies use Struts. Its feature set is not too impressive, but the underlying architecture is conceptually sound. It is often easier to sell to your manager the use of Struts than the use of Cocoon. Also, you can incrementally add XML processing to an existing application instead of starting from scratch with Cocoon.

    -Erik
  32. Cocoon and Struts[ Go to top ]

    FWIW, I did write a plugin to stxx that integrated Cocoon and Struts. stxx generates the XML like it always does then passed the request over to cocoon to handle how it was sent back to the client using a special stxx generator that got the pipeline started (mainly to convert the JDOM document to JAXP otherwise I could have used an existing transformer to pull the DOM from the request).

    While this worked pretty well, there were a couple of issues:

    - Not everyone wants to take the stxx approach and manually create XML in their struts action and optionally have resources, errors, and request attributes/parameters serialized into XML

    - stxx reliance on JDOM

    - struts 1.1 doesn't allow multiple RequestProcessor's (i.e. you can't use tiles and stxx)

    I think it would be better to write a struts plugin that simply passes the request to cocoon and let cocoon generate the XML via its own methods. It would be nice to use the @path value from the <forward /> tag to somehow be passed to cocoon so it can use it in the pipeline. If a workaround for struts to chain RequestProcessors could be found, the integration would be very easy for the developer. One of these days, I'll hack something like that up.

    Don
  33. Cocoon?[ Go to top ]

    BTW, the article mentions Cocoon as a tool to implement XML pipelines, and there is a link to the Cocoon project in the references. For what it's worth, OXF was born in part due to frustrations we had with Cocoon.
  34. Stndards by W3.org[ Go to top ]

    I do no think Orbeon will set standards, but .... w3.org might.

    Here is a better, W3.org based aproach by a J2EE vendor applying a W3.org standard.

    novell.com/xforms.

    Note how using W3 Xforms (a new HTML forms tag) enables drag and drop of fields.
    Anyway, I think this is ahead of curve.
    .V
  35. Stndards by W3.org[ Go to top ]

    Then you will be happy to see that OXF supports XForms 1.0. See the following two links:

      http://www.orbeon.com/oxf/doc/processors-xforms
      http://www.orbeon.com/examples/xforms

    -Erik
  36. Stndards by W3.org[ Go to top ]

    Wed Feb 12 10:24:21 CET 2003
    http://www.orbeon.com/examples/xforms

    HTTP Status 500 - Internal Server Error
    root cause java.lang.OutOfMemoryError <>

    OK, let's say I haven't seen this one :)
  37. Stndards by W3.org[ Go to top ]

    Yes, Erik, I am happy!
    .V
  38. http://mav.sourceforge.net/

    Can anybody using Maverick give feedback? I'm looking for a framework for a new project.

    BTW, it'll be nice to have the price of the OXF framework on the web, unless you plan to charge different to different people. ;-(

    Also, the Apache server running Orbeon site needs more memory or sombody needs to fix memory parameters for the JVM. My guess probably is the latter ;-) OutOfMemory - no good :-)
  39. This is the danger of deploying a new Web site half a day before the article was posted... I hope you won't see those errors anymore.
  40. OXF pricing...[ Go to top ]

    Someone asked about OXF pricing.
    It is free for non-commercial use and $495/CPU otherwise.
    This information will be available on Orbeon's website before the end of the week. We are definitely not planning to charge a different price to different customers.

    Thanks.

    -Omar
  41. XSLT vs XForms[ Go to top ]

    Has anybody done anything non-trivial with XForms? It seems to take the next logical step from XSLT.
  42. If you really care about performance...[ Go to top ]

    Definitely cache your compiled templates, and only take the recompile hit when they're modified again.

    But server-side optimizations will only net you a tiny percentage of the possible performance improvements.

    The fundamental performance problem with frameworks like Struts and JSF is that they don't reach all the way down to the client--so your app server is processing and rendering far more pages than it should in the first place, and your users are waiting out a lot unnecessary round trips.

    Disclaimer: This is the problem we fix. :o)

    Jeff Dill
    Isomorphic Software
    www.smartclient.com
  43. JSP not necessary[ Go to top ]

    The original purpose of JSP was to generate HTML. When the output of xslt transformation can naturally be HTML, JSP would just add another layer of indirection. The simpler, the better for performance.

    Check out a prelimenary demo site below. It does not use JSP at all. The data shown as table or graphics are from relational databases.

    http://208.48.57.175/glstar

    The graphic is in SVG format, so that you would need the Adobe SVG viewer to see the beauty. Here is the link to their site for download of the viewer:
    http://www.adobe.com/svg/viewer/install/main.html
  44. JSP not necessary[ Go to top ]

    For an example of Model 2X witout JSP, where JSP is simply replaced with XSLT, read our first JavaWorld article:

      http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html

    Clearly, you can build approaches with or without JSP, with or without Struts. There is a nice diagram showing three possible models here:

      http://www.orbeon.com/oxf/scenarios.png

    Replace OXF with your favorite framework. All three models can make sense depending on the type of application you are building and how much of an existing infrastructure you need to reuse.

    JSP is pretty much ubiquitous and is getting more and more so. If you can provide a solution building on top of existing JSP technologies, you are more likely to attract developers. The solution we propose in this article is done with these considerations in mind: leverage JSP and JSF, which, if used correctly, are acceptable technologies, and address the specific rendering issues with XSLT and XML pipelines.

    -Erik
  45. JSP not necessary[ Go to top ]

    I read the article you published a year agao. It is nice.

    You are right in pointing that "JSP is pretty much ubiquitous and is getting more and more so". However, that does not change the fact that JSP adds another layer. My opinion is that JSP does not add that much indespensible value on top of servlet although it brings some convenience. The tag libraries are surely an asset for using JSP. I have my doubt that it is in the right direction in the long run.

    The demo site I cited is not targeting developers. Its intention is to provide a solution without requesting a developer with java or xml skills.
  46. The real agenda here.[ Go to top ]

    I have read through this article and my view of it is as follows:

    The authors are outlining a way of securing lifetime employment. You design web apps (or any other kind of app) in such a complex, convoluted way, using such a cocktail of overly-hyped buzzword-acronym technologies, that nobody after you can make head nor tails of it.

    So, since you are the only person who understands what you did, you become unreplaceable and have what was called in the People's Republic, the "iron rice bowl". (And of course, the socialist iron rice bowl combined with a capitalist pay scale may well be the best of both worlds to which the authors refer.)

    That, as far as I can see, is the only rational reason for architecting web applications as outlined in the article. If your goal is not lifetime employment via the mechanism I describe above, then to develop web applications using this unholy combination of JSP+XSLT strikes me as suicidal, or, at the very least, masochistic to a pathological degree. It also could bear certain risks, such as being lynched by your graphical design team. (*)

    Best Regards,

    Jonathan Revusky

    P.S. For full disclosure, I should say that I am the lead developer of the FreeMarker project at http://freemarker.org which is a reasonably sane JSP alternative.

    (*) Note the lack of any smileys here. This is deliberate because I am *not* joking.
  47. The real agenda here.[ Go to top ]

    Dear Jonathan,

    I am not sure what buzzwords you are referring to. Is it the set of technologies developed, or under development, under the umbrella of Sun (JSP, JSTL and JSF)? I agree that Sun is good at creating acronyms by the bucket and that it can get confusing. But today developers use JSP, Struts, are beginning to use JSTL, and I contend that soon they will use JSF. If you think about it, it all comes down to HTML with a bunch of special tags to control conditions, iterations, extract data from models, and place components on a page. Yes, a real, extensible template language!

    I had a look at FreeMarker. Please understand that I respect the project and its developers. But consider that you use Model 2 and MVC as we do. You use your own template language, and we use JSP and XSLT. The differences are minor from an architectural point of view, and your analysis that our approach is particularly convoluted does not really stand. You could have argued that your template language is simpler than modern JSP and XSLT, and there is truth to this. But there are benefits to building a modular presentation layer that separates and centralizes the look and feel aspects. With JSP, I have seen people spend weeks updating hundreds of JSPs just because the look and feel of the application changed. With XSLT, I can integrate a new look and feel in a matter of hours, independently from the size of the application.

    The statement in your FAQ that JSP is not appropriate to implement an MVC view is more than disputable. This may have been easier to defend three years ago, but, and that is one of the major points of the article, things have changed. With JSTL and the Expression Language, JSP is now a better template language. Even without JSTL or JSP 2.0, Struts users have been using JSP as MVC views for ages. You will have a tough time convincing them that JSP is not "suitable".

    Where I agree with you is that the relationship between developers and graphic designers is a tough one, even if you may have seen one side of the coin, and I have seen the other. In most real-life scenarios I have witnessed, designers concentrate on what they are good at and paid for: creating a design with their favorite tools. They may go as far as creating advanced mockups with JavaScript. Once they are done, developers include the design into the application. The bottom line is that you need people with a totally different set of skills for each part. I strongly agree with the concept of separating roles, but so far I have not seen the magic tool that allows designers to easily integrate their design with the application, except in the most trivial scenarios and with serious limitation.

    -Erik
  48. The real agenda here.[ Go to top ]

    Dear Jonathan,

    >
    > I am not sure what buzzwords you are referring to. Is it the set of technologies developed, or under development, under the umbrella of Sun (JSP, JSTL and JSF)? I agree that Sun is good at creating acronyms by the bucket and that it can get confusing. But today developers use JSP, Struts, are beginning to use JSTL, and I contend that soon they will use JSF.

    <sigh>

    Erik, there are people who will use anything if it comes from a big company and there's marketing behind it. However, in a technical discussion of whether a given architecture is actually a good idea, that is really completely irrelevant.


    > If you think about it, it all comes down to HTML with a bunch of special tags to control conditions, iterations, extract data from models, and place components on a page. Yes, a real, extensible template language!

    Erik, this has been available for years. FreeMarker, and WebMacro for example, have both been available for 4 years. I mean, this statement that these are "such exciting times" for developers... yes, it irritated me and that was clear from the sarcastic tone of my message. If you can undertake the empathic exercise of imagining yourself in my position, you could perhaps begin to understand just how frustrating and annoying that could be...

    >
    > I had a look at FreeMarker. Please understand that I respect the project and its developers. But consider that you use Model 2 and MVC as we do. You use your own template language, and we use JSP and XSLT. The differences are minor from an architectural point of view, and your analysis that our approach is particularly convoluted does not really stand. You could have argued that your template language is simpler than modern JSP and XSLT, and there is truth to this. But there are benefits to building a modular presentation layer that separates and centralizes the look and feel aspects. With JSP, I have seen people spend weeks updating hundreds of JSPs just because the look and feel of the application changed. With XSLT, I can integrate a new look and feel in a matter of hours, independently from the size of the application.

    The above is another non-sequitir. That *you* can integrate a new lok and feel in a matter of hours.... that is completely irrelevant. What would be relevant would be if a non-programmer could change the look and feel.

    But, moreover, there is a deeper issue here. I think you're attacking an ersatz problem. In practice, the whole issue of changing the look-and-feel of a site using templates is a solved problem already. Basically, you use includes for commonly repeated elements. You have a header include, a footer, maybe a sidebar. Then, in practice, you can change the look-and-feel of a site by changing those files. You might change a logo or two, and if a change in font or type style is necessary, you edit the accompanything .css file. What I am describing is not the full customizability of XSLT. But your target audience cannot use XSLT anyway. Also, that level of manipulability is not necessary in practice.

    Meanwhile, this pipeline architecture of JSP followed by XSLT is such that it is almost impossible, given the typical cultural level of web developers, for those people to develop a strong conceptual model of how the pages are generated. And that is a real problem.


    >
    > The statement in your FAQ that JSP is not appropriate to implement an MVC view is more than disputable.

    It's disputable, but I don't know what "more than disputable" means. Actually, I think the statement is broadly true. By analogy, it is true to say that you can follow robust coding practices in C++. However, that involves using a certain subset of the language -- for example, avoiding the crazy uses of pointer arithmetic that are very common out there. You can do MVC with JSP as long as you use a certain subset of its features that are compatible with that set of practices. For that matter, you can write well-structured, maintainable code in perl if you have a lot of discipline. (It just doesn't happen that way in practice....)

    The point is that FreeMarker is a tool that, by contrast, pushes you in the direction of MVC practices, while JSP does not. You can do horrible things in FreeMarker or with anything else, but the tendency with JSP is much much stronger. Similarly, the tendency for C++ code to be unmaintainable is much greater than with Java.

    > This may have been easier to defend three years ago, but, and that is one of the major points of the article, things have changed. With JSTL and the Expression Language, JSP is now a better template language.

    Well, it's a better template language than what???

    Compare this from your article:

    <c:choose>
            <c:when test="${status.index % 2 == 0}">gray
            <c:otherwise>white


    to the FreeMarker equivalent:

    <#if status.index %2 == 0>gray<#else>white

    The JSP code fragment is ridiculously verbose!

    >Even without JSTL or JSP 2.0, Struts users have been using JSP as MVC views for ages. You will have a tough time convincing them that JSP is not "suitable".

    I'm sorry. This is just ridiculous. You cannot continually make the argument that, simply because a set of people use something, that therefore it is a good idea. You cannot argue that way. It isi simply logically invalid!


    >
    > Where I agree with you is that the relationship between developers and graphic designers is a tough one, even if you may have seen one side of the coin, and I have seen the other. In most real-life scenarios I have witnessed, designers concentrate on what they are good at and paid for: creating a design with their favorite tools. They may go as far as creating advanced mockups with JavaScript. Once they are done, developers include the design into the application. The bottom line is that you need people with a totally different set of skills for each part. I strongly agree with the concept of separating roles, but so far I have not seen the magic tool that allows designers to easily integrate their design with the application, except in the most trivial scenarios and with serious limitation.

    Well, there's no magical tool, but nobody was claiming that, and that hints at some kind of all-or-none fallacy. (You should watch out for this kind of logical fallacy stuff, like the idea that because a lot of people do something, therefore it's a good idea, that is a logical fallacy that you are guilty of above.) While there's no magical tool, the fact remains that some tools are better than others and some approaches to a given problem are more promising than others.

    Frankly, the approach outlined in your article does not strike me as very promising. At least, not in practice. Far better tools and far better approaches are available.

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project, http://freemarker.org/

    >
    > -Erik
  49. The real agenda here.[ Go to top ]

    Dear Jonathan,

    There are are several points that I would like to precise:

    1. The vast majority of people I work with and talk to use JSP. JSP is used by the masses and is likely to remain the market leader for a long time. This is not, and has never been, to my liking, but it is a fact. Nowhere have I said that I think that JSP is perfect or even excellent. That is your own interpretation and your own conclusion. If you want to ignore the fact that people use JSP, that's fine. There is room for many different frameworks on the market.

    2. The subject of the article is about leveraging the fact that developers use JSP. It is not about proposing the best presentation layer architecture you can think of from scratch, although I think the architecture has a lot of merit (otherwise the article would be pointless for me).

    3. JSP is slowly changing. Whether JSP's new features have been implemented before, or in better ways, in other frameworks is irrelevant. This evolution is exciting in that it brings those features to the masses. For example, JSP 2.0 allows you to explicitly disable the use of scriptlets in all JSP pages at the web.xml level. This is an easy way to enforce the discipline of using the EL and standard tags instead of Java, and of avoiding the mess of the initial style of JSP. That is what I mean when I say that JSP is a better template language than it used to be. You are free not to be excited.

    4. JSF provides a component framework that is tools-friendly. Many template frameworks lack such a component-based approach, which is very intuitive to non-developers. Again, I think that it is exciting to see that kind of feature slowly getting available to JSP developers. Not because it is new: ASP develeloper have had components for years, and server-side Swing-like frameworks are legion (but none is widespread). Will JSF succeed? Maybe, maybe not.

    5. You have to realize that different people have different real-life experiences with different tools. In most projects I've seen, designers do not touch JSP or other template pages, period. This being said, I am all for lowering the barrier of entry, and I think that JSP 2.0 and JSF, with adequate tools, will do exactly that.

    6. XSLT is just the most widespread XML transformation language currently available. The architecture presented does not require XSLT. You can use a simpler language. The point is that it makes sense to define the look and feel for a table, a button or a calendar in a different place than where the table is used. This is the same approach you use with your templates for the header and footer, except that it is extended to all components on a page. Used right, an XSLT template will look much like one of your header templates. It is maybe a weakness of the article not to show how simple this can be. This can also be leveraged by tools such as HTML editors: design a single button, automatically generate the XSLT template for that button, and off you go: all your buttons look the same.

    7. Yes, JSTL and XSLT are a little too verbose. This does not mean that the concepts are more or less complicated than those of other, less verbose languages.

    BTW, there is no simple truth about technology. It is all a matter of discussing pros and cons and understanding where people come from. Ranting and sighing won't convince anyone.

    -Erik
  50. Millstone UI Library (LGPL) together with Web Adapter (LGPL) implements very similar architecture combining XSLT for look and feel (themes) and strong UI components framework. The combination of these technologies provide better flexibility than JSF, but XSLT adds some performance cost.

    You can see a demo that shows what can be achieved and some code examples showing the benefits from programming model perspective.
  51. Just my 2c regarding using XSL in presentation layer.

    We've got one-fits-all Apache's Xalan, and, unfortunately, it has very serious scalability problem. If you use anything different from Substitute Pattern (which is much better implemented by JSP), like computational stylesheets, it scales badly because of that silly StringBufferPool. Whenever you have any noticeable number of concurrent users, all the threads get locked up in this pool waiting on get/put monitors. And that's the only JAXP compatible transformer, thanks to open source.

    So I'd take second part of the subject out. It's not going to work, at least for now.
  52. You may want to look at Saxon:

      http://saxon.sourceforge.net/

    I do not know if Saxon fixes your problem, but it is open source (MPL) and does support JAXP:

    "Saxon implements the JAXP 1.1 API (including TrAX), as defined in JSR-63. Saxon implements the interfaces in the javax.xml.transform package in full, including support for SAX, DOM, and Stream input, and SAX, DOM, and Stream output."

    You can also report your Xalan issues here:

      http://nagoya.apache.org/bugzilla/

    -Erik
  53. Still Require Some more Help[ Go to top ]

    Does anyone know what do I need to read to start a perfect jsf project. If you do please help and get listed. admin at javaserverfaces dot co dot uk
    Thanks
  54. Source code for the article[ Go to top ]

    I'm very interested by the source code for the article. Unfortunately the mentioned link (http://www.orbeon.com/model2x/tss) conducts to a missing page.
    What I would to realize is an XML RenderKit.
    Thanks.
  55. A LiVe Example[ Go to top ]

    Meta Search Engine of torrent files meta-torrent