|
|
 avaServer Pages Standard Tag Library (JSTL) is a library of standard tags that you can place on JavaServer Pages (JSP). The tags encapsulate functionality commonly used in Web applications. JSTL supports common structural tasks such as iteration, conditional processing, parsing, XSL transformation of XML documents, internationalization and locale-sensitive formatting, and database access. JSTL has become a popular standardized tag library in the market today.
In contrast, JavaServer Faces (JSF) is the "new kid on the block" addition to the Java suite of technologies available for Web development. It is the "Swing for server-side applications." It brings the popular desktop event-handling metaphor into the world of server-side Java applications. The JSF specification allows for custom rendering of common user interface components intended for different presentation protocols and devices, while also providing extensibility so developers and vendors can create custom user interface widgets. The standardization of this specification has already triggered the development of numerous third-party tools to improve and simplify application development with JSF. Among the early adopters to develop Integrated Development Environment (IDE) support are IBM's WebSphere Studio (version 5.1.1), Exadel JSF Studio 1.0, and Sun's Java Studio Creator. At this writing, Java Studio Creator (formerly code-named Project Rave) is available only in pre-release mode, while the other two products are already commercially available.
If you're not familiar with the evolution of Java as a Web development tool, the coexistence of these two strategies (JSTL and JSF) might seem strange: Why have two separate ways to create Web interfaces? They may not both survive forever, but right now, both are warranted. Current JSTL users get a straightforward migration path, and having both provides choice for developers, who can benefit from using the best features of each.
This article outlines an effective coexistence strategy between these two technologies. It assumes that you already have some basic understanding of JSF and JSTL. There are many resources on the Web that discuss these two technologies independently; but, there is little available information about creating a marriage between the two.
JSF Hides Complexity
JSF-enabled IDE's simplify development of large Web applications with several data entry screens (Web pages). Painting a JSF screen using the IDE's drag and drop features eliminates the need to manually code JSP page layouts. Similarly, hooking screen events to server-side Java components through the IDE's user interface reduces the coding effort required to connect the screens to business logic components. Using JSF, you need to develop applications once that are intended to render through multiple user interface protocols to multiple client types. Subsequently, you need to develop only the necessary custom renderers for the different delivery mechanisms as needed. JSF also brings resemblances of .NET into the Java world. This similarity of concept is an advantage for developers who would like to switch between the two technologies (trust me, there are some who do this).
Programming using JSF with JSF-supported IDEs can hide the complexity and inner workings of JSF from developers. This makes it very important to pay close attention to the performance implications of application design. You must be very careful to avoid overusing event handling on any Web screen. The more JSF events on a screen, the more round trips are required from the client to the server, and the slower the application becomes. As the case is with any new technology, debugging and troubleshooting support for JSF is minimal at this point. You should keep that in mind before diving into the sea of JSF. The built-in data validation support in JSF is not too elaborate, but what's provided today is a good start, can be extended, and will likely evolve as user support grows. If your application doesn't have data entry forms and uses simple screen-to-screen navigation for static display of dynamic content, JSF will really be overkill, but is appropriate if the development team is comfortable with JSF and if you're planning on migrating the application to include form interactivity at some point.
|
|
