Shale: The Next Struts?
I'm at TS-7393 along with a pretty packed room of, I
estimate, 700+ attendees. All the sessions that I've gone to have
been well attended with a serious but enthusiastic-looking group of
folks it appears who ask smart questions in the Q & A's. The
session is titled "Shale: The Next Struts?" with Sabreware's David
Geary and Sun's Craig McClanahan. Craig is Strut's inventor and
David, Struts template tag library inventor, which was the
inspiration for creating Tiles, one of Struts most popular features.
Shale is the new kid on the block in the web application
frameworks space, with David and Craig being two of the three
leading original contributors on Shale. A lot of people want to
know: What's the deal with Struts and JavaServer Faces (JSF), and
Struts and Shale? A lot of uncertainty surrounds the topic. It is
impossible to predict where it is all headed
McClanahan presents the rationale for Shale. Shale is unique
among web application frameworks in that it starts by assuming
that JSF exists. Recognizing that with a little tweaking you can
turn JSF into a completely functional web app framework, he
decided to see if something as popular as Struts could be created.
So he proposed Shale as the architecture for Struts 2.0 to Struts
developers, which did not entirely sit well, given the focus on
backwards compatibility and support for existing Struts users.
They did accept Shale as a Struts sub-project, so it is officially part
of the Struts environment. The idea is to grow a community around
Shale that is already used to the idea of using web app frameworks
in developing. He is quick to point out that Shale has zero direct
relationship with the Struts 1.0 code. Shale is all new code based
on the assumption that JSF exists; it skips the step of re-
implementing the features that are already there, like validation
and request processing.
Features in Shale include web flow, so developers can
organize a dialogue that is longer than a request but shorter than a
session. There is client-side and server-side validation but with JSF
components. Shale is integrated with Spring to enable transparent
use of Spring's bean factory to create managed beans. David Geary
has been extracting Tiles out of the Struts core, so it is independent
of the underlying framework and can be used by any framework
more easily. Shale will take advantage of that. Primary subtrees is
another way to perform reuse that will function through a
specialized library called "Play". McClanahan pointed out that a
lot of people dislike Struts because it likes JavaServer Pages (JSP).
JSF likes JSP as well, but JSF has components as a Java API, and
developers can plug in a different view handler to use something
different. With Shale, they've created an environment that looks
like Tapestry with a standard HTML file for the markup
presentation. It has a test framework to make it easy to test the
view controller and other implementations.
He is quick to point out that, although they could use Shale to
create another JSF component library, that is not their goal. The
components they are creating are only ones that interact directly
with the framework's facilities. Anyone's JSF components will
work in Shale - why reinvent the wheel? The five tags within
Shale are: token tags to catch duplicate submits; a subview for
extra value-add services for a dynamically included page as well as
the main page; a commonsValidator tag used to integrate the
commonsValidator rules; a validator script so developers can
point to the Java script so they don't have to load it on every page.
and a clay tag used for parameterized subtrees.
JSF as an architecture has extension points that Shale takes
advantage of. The Spring integration is a custom variable resolver
and looks at the first word in an expression like
"customeraddress.city" -- if a customer does not exist will create
the bean for you. By default, JSF will look in the managed beans
definitions, but the extension checks for a bean factory as well.
Similar facilities enable access to the Java Naming and Directory
Interface (JNDI) context. The navigation management is
encapsulated in a specialized dialog navigation handler. A
specialized view handler enables developers to treat a Tile name as
a view ID to reduce work
So where is all this headed? McClanahan presents three
scenarios. First, it is possible that Struts developers will see that
Shale is becoming popular and choose it as Struts 2.0. Second, it
could become a separate Apache project - synergy exists with the
Apache MyFaces community that is building both an
implementation of JSF and some interesting components to go
with it. All of the JSF-related things could be encapsulated into a
single project. A third possible future is aware of how long it takes
to build a Java standard in the Java Community Process (JCP) -
almost two years to build JSF 1.0. Shale can be seen as an
experiment to see if its facilities make sense in a future JSF
release, perhaps in JSF 2.0 time frame. The future is unclear and
ultimately in the hands of developers.
An Interview with Craig McClanahan
David Geary's Blog
Craig McClanahan's Blog