JSF 2 - Seam's Other Avenue to Standardization
Ajax for JSF now part of JSFAjax is nothing new. So it's about time we start calling it a standard (even if the W3C hasn't gotten around to it), right? Well, the foundation is finally in place. Ajax is now part of JSF!
But weaving Ajax into JSF is about more than just adopting a fad. The stateful UI component tree in JSF is an ideal candidate for communicating partial page updates to the client via Ajax. In JSF, the server maintains a representation of the view at all times. When a user interface event occurs, the server simply processes the relevant sections of the tree and pushes any changes in the tree's structure back to the browser. An Ajax bridge can then stitch the changes, in the form of HTML fragments, into the live view. A match made in Web 2.0 heaven.
Now, regardless of which Ajax feature a third party component library introduces, it should attach to this bridge to ensure compatibility and reduce disparate chatter with the server. RichFaces 4 will be designed around this API, for example. This Ajax bridge can be leveraged either by the components themselves or directly by the page author. For example, the Ajax functionality in RichFaces extends from the standard API. Jim Driscoll demonstrates in his blog how to bridge to the Open Ajax Alliance API.
To reiterate an earlier point, the defacto standards were blended together to form the Ajax support rather than the EG inventing yet another solution. For example, the familiar approach from Ajax4JSF of adding Ajax behavior to existing components evolved into the behaviors framework. The first standard implementation, <f:ajax>, is an adaptation of the <a4j:support> tag.
Validation is back in the right handsJSF has always had a comprehensive validation mechanism. However, when you look at the big picture, it's clear that the UI is the wrong place to define validations. That's because likely you are going to end up validating again in the business layer and perhaps a third time in the data access layer. Thus, the best solution is to centralize the validation constraints and have each layer enforce, rather than define, these constraints. The purpose of JSR-303: Bean Validation is to define a meta-data model and API for JavaBean validation. The meta-data model is declared using Java 5 annotations, with an option to describe them in XML as an alternative.
That leaves it up to JSF to enforce the Bean Validation constraints in the UI. JSF 2 integrates with Bean Validation using a built-in JSF validator. The validator enforces field-level constraints defined on the model properties that are bound to UIInput components. Consistent with the behavior of other JSF validators, this check occurs before the value is applied to the model.
The best part is, if Bean Validation is present, the validation takes place automatically, with no requirement to include special markup in the UI. Not only does the page author not have to worry about validation tags, there is no chance the constraints can get out of sync since they are read from the model. But that doesn't mean that the user will have to wait to see the violations. If Ajax is enabled for an input or a region of the page, the constraints will be enforced in almost real time.
Introducing the validator alone left a gap, though. In the past, JSF would not validate null or empty fields, making it impossible for Bean Validation to enforce these constraints. When Bean Validation is present, JSF defers the decision to validate a field in this state to Bean Validation.
Of course, developers may not always want the constraints to be enforced. Therefore, the integration allows the page author to disable the Bean Validation on a field or page region. Instead of disabling validation outright, the page author can alternatively choose which constraints are enforced by activating select validation groups for those regions.
Future goals of the Bean Validation integration are to offer true client-side validation that enforces the validation constraints defined on the model and to have a facility to accommodate multi-field validation--it's trickier than it appears at first.
When things go wrong, it's not always the user who is to blame. When a runtime exception occurs, it's important that JSF handle it appropriately. As many JSF developers have discovered in the early morning hours, sometimes when an exception occurs, you'd never know it.
Queue exceptions, don't swallow themIn JSF 1.2 and earlier, exceptions were frequently either swallowed or wrapped to the point where it was difficult to make out the root cause of the problem. JSF 2 introduces an ExceptionHandler, which is the central point for handling unexpected exceptions that are thrown during the JSF life cycle. The specification explicitly states that unexpected exceptions must not be swallowed, but rather queued and allowed to bubble up to the ExceptionHandler.
The default ExceptionHandler that must be provided by any JSF 2 implementation unwraps the root exception, rewraps it in a ServletException and throws it. This allows a developer to use the <error-page> directive in the web.xml descriptor to declaratively handle unexpected exceptions. Even before that point, the application has the opportunity to react to an unexpected exception by implementing an listener that observes the ExceptionQueuedEvent that is fired by the new system event infrastructure at the point the exception is trapped.
If the default behavior does not meet the application's requirements, then it's possible to provide a replacement ExceptionHandler. For instance, a substitute exception handler can be installed to handle a specific exception, as described in this article by Ed Burns, or delegate the the default resolver for all other exceptions. Another possibility is that a third-party framework can provide a generic exception handler that provides an alternative means of declaratively capturing and handling exceptions. A future goal for the exception handling intrastructure is to introduce a powerful, declarative configuration syntax for defining exception handling rules.
In addition to circumventing swallowed exceptions, Red Hat lobbied to eliminate many other "pet peeves" that remained in JSF 1.2.
Pet peeve raidThe biggest complaint about JSF is that it has a lot of little annoyances that tend to build up and lead to developer rage. Red Hat swept away as many of these as possible, and has plans on doing another cleaning the next revision of JSF. Here's a couple of the minor fixes that have been addressed so far:
- <f:selectItems> component capable of building a collection of SelectItems from any collection of objects
- Support for a "no selection option" in UISelectOne components
- varStatus attribute on <ui:repeat> (but not yet on all UIData components)
- Allow alteration of naming container separator character
All of the aforementioned improvements, whether big or small, can be traced back to community feedback. Regardless of how elegant the framework appears on paper, it must work in the enterprise and therefore it's the community feedback that will ultimately ensure JSF remains a successful and useful UI framework.
OpennessPutting technical concerns aside, one of the most notable advancements in JSF is the design process itself. Red Hat, Oracle, Sun, Apache and other key independent members of the JSF EG have continued to lobby to open up participation in the specification. Consequently, with each quarter that goes by, the JSR-314 specification takes another step towards openness. The goal is to get the community involved, give them a voice, and break away from the "closed door" practices that have driven the JCP and the Java EE community apart in the past.
Previous iterations of the JSF specification have lead the way by using an open issue tracker. JSR-314 took another step towards openness by introducing an open mailinglist viewable to any registered subscriber. Registration is open to the public. However, the aforementioned EG members are not yet content with the level of openness. Alternatives such as a second, read-write mailinglist open to the community and invitations for non-EG members with unique expertise in JSF to post to the primary EG list are being considered.
Not only does Red Hat want to bring openness to the JSR-314 specification, it strives to make JSR-314 a model for other JSRs to employ an open participation policy. Given how important the Java EE platform is to businesses worldwide, it's crucial that consumers be allowed to participate in how the platform is defined. The general philosophy is, the more experienced eyes reviewing it, the better the result. Since this philosophy mirrors that of Red Hat, it's understandable why Red Hat would lobby for this mode of operation in the JCP.
The JCP recently relaunched the JCP website as a community portal with registration open to the public. There are both open forums for each specification and a wiki that can be utilized by members. The JavaServer Faces EG has created a wiki book for brainstorming purposes. The problem so far is that there is no clear relationship between the open mailinglist and the forums and the wiki remains quite barren. So there is still work to be done, but the steps so far are encouraging.
Going beyond the bullet points
Although JSF 2 has been a long time coming, it has a lot to show for
it's time spent on the drafting table. A significant portion of the new
features in JSF 2 emerged from Seam as part of Red Hat's initiative to
standardize Seam. With the core programming model in Seam evolving into
JSR-299, that left Seam's JSF enhancements to find a home in JSR-314.
Because there are so many new features in JSF 2, covering them all in a single series is unreasonable. Therefore, this series focuses on the "big ticket" items that were contributed by Red Hat and its community. In return, the series will go beyond the bullet points of new features by explaining the motivation behind each feature and give an example of how the feature is used. The next article in this series will begin this deep dive by covering a particularly hot topic, view parameters and bookmarkable links. Stay tuned!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)