Women in Technology

Hear us Roar

  Improving JSF by Dumping JSP
Subject:   Response to some of your issues
Date:   2004-06-15 08:45:22
From:   edburns
Hi Hans,

Thanks for collecting the top problems with JSP/JSF integration into one
concise article. We know that JSF/JSP has some rough edges and
smoothing them out is the *sole* purpose of the JSP 2.1 spec effort [1].
I've added instructions on dealing with the issues you raise in your
article to the ReleaseNotes [2]. These will be updated in the next day
or so.

I disagree with your suggestion to abandon JSP for use in JSF. There is
a great value in continuing to leverage standard technologies, such as
JSP. To use build on your transportation anolgy, note that the UI for
driving an SUV is generally the same as for driving a sedan, or a
compact car. Therefore, the JSP spec team is open to doing whatever it
takes to solve these JSP/JSF integration issues, while maintiaining a
modicum of backwards compatibility. There is nothing new about these
challenges. When JSP 1.1 came out, several requirements seen as key by
some people were not addressed. I feel the JSP 2.0 spec addresses these
omitted concerns quite well, and I'm very confident that the JSP 2.1
spec will adress your concerns.


[1] http://www.jcp.org/en/jsr/detail?id=245

[2] http://java.sun.com/j2ee/javaserverfaces/docs/ReleaseNotes.html

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Response to some of your issues
    2004-06-15 09:52:32  Hans Bergsten | O'Reilly Author [View]

    Hi Ed,

    Nice seeing you here. If JSP 2.1 proves me wrong, great! Until then, I remain unconvinced.

    I don't see how JSP can be modified to remedy the parallel creation and rendering of components for the first request, because processing a JSP page can have side effects and processing the same page twice (once to create the components and once to render) may lead to different results because the page can contain conditional code.

    The buffering issues may be possible to fix, either with hacks in the JSF tag handlers or with new hooks in the JSP tag handler API, but either way, it will be a kludge.

    I don't see any way to get around the fact that non-JSF tag libraries can't be used without a special set of rules (e.g., required "id" attributes and no non-JSF iteration allowed).

    Regarding the analogy, JSP and JSF goes beyond the dashboard and the steering wheel; the differences and overlap are more fundamental, because both have request lifecycles and semantics that simply don't match. Using the features that make JSP so popular (e.g., conditional processing of a page, changing the page flow in a page with forward/redirect) will always clash with JSF, where the same things are intended to be done by other means.

    Even if I just don't get it and there is in fact a way to solve all these problems in JSP 2.1, I still think an alternative that completely separates the template from the view specification ala Tapestry has many advantages over the JSP model. So an alternative to JSP is very much an important area for experimentation no matter what, and I'm sure that including such an alternative in the JSF spec would be very welcome.