Many folks on both the STRUTS-DEV and STRUTS-USER mailing lists, have wondered at what the future holds for Struts, now that the initial early access release of JavaServer Faces has become available. Here is a snapshot of my current thinking on the subject.
BACKGROUND: ========== JavaServer Faces (JSF) is being developed as JSR 127 under the Java Community Process, with the goal of creating a standard framework for user interface components to be used in web applications. Included will be the following basic features: * User interface component model * Event handling model * Validation framework * Flexible rendering model (plugin support for rendering different kinds of HTML, or different markup languages and technologies) * A standard RenderKit (and associated Renderers) for generating basic HTML/4.01 markup. This library is primarily for making JSF useful out of the box, and allow apps to be portable across JSF implementations. However, we expect a lot of innovation in this area among competing JSF implementations. All of the above functionality is available via standard Java APIs, and is thus not tied to JavaServer Pages (JSP). However, because a large majority of JSF users will also be using JSP, an additional set of requirements is included in the JSF specification, including: * A standard tag library for generic things that are independent of the specific RenderKit in use (such as adding a validator to a component). * A standard tag library for the basic HTML RenderKit, with a tag for each combination of a component type and a method of rendering that component type. An example will make this clearer -- consider the UISelectOne component, which represents a list of options, and allows only a single option from the list to be selected. Such a component can be rendered in three different ways (in the basic HTML RenderKit), each with a different Renderer and a corresponding custom tag: <h:selectone_listbox> Display a list of all the possible options (expanding the box to include all of them so that no scrollbar is required). <h:selectone_menu> Display as a combo box (the traditional HTML <select> element with size="1"). <h:selectone_radio> Display as a set of radio buttons and corresponding labels. Note that the application developer doesn't know or care which mechanism was used to display this component -- that's up to the page author, who will pick the desired representation by virtue of which tag he or she selects (at the Java API level, you make this choice by setting the "rendererType" property on the component instance). This is one of the many advances that JSF provides over Struts tags, where there is one and only one way to render each individual element. There are also provisions for creating more complex components like grids, tree controls, and the like -- a common theme you will see is "compose complex things out of little things" -- that is accomplished in JSP by nesting component tags inside each other, just like you nest HTML <input> elements inside a <form> element. For more information about JavaServer Faces, and an early access draft of the specification (and an early access version of the RI that corresponds to an even earlier draft of the spec), you'll want to bookmark: http://java.sun.com/j2ee/javaserverfaces/ In addition, there is a forum on the Java Developer Connection (free registration required) focused on JavaServer Faces, so please ask your general Faces-related questions there instead of here. Here's a direct link to the forum page: http://forums.java.sun.com/forum.jsp?forum=427 Note that JavaServer Faces depends on Servlet 2.3 and JSP 1.2 (i.e. J2EE 1.3 containers). HOW DOES THIS AFFECT STRUTS? =========================== At first glance, the low level components sound a lot like the struts-html tag library that Struts users know and love. Indeed, there is a very substantial amount of overlap. So, what's going to happen? In my JavaOne BOF on Struts (March, 2002), I made the statement that Struts would have a very clean integration with JSF, so that you can use JSF components in your user interface, but continue to use the controller, Actions, and associated business logic. Indeed, I stated that it will be possible to transition your application from using Struts HTML tags to using Faces component tags, one page at a time -- in most cases, with zero changes to the business logic or Action classes and minimal changes to the <forward> elements in your struts-config.xml configuration file. Along with developing JavaServer Faces itself (I am the specification lead for JSR-127), I have been working on just such an integration library for Struts (1.1 only; sorry in advance to 1.0 users). While not completed yet, it is clear that the goals stated in the previous paragraph are achieveable with the current evolving design of JSF. While things can always change in the future, many JSR-127 expert group members consider high quality integration with Struts to be an important success factor for JavaServer Faces to be accepted. Therefore, I do not expect that JSF will evolve in ways that make this kind of integration difficult or impossible. >From the developer's perspective, you will need to do only the following to start using JSF components in your pages: * Add a new struts-faces.jar file, and the JAR files for an appropriate JSF implementation, to your /WEB-INF/lib directory. * Note that JSF and the JSP Standard Tag Library (JSTL) interoperate very nicely, so you will also be able to use JSTL tags in your new pages if you wish to. * Add a couple of elements to your web.xml deployment descriptor, corresponding to the requirements outlined in Chapter 9 of the JSF specification. * Transition one page at a time to use the new tag libraries, making an appropriate modification to the <forward> elements for your pages (the URL needs to change to meet Faces requirements). The integration library will be available as a separately packaged download that runs with Struts 1.1, and will include a converted copy of the canonical struts-example web application so that you can see exactly what had to change in order to use Struts with JSF. Besides the integration classes themselves (primarily an implementation of the JSF ApplicationHandler API), the library will include some Struts-flavored components and renderers that provide functionality similar to that provided by the existing struts-html tags, when this is not provided by the standard JSF components. For example, there will be a Struts version of the UIForm component that accepts an "action" attribute that looks up the corresponding action mapping, and creates the form bean as needed, just like the <html:form> tag does today. The good news -- development of this integration library is well under way. The bad news -- you can't see it quite yet. This is primarily because it relies on changes to JSF that have occurred since the early access release of the RI was published, so you wouldn't be able to use it anyway. However, as soon as it is feasible, this library will be added to the "contrib" folder of Struts, with the sources (and downloadable distributions) available under the usual Apache license terms. (The source code will also give you a head start at creating your own JSF components, too). SO WHAT USER INTERFACE TECHNOLOGY SHOULD I CHOOSE? ================================================= Everyone's functionality and schedule requirements are different. However, the following points summarize my basic recommendations and thoughts about the future: * If you have existing Struts-based applications that use the existing HTML tag library, feel free to continue to use them if you wish. Struts 1.1 offers full support for this existing functionality. * Once the integration library becomes available, you should do some experimenting and prototyping to determine the effort required to migrate your apps to the new JSF component architecture (I'm betting that the extra functionality you gain by doing this will be well worth the effort in many cases). As described above, the actual migration can be done piecemeal -- it doesn't need to happen all at once. * For applications now (or about to be) under development that have relatively short term schedules (i.e. the next few months), you should probably stick with the existing HTML library. * For applications with a longer lead time, seriously consider waiting for the ability to use JSF components instead of the Struts HTML tag library. Doing this will let you leverage not only the standard HTML components that come with JSF out of the box, but also the rich libraries of JSF components likely to be created by third parties in the future (including Struts developers). For Struts after 1.1 is released, the developers haven't yet had formal conversations (which will happen on STRUTS-DEV) about what a future Struts will look like. However, I'm going to continue to advocate a long term migration to using standards like JSF and JSTL when they are available, and de-emphasize the further development of the Struts proprietary tag libraries. The Struts tag libraries have had a tremendous positive impact on the development of the standard Java APIs for user interfaces. I joked with the JSTL spec lead that Struts users would *never* accept JSTL without an expression language at least as powerful as the Struts one; and there is more than a little truth to that statement :-). The same thing is happening now for the HTML tags -- and it's time for us to start migrating to the standards, which gives us the time to focus on extending Struts in other directions in the future. Comments? Questions? If it's about Struts, or Struts/JSF integration, feel free to ask about these issues on STRUTS-DEV or STRUTS-USER (although I'm going to be relatively incommunicado over the next week; I'll be in Yokohama at JavaOne Japan and only intermittently connected to email). Questions about JSF itself should be addressed to the JSF forum at the URL listed above. And thanks to all of you for your continued support and use of Struts -- the community that has developed around this framework continues to amaze and humble me. Craig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>