UI frameworks and JavaServer Faces, Page 2
The Velocity framework provides a capable and flexible template language ideal for creating UIs (and very valuable for many other templating tasks, incidentally). It purposely avoids being a general-purpose programming language, neatly avoiding the temptation to embed business logic in the UI, which can happen with JSP, for example. Velocity's template language does, however, have plenty of capability to render components managed by JSF. The renderkit in this case produces a nested structure of JavaBeans from the UIComponents as it traverses the JSF tree. Velocity's template language allows easy access to both bean properties and methods directly from the template. By preparing a template "macro", Velocity's VTL (Velocity template language) can be extended, and a macro can be used to refer to each JSF component to be placed on the finished page. These macros then perform the same function as the JSF custom tag library does in the JSP implementation of JSF: they provide the translation from the non-visual JSF component to the finished markup.
The Tapestry framework (another Apache project) takes a different approach to its UI functionality, as well as providing much more than just a rendering technology. Conceptually, some parts of Tapestry are comparable to JSF, in that Tapestry uses a reusable component mechanism for building the user interface, and incorporates an event model for handling interaction between the UI and the underlying application model. Tapestry, however, uses the target markup (for instance HTML) as the "template language", as opposed to imposing a new template language, making it far easier for web page designers to work directly with HTML, and have that same HTML, without changes, act as the template for a dynamic web application. Special anchor markers are used to simply denote where the Tapestry components are to be placed in the HTML page, and at runtime the framework handles the merging of the two, producing the finished markup. Each Tapestry page can have a corresponding component de! finition, specifying for each of the referenced components what type they are, and how they interact with the page.
Of course, Tapestry also has one significant advantage of JSF as it stands today: the Spindle project, designed as an Eclipse plugin for Tapestry developers is something that JSF needs, and no doubt will get, but doesn't have today.
We've only examined a few of the many powerful UI frameworks available in open source today, and have just scratched the surface of how these frameworks might be tied in to JSF (or vice versa). Hopefully though, this exploration of the possibilities is enough that you can see that JSF is not necessarily an "either/or" choice with existing UI tools and frameworks, but that to a large degree synergistic co-existence is possible. This has the potential to allow developers to take advantage of what's good in JSF, and to come together on a single component standard over time, while at the same time not disrupting current development, nor losing the unique advantages of other UI frameworks.
So, if JSF can be used as a compliment to existing UI frameworks, how can tool-builders accommodate this? It will no doubt be easier for creators of development tools to write their visual design tools to support only JSP, indeed, JSP is an essential choice to support. However, it is not the only choice, and tool-makers who provide only JSP support are doing developers a disservice. By making it harder to use other UI frameworks at the rendering level, they are effectively putting those frameworks at a disadvantage as well, and failing to live up to the promise of flexibility offered by JSF itself. If instead tool vendors allow a choice of outputs from their JSF design tools, permitting the user to select the rendering technology used, there is no loss of flexibility. A page designer can 'paint' a UI page, choosing from a pallet of JSF components. The developer can then take this design and generate the UI template for their framework of choice - a Velocity template, a Struts JSP page, a Cocoon XSL stylesheet, and so forth. No, this will not be as easy for the tool vendor, but development tools are not judged by how easy they are to create, they are judged by how easy they are to create with them. As developers, we have a responsibility to throw our support behind those tools that give us choices, encouraging other tool-makers to do the same. In the development technology battle between J2EE and .NET, we must not fall prey to solving problems the easy way - by taking choices away, as Microsoft has done. We should instead rely on the superior flexibility of the Java platform to continue to give developers even greater choices, just as Java itself preserves our choice of platform.
About the AuthorMichael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at firstname.lastname@example.org.
Page 2 of 2