UI frameworks and JavaServer Faces
While JSF provides a powerful foundation for building user-interface components, it is a new standard, only just now being fully defined. Many other articles discuss what JSF is, and how it works, and the upcoming book "JSF in Action", by author Kito Mann (Manning publications), gives a comprehensive description of how to put it to use effectively. Most web applications already in use today make use of a UI framework of some sort already, and many of these frameworks are highly capable in their own right. These frameworks are not going to go away, nor are developers going to readily discard all their learning and experience with them. Indeed, why should they? Just because a new standard has arrived is no reason to abandon not only the tried and true, but also the unique advantages of existing UI frameworks. The good news is that JSF is perfectly capable of working in conjunction with these frameworks, and has in fact been designed with easy integration in mind. In that light, lets have a look at how JSF can be used in conjunction with existing frameworks, as an enhancement, not a potential replacement.
While JSF supplies functionality at several levels of UI design, many of its components are designed to be "pluggable", using the Factory pattern to provide the specific implementation at runtime. (Even the factories themselves are "pluggable", in fact). This allows elements such as the FacesContext, the StateManager, the ExternalContext, and, perhaps most importantly for our discussion here, the LifeCycle handler and the RenderKits to be dynamically specified. This means that for each major piece of JSF, a special implementation of these elements can be provided that is "aware" of an external framework, and makes the connection point between this framework and JSF.
In addition to pluggable factories, JSF also provides the means to handle both "JSF requests" and "Non-JSF requests", meaning a page prepared by another framework can trigger a page that will be handled entirely by JSF, in addition to the usual case where a page rendered by JSF itself triggers the next request.
Let's examine how this might be accomplished using a few of the more popular UI frameworks as an example - please understand it is not my intention to lay out a development roadmap for integration with these frameworks here, just to examine the possibilities for such synergy, and to open the door to further exploration.
With somewhat of a leaning towards the use of JSP in any case, it is easy to see how JSF would make a good fit with Struts. Indeed, there is an effort already well underway to create such a connection. Both Struts and JSF already integrate well with the JSTL (Java Standard Tag Library), and Struts provides some unique functionality in that it delves a bit further into providing services for application logic than JSF does. Struts provides, for example, a database connection pool mechanism, which is a Model-oriented concern that JSF does not provide. Struts also includes the portlet-like Tiles tag library, which currently has no equivalent in JSF. Where the two frameworks do overlap entirely, it provides an opportunity for developers to transition gradually, where this is desirable, to JSF components. Where existing applications are being extended, this allows new pages to take advantage of JSF components, while existing Struts pages co-exist properly with them in the same application. A library and information about this integration is already available at the Apache Foundation's website.
A powerful Avalon-based framework, with capabilities for much more than user-interface construction, Cocoon does however bring substantial power to the UI developer. Cocoon provides more than the normal request/response cycle processing, it brings the concept of "pipelines" to the web application. A typical pipeline begins with a matcher, which maps requests to the proper pipeline, then continues with actions, generators, transformers, and finally a serializer, which produces the finished markup for the browser (or other output device). Typically, the data flowing through this pipeline is XML, often taking advantage of XSL to produce the finished markup. JSF fits neatly into this structure in that it is straightforward to provide a RenderKit that will produce XML. The Action class in a pipeline is normally where application logic is executed. By providing a custom implementation of the JSF LifeCycle object (allowing us to "intercept" the JSF process flow at the proper pla! ces), we can use the Action mechanism to provide the "connection point" for JSF and Cocoon, taking the output of the Action and producing a JSF view "tree". JSF's components are already organized into hierarchies, making it easy to map them to XML via the RenderKit, which then "inserts" this XML into the Cocoon pipeline. Cocoon's processing then continues as normal, doing whatever it would normally do with the XML. Often this involves processing via one or more XSL stylesheets to produce markup. We can produce "standard" stylesheets that provide the mapping of the XML version of a rendered JSF component into, say, HTML (or PDF, WML, etc). As Cocoon already supports serializers for many different display formats, such as PDF, SVG, and so forth, these alternative markups are easily supported.
This is just one example of a connection between Cocoon and JSF - there are several other possibilities.