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 Framework"?

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 on Rails.

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.

Page:  1   2   3   4