JSF and JSTL
Though it is supported, many people are now advocating that JSF tags should not be mixed with Java Standard Tag Library (JSTL) tags in the same JSP. The reason for this is that JSF provides a slightly different model for separating the view from the view logic. Using standard JSTL tags, a lot of the programmatic flow is actually embedded in the JSP itself. With JSF, the goal is to push most of the programmatic logic into the bean classes rather than in the JSP itself, so your JSPs tend to remain more declarative in nature. One advantage to abiding by this separation of view and view logic is that it makes it simpler to switch rendering kits if the need arises. There are equivalent ways to accomplish most things in JSF that you may have previously done using JSTL.
This said, a pragmatic approach to introducing JSF into an application is to incrementally add new JSPs or change existing JSPs to use JSF custom tags instead of standard custom tags. This DevX article, "Mixing JSTL and JSF in Web Applications," discusses this approach.
Is JSP the right choice?
Server page technologies (like JSP) have always been a little difficult to work with because of their in between nature. A server page is a concoction of HTML embedded with Java code. Custom tags help to minimize the amount of code in JSPs, but there is still a fundamental problem in that somebody has to write the JSP. This JSP author must either be a UI designer or a developer that learns how to convert UI mock-ups into JSPs.
In my experience, the creation of JSPs never seems natural to either the developer or the UI designer. Developers don't want to have to deal with problems involved with text and images not lining up right, and UI designers don't want to deal with case-sensitive variables and iteration logic. JSPs also seem to be a recurring point of failure because they are hard to unit test and they are affected by both code changes and look-and-feel changes. These are all indications that JSP does not give you a true separation of view from view logic.
People have been using JSP because it is a standard and because there is a lot of support for it. Both are obviously great reasons, but not too many people even question using JSP as a view technology because they are used to it and/or because they have never worked with any other view technologies.
JSP is a required part of the JSF specification because the specification writers wanted to ensure an easy transition into JSF for Web developers who are familiar with existing Java technologies. But, as some people have discovered, the combination of the two technologies has its own set of problems. Hans Bergsten, author of "JavaServer Faces" (O'Reilly) has written an article about some of the technical issues that arise when using the technologies together (see Related Resources, left column).
Some highlights of the article are:
- JSPs are processed in order from top to bottom in order, but for JSF to work well components should be created, processed, and rendered separately. Mixing the two causes JSF component rendering to behave erratically.
- It's not safe to assume that a construct that is valid in a JSP page is necessarily valid in a JSF.
- JSP is supported in JSF to allow an easier segue into JSF development, but the complications of mixing the two don’t necessarily make JSP the best choice.
As an alternative to using JSPs, Bergsten shows how one can almost entirely separate the view from the underlying view logic by creating a custom rendering kit.
A mockup is a UI prototype that a graphic designer or a Web designer puts together so that people can get an idea of what the Web application will look like. I've heard one too many developer wish that they could just read the mockup and programmatically change the elements inside of it, without having to manually "translate" it into a JSP. Bergsten's template-based rendering kit allows you to do exactly that. The HTML mockup need only be injected with identifiers specified in span tags and id attributes. These identifiers represent JSF components. An XML file is provided that tells the rendering engine which component to replace the identified HTML elements with. The rendering kit will parse the HTML page using a DOM parser, replace identified tags with matching components that are specified in the XML file, and then translate the DOM back into HMTL using XSLT.
Using this model, UI designers are free to modify the layout of the page using their favorite WYSIWYG editor and the changes can be reflected in the system immediately. The only thing that they must worry about is to leave the id attributes and span elements intact. Developers would no longer have to worry about UI layout and can focus on developing the view logic and view components.
I would like to see this kind of rendering kit become more popular, if not become the de facto standard for Web development. I'm sure that it has its limitations as well, but I think it facilitates easier cooperation between UI designers and developers and it provides a better separation of layers.
Is JSF Ready for the Mainstream?
Today, if a client asked me to give them a recommendation on whether or not to use JSF for a mission critical application, my answer would be no. If a client asked me to build a small Web application that would be used for internal operations, I would probably build it using JSF. My point here is that I think JSF has potential to become the framework of choice for Web developers in the next several years, but it is not quite there today. The specification is still being updated and existing implementations are not mature yet. It is also unclear how developers will react to the integration problems that exist with JSP and JSF. It's uncertain whether developers will be willing to shift to a different view technology, whether they will just chose to abandon JSF, or whether JSF and JSP will undergo changes in order to facilitate better integration.
What about Struts?
Craig McClanahan is the original creator of Struts and is also the specification lead for JSR-127. McClanahan talks about how Struts and JSF will work together on the Struts Web page (see Related Resources, left column). It seems that the short-term vision for Struts is for it to easily integrate with JSF by providing a custom-tag-based rendering kit. The long-term vision is unclear, though I envision future versions of Struts becoming pure JSF implementations, and eventually dropping support for the existing MVC framework. But this is all speculation, so don't bet money on it.