- Drop backwards compatibility. There is just too much work involved with supporting JSF 1.2 and too much good stuff coming up in Spring 3.1 to ignore.
- MVC annotations are king.
@RequestMappingseems to be the preferred approach for most people; lets only support this and keep any custom annotations to a minimum.
- Reduce dependencies. It’s nice to reuse stuff but this is an integration project so the less there is to integrate the better.
With this in mind I decided to take the
org.springframework.faces.mvc.JsfView class from Web Flow as my inspiration. This class works really well because it only deals with the
Controller remain entirely in the realm of Spring. The only problem with
JsfView is the lack of postback support. We need to somehow detect the difference between the initial request for a view and any subsequent JSF postback.
Thanks to Spring MVC having a very flexible architecture this is entirely possible. We can have multiple
HandlerAdapter beans registered with the
DispatcherServlet. To support JSF we need something high up in this chain that can detect and deal with postbacks, leaving anything that is not a postback to be dealt with in the usual way. Here is the general sequence of events:
user dispatcher @controller | /some/request | | |-------------------->| maps to | | |------------->| creates | | |------------> FacesView | | (/pages/file.xhtml) | | render | | |-------------------------------->| | | [Delegate to JSF] | response |<--------------------------------| |<--------------------| | | | | | /some/request | | (postback) | |-------------------->| postback handler | |--------->| | | [Delegate to JSF] | response |<---------| |<--------------------| | | | |
The postback handler has a couple of interesting problems to deal with. 1) How do we know we are a postback. 2) How do we know what view to restore. Obviously a postback will be a
HTTP POST operation, but we cannot blindly assume that all
POSTs are JSF postbacks. We also need to know what XHTML file to restore, but this file is based on a decision taken by the
@Controller of the last request.
The answer to both these problems is to write our own JSF
ResponseStateManager is part of JSFs state management infrastructure and is responsible for reading and writing component state. Usually JSF will save the state data in the HTTP session and write a hidden form field within the page so it can be restored later. Hooking into this mechanism we can write an additional field for MVC, the presence of the field lets us know that we have a postback and furthermore the value will let us know what XHTML file to restore.
With the postback handler in place we now have the best of both the Spring and JSF worlds. We can use
@RequestMapping annotations to build expressive URLs and JSF components to render complex web pages. If want to we can even return different Views for the same URL based on entirely different technologies (for example by inspecting the HTTP header we might decide to return a JSF page or a XML document).
If you want to look at postback handler code it is available here. The usual caveats of this being a moving codebase apply.
Reference: Integrating Spring & JavaServer Faces : MVC Nuts and Bolts from our JCG partner Phillip Webb at the Phil Webb’s Blog.
Java Platform, Enterprise Edition is a widely used platform for enterprise server programming in the Java programming language.
This book covers exciting recipes on securing, tuning and extending enterprise applications using a Java EE 6 implementation.The book starts with the essential changes in Java EE 6. Then they will dive into the implementation of some of the new features of the JPA 2.0 specification, and look at implementing auditing for relational data stores.They will then look into how they can enable security for their software system using Java EE built-in features as well as using the well-known Spring Security framework. They will then look at recipes on testing various Java EE technologies including JPA, EJB, JSF, and Web services.Next they will explore various ways to extend a Java EE environment with the use of additional dynamic languages as well as frameworks.At the end of the book, they will cover managing enterprise application deployment and configuration, and recipes that will help you debug problems and enhance the performance of your applications.