NFJS 1.3 - Shale: The next Struts "?"

This session was presented by David Geary who is one of the Shale developers along with Craig McClanahan (also Struts developer) and another colleague of his. Shale is an extension to JSF and Craig's proposal for Struts 2.0 although there is no connection between Struts and Shale. JSF lacks quite a few things (as mentioned by RC in the JSF Session) due to the rush in its development and Shale fills in those holes.

David's inclination towards Shale architecture over Struts was pretty obvious. Although it wasn't completely mentioned why choose JSF over Struts in the presentation nor was it brought up by any of the attendees, I found the following top ten reasons why prefer JSF over Struts on David's blog http://jroller.com/page/dgeary

1. Components
2. Render Kits
3. Renderers
4. Value Binding Expressions
5. Event Model
6. Extensibility
7. Managed Beans (Dependency Injection)
8. POJO Action Methods
9. JSF is the standard Java-based web app framework
10. There's only one Struts

However there was quite some discussion over the adversary between Shale and Struts. According to David, Struts architecture does not hold a very high place among the list of the best framework options around and offcourse JSF being the best one followed by Tapestry, Webwork, others and then Struts. Part of the reason is Struts is quite an 'old' architecture. According to Craig McClanahan (the founder of Struts) "Struts will become gradually less relevant for new application development unless it adopts JSF strongly". Craig is throwing away the framework that he built himself.

David covered the features that Shale provides and I will describe a summary of those. The presentation was based on a demo of a user profile (account) creation page and Shale on JSF was used to create the functionality. The Symposium CD contains all the code for the demo. The main features that Shale offers are:

• Web Flow
• Remote Method Calls
• These two are the basis for AJAX (Asynchronous JAvascript with XMLHttpRequest)
• Spring Integration, Shale works out of the box for Spring
• HTML Views
• Tiles Integration
• Using Tiles View handler (JSF extension point)
  
• Client and Server-side validation, JSF 1.1_1 does not provide any client side validation
• Utilities
• Back Button abuse
• File Uploads (may not happen)
• JNDI

There are three different paths that future Shale can take

• Struts 2.0? There has been a lot of push back on the dev forums and so it is unlikelyto happen
  
• A new Apache Project? Most likely scenario
• Absorbed by MyFaces?

JSF extension points are used to add objects in the JSF by specifying them in a config file which are then taken over by Shale and action is performed. Shale is currently under development although the current releases can be downloaded bundeled with Struts nightly releases. According to David, it will take a year to couple of years for this frame work to completely develop and now is the time to learn it. Offcourse they always want people to be contributing to its development. Five tags are provided in Shale's tag library.

• s:token
• s:subview (life cycle tags)
• s:commonsValidator (this tag can be embedded in JSF input tag)
• s:validatorScript (writes the java script for all the commonsValidator tags used)
• s:clay (lets you parametrize JSPs to be used for various beans to avoids repetition)

Tokens disallow the duplicate submission through the back-button (as also mentioned in the JSF session). Tokens can be used by adding the s:token tag to the form and embedding the error message in between.

JNDI objects can be accessed by using built-in jndi variables in the EL, and specifying the objects under JNDI.

Remote Method Calls are used for AJAX. Currently this feature only supports remotely generating XML by using Jakarta-Commons chains. Remote chain commands are defined in the config and a call is made from the server side using the command name. Java Script will be supported in the future.

Spring with Shale is easier than with JSF. Shale uses Spring's delegating variable resolver and accesses the Spring beans from JSF expressions. The implementation requires only the addition of shale-spring.jar to WEB-INF/lib

Shale can be used to provide extra support for Tiles with JSF. tiles tags are inserted in the shales subview tag and the views are specified as tiles. This allows to load tiles directly rather than specifying a jsp for each tile.

Shale provides both Client and Server-side Validation by using Commons Validator and Validator Script tags. A commonsvalidator tag is attached to the input component and a type (required, credit card, etc) can be specified. The validatorscript tag in the end then produces the Java Script necessary for validation at the client side. (Writing Custom Java Script methods was covered in the JSF session).

The idea of Retro Views comes from Tapestry. The idea is that HTML elements can reference the JSF components which are actually defined in XML (in clay-config.xml) . 'jsfid' attribute is used to tie the HTML elements to the JSF components. There are two modes for these views, the preview mode where the page can be referenced as .html extension and it enables the Graphic artists to work with the HTML part and the Runtime mode which is used by the developers and end time users and can be referenced with the .faces extension. There is a custom view handler in JSF that reads the corresponding html, renders the components and then displays the page.

Shale Web Flow is modeled after the Spring's Web Flow. it consists of Dialog, states and transitions. Dialogs are defined in /WEB-INF/dialog-config.xml and can be invoked with the JSF expression language.

Overall, I think it was a good intro session to the capabilities of Shale and what it adds to JSF. But I think it will be still a while before this framework can be used and definitely not till they decide what the future of Shale will be, Struts 2.0 or something new?