KM: Craig, most people know you as the father of Struts. Can you explain
your involvement with JavaServer Faces and Shale?
CM: Primarily because of the success of Struts in the Java
web application space, I was invited to be on the initial expert group for JavaServer
Faces 1.0 (JSR-127). About a third of the way through that process, the original
spec lead stepped aside, and I assumed the spec lead role (and later on shared
this role with Ed Burns) through the initial 1.0 release. Subsequent to that,
I assumed a new role as architect for Sun Java Studio Creator (an IDE providing
a visual drag-and-drop experience for apps built with JavaServer Faces components).
At the same time, it became clear to me that JavaServer Faces, even though
it was primarily focused on UI components, was itself built on a front controller
architecture that provided many of the facilities of existing frameworks like
Struts. I wondered if it was reasonable to add just a little bit of code to
standard JSF, and be able to build webapps without needing a second framework
as well. That investigation turned into Shale.
KM: In a nutshell, can you explain what Struts Shale is?
CM: As JSF started to gain market acceptance, a common question
became "how can I use the cool JSF components with my existing applications
based on a framework like Struts?" This is indeed technically feasible;
for example, see the Struts-Faces integration library for Struts 1.x, or the
JSF integration plugins to the controller for Struts 2.x. But when you looked
at the resulting application, it looked a little odd ... basically you ended
up with a component framework (JSF) wrapping an action framework (Struts). And,
you now had two ways to do validation, two ways to do navigation, and so on.
Not very elegant.
In the initial design of JSF, we were constrained by timing issues to focus
mostly on getting the basic component APIs right, rather than on the framework
aspects (such as the request processing lifecycle). Therefore, we deliberately
provided a number of extension points where an application oriented framework
could plug in specialized functionality to add value (new features, ease of
use improvements, and so on) around the basic JSF controller. It turns out that,
with just a little bit of help, the controller part of JSF can provide pretty
much all of the functionality of an action oriented framework like Struts, while
not requiring you to combine two frameworks together.
The "little bit of help" that I had envisioned turned out to be Shale,
which leverages the extension points to provide things like application event
callbacks, dialog management (including a "dialog scoped" storage
that lasts longer than a request, but shorter than a session), an alternative
to JSP for rendering, and even a way to register managed beans with annotations
instead of XML configuration files. We even integrated technologies that were
familiar to Struts developers (such as Tiles and Commons Validator), and can
take advantage of Spring 2's integration with JSF without having to do much
of anything special, to round out the picture. And, because JSF provides all
of the basic support needed by an application framework, Shale can be provided
as a set of very thin layers on top; you just use what you need and skip the
rest. No more redundant implementations of things like how validation is done;
just do it the JSF way.
KM: What would you say are the three most useful features Shale provides?
CM: The three most useful features are:
- The view controller, which gives you application event callbacks that are
perfect for acquiring data from your model tier, and cleaning up afterwards.
- The dialog manager, which gives you support for "conversations"
with the user, including support for a "dialog" scope that is longer
than a request, but shorter than a session.
- The "clay" view handler, which lets you compose your own reusable
components without having to write Java code.
KM: When will a GA release of Shale be available, and what's in store
for the future?
CM: The current 1.0.4 version is looking fairly solid—I
would expect we'll be able to fix the small number of reported bugs against
it in fairly short order, so we can perhaps go GA with 1.0.5.
New feature development on the trunk (tentatively labeled 1.1.0-SNAPSHOT at
the moment) is featuring some usability improvements in the existing APIs, improvements
in the Tiles and Validator integrations, and other general improvements. I'd
also like to see us do more in the remoting area to provide a nice backend for
Ajax based clients.
KM: How does Shale relate to Struts 1.x and the Struts "Action
CM: Initially, Shale was developed inside the Struts project
at Apache. To help people understand that it really was a separate framework,
we labeled Struts 1.x as the "Struts Action Framework" so that the
term "Struts" wouldn't be quite so ambiguous. Later on, I pitched
to the Struts developers that Shale should be the direction we should go for
Struts 2.x. The community elected to go a different direction (merging with
the WebWork 2 framework, and creating what is now known as Struts 2.x), so last
summer Shale became its own top level Apache project (<http://shale.apache.org/>).
Because of that, we no longer needed the term "Struts Action Framework"
as such—now, it's just "Struts 1.x" or "Struts 2.x"
depending on which version you are using.
The Struts community seems likely to remain focused on an "action oriented"
or "command pattern oriented" architectural style, where you flow
all incoming requests through a processing pipeline (and in Struts 2, you can
customize the contents of the pipeline in quite interesting ways), while the
Shale community is focused on a "view helper" pattern that distributes
the controller functionality into multiple pieces, generally combining all of
the possible events for a logical section of your app into a single class for
easy development and maintenance. This idea is by no means unique to Shale—you
see similar patterns in frameworks as diverse as Microsoft ASP.Net and Ruby
This architectural style fits better with where I see web application development
going in the future, so my own open source activities (in this space) will be
focused on Shale rather than on Struts. However, if you are committed to Struts,
you need not worry—one of the marks of a successful open source project
is what happens when the original founder steps back, and I'm really proud of
the developer community that has grown up around Struts. It is in good hands.