State of Spring Web

For those that are interested, the following is a summary of the notes I captured from a conversation with SpringSource on the state of Spring Web:

Spring Faces

• Driving JSF in the context of the Spring MVC lifecycle
• All of the standard JSF components and component libraries work unchanged
• Bread and butter of JSF is its component model
  • Lifecycle for rendering and updating component tree
  • Could have different vendors integrating with the standard
• The faces servlet, the front controller code, etc., was not found by SpringSource to be particularly useful
• When you run a Spring Faces application, you're actually using the Spring Dispatcher Servlet.
• Spring MVC and Web Flow manage all controller responsibilities (request mappings, navigation rules, etc.)
• JSF handles view rendering responsibilities as a View implementation
• The focus of JSF going forward should be on enhancing its UI component model; specifically improving component interoperability, and ease of authoring new components
  
• The difference between Spring-centric and JSF-centric approach in SpringFaces is not in the JSF component model.

JSF-Centric Model

• JSF faces servlet drives everything, including mapping to views, etc.
• A view-driven approach.
• State is typically stored in HTTP session.
• When user initiates an event, the postback lifecycle is invoked.
• Ultimately that view decides whether to re-render or whether to delegate to a navigation handler to render a new view via faces-config.xml.
• Only Spring integration is that JSF views will be bound to Spring-managed beans for business logic.
• Downsides
  • You are limited to standard JSF navigation system
    • Can't go to views based on events
    • Difficult to modularize faces-config.xml if the modules are independent (but can have faces config fragments; extremely verbose)
  • State management not flexible (HTTP session only for every user)

Spring-Centric Model

• Web Flow becomes the navigation model by plugging into that JSF extension point.
• Architecture becomes controller-driven instead of view-driven
• All requests are routed through controllers, which make decisions about which views are rendered.
• What action-oriented developers are used to.
• Bringing model and view together, but handling what needs to be done in the controller.
• Benefits:
  • With Spring MVC, get full advantage of dispatcher servlet which allows you to customize how views are rendered via URLs
  • When controllers are invoked they can use input parameters to execute initialization logic to select the right view, etc.
    • With JSF out of the box, difficult to do initialization before view is rendered, and difficult to clean up after a view is rendered.
    • With Spring Faces, if there's a problem with handling a given request, instead of it being caught in the render cycle (which is difficult to recover from if you've already written out some of the response), you can catch an error before you render the view at all.

The Need for Control Logic / Spring MVC and Web Flow Bundling

• Either way (JSF-centric or Spring-centric) you need control logic.
  • In JSF, it's managed beans, so typically people have to go out anyway and get something like Shale to allow for initialization prior to rendering, etc.
• For people building components, nothing different between a JSF-centric approach and a Spring-centric approach.
• People that have to do the event handling have to know Spring MVC and Spring Web Flow. SWF could be theoretically incorporated into the JSF spec over time to handle events, drive transitions, etc.
• There is so much synergy between the two, it is not out of the realm of possibility that MVC and Web Flow could be combined in some future distribution of Spring focusing on web applications.
• There's a need for both technologies.
• Spring MVC will continue to exist, but the two products may merge at some point for developers to consume.

Benefits of Spring Web Flow

• More powerful navigational system
• Finer grained scopes (flow scope, view scope)
• Reduce amount of state that's stored traditionally with JSF
  • Works with a multi-window application
• Modularization of Web application
• Built-in Ajax event model for rendering partial page fragments after responding to Ajax events
• Spring MVC focuses on stateless, RESTful interactions

Spring MVC and Web Flow Contrasts

• JSF is stateful by nature, as is Web Flow by nature, so that you can execute all phases of the lifecycle within Web Flow
• With Spring MVC, only render phase can be executed. You cannot execute the postback lifecycle.
  • Might be able to address this in Spring MVC with custom form controllers, etc., but Web Flow provides this already with more power (flows can be changed without server having to be restarted)
  • You may see demand from clients to do more of the lifecycle within form controllers, but this hasn't emerged yet.

Spring JavaScript

• Spring JavaScript is bundled with Web Flow at the distribution level, but not at the module level.
• Spring JavaScript is not tied to Web Flow engine at all.
• It can integrate with Dojo components that aren't in Spring JavaScript.
  
• Spring JavaScript builds on Dojo 1.1 and can co-exist with other Dojo components.
  • The SpringSource Enterprise Bundle Repository, for example, uses Spring JS and Dojo 1.1 components outside of Spring JS, so they definitely work together (e.g. popup, query API, etc.)
• Would probably have to have another release of Spring JS when another major release of Dojo comes out.
• SpringSource provides an optimized build of Dojo to try to target the customers it serves (writing less JavaScript), without taking away power of underlying toolkit.