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]>
