Artist's Rendering of A Mojarra*
Friends, St. Louisans, Developers,
I come not to bury Struts, but to praise it.
Web frameworks have come a long way since we were writing HTML markup from the doGet() and doPost() methods in our custom Servlets and using distinctly non-MVC scriptlets in our JavaServer Pages.
Thank goodness, Craig McLanahan gave us Struts 1.x. With Struts 1.x we learned that MVC could be applied to web development. Struts introduced a lot of us to practical implementations of the Front Controller and Command design patterns with Struts ActionServlet dispatching preloaded (and optionally validated) Form Beans to our Struts Action command classes.
When Struts
was introduced, large and small organizations everywhere adopted it as the de facto standard Java web framework. Speakers flooded the conferences with tips and techniques on how to use Struts. Books sprang up everywhere. As of today, Amazon.com reports 150 books when searching for the keyword "Struts" in Computer and internet books.
Despite its goodness, we all sensed something was not quite right with Struts.
First, there was all of that inheritance / framework-coupling going on. Form beans weren't true POJOs; they needed to inherit from Struts' ActionForm. Our Action classes had to inherit from a Struts' Action. Action execute() methods required a Struts ActionMapping argument and had to return Struts' ActionForward objects.
Second, everything was just so coarse grained. A form bean had a single validator() method used to validate all the String fields of the form bean and one form bean was generally only useful for handling one screen. Why did we use String fields in our form beans? Craig McLanahan himself recommended type conversion not be performed in the form bean since any missing required field data or other 0th-order validations done in validate() would result in the re-rendering of the original view. He recommended type conversions and inter-field validations be deferred until the Action class processing once we knew all the data needed was present and basically sound. (I should note that validation was later improved with a separate API. Dynamic form beans improved the 1:1 ratio of form beans to screens.)
Finally, many common requirements like custom type conversion and validation had to be handled individually each time they were needed. Consider a date entry. First, we need to convert the String representation of the date to a type like java.util.Date. We need to ensure the date is a valid date (i.e. no February 29th in 2010 or June 31st ever). Finally, we need to apply our own business rule validations. Perhaps in one context, the data must be before today; in another, the date must be in the future. The latter type of validation is truly business specific, but the conversion to/from a String and basic validation is common in all cases. Yet Struts offered little for us in this regard. Want to report errors from these conversions and validations? We had to handle this somewhat mechanically.
No one recognized these deficiencies and others more than Craig McLanahan. So when he set out to redesign the next big web framework, he did so as a co-spec lead for JavaServer Faces, JSR-127, in the Java Community Process (JCP). Craig's magic touch seemed to fail when he launched the Apache Shale framework, based on JSF 1.0/1.1. Originally, he tried to call Shale Struts 2.0, but the Struts villagers gathered their rhetorical pitchforks and torches and marched on Castle McLanahan. So he moved ahead with the project as Shale. It was a bust and has since been retired. However, there is a new Struts 2.0, based on WebWork 2.2.
Despite Shale's failure, JavaServer Faces (JSF) did catch on, becoming the official Java Enterprise Edition (JEE) web framework as of JEE5. Amazon reports 43 JSF books, with several new titles out or soon to be out.
JavaServer Faces, often just called Faces, sought to correct many of the deficiencies of Struts 1.x while retaining the essential goodness of Struts' MVC enforcement and implementation of Front Controller and Command design patterns.
In JSF 1.x, we were introduced to POJO managed beans performing the combined role of Struts form beans and actions. We got a lightweight, reusable Converter API for transforming Strings to more useful object types so now we can reuse the same converters across our application. The Validator API provides a simple, reusable mechanism for doing robust field-level validation. Both the converter and validation APIs provide easy ways to register messages into Faces' built-in error reporting and localization APIs.
Its well defined API and request processing life-cycle opened the door to an alternate implementation, MyFaces, from Apache. as well as several robust JSF widget libraries, including MyFaces Tomahawk (works with RI and MyFaces) and RichFaces, a JBoss subproject. (No JBoss server required.)
So given that JSF is here to stay...
What's Ahead In JavaServer Faces 2.0?
JavaServer Faces 2.0, available today, introduces a plethora of great enhancements. Our meeting on June 1st will highlight these improvements, comparing and contrasting JSF 2.0 with 1.x and Struts. Through code examples and live coding, topics to be covered will include:
- A Brief Introduction to JSF
- Improved navigation handling
- Multi-component validation
- Say Hello to Facelets; Good bye to JSP!
- Easy Ajax
- Managing Resources
- Improved Event Handling
- A Sneak Peek of RichFaces 4.0
- Third-party Support for JSF 2.0: Spring Faces,IDE Support, and more ...
Even if your shop is not using JSF today, you will want to attend to learn about what Faces can offer and how it solves some common problems in Java web development. So RSVP today!
Presenter: Jack Frosch
Sponsor: Adaptive Solutions Group
Meeting Notes: coming soon ...
* Project Mojarra is the code name for the JavaServer Faces Reference Implementation. Mojarra is a Caribbean fish.
Comments