JavaServer Faces 1.0 Early Access Draft (Page 4)

<< Page 3 (Request Event Handling)

Responses and State Saving

Section JSF 2.7 talks about the render response phase where the UIComponent Tree is used to generate the UI that is displayed to the user. In this phase, the default behavior is that the ViewHandler forwards the HttpServletRequest to the UIComponent Tree. This is done via the id of the UIComponent Tree, which is the URL of the resource to forward to.

How will applications be able to redirect to HTML pages? It doesn't seem possible in the current setup without creating UIComponent Trees for pages that don't contain JSF code and creating a ViewHandler that will redirect the request to this UIComponent Tree. Likewise, it seems very constricting to have the UIComponent Trees dictate the response page.

In order to remain conceptually correct, every page in an application is required to contain JSF code, whether it needs to or not. This seems like a large requirement for businesses with existing info-structure or that need to be redirected out of the J2EE application server to an ASP server, for example. Of course no one wants that, but it is a reality. The flow should be flexible enough to support forwards and redirects to any resource inside and outside the container.

Also, the requirement of forcing the UIComponent Tree to be saved to the response or the session is very ambiguous and raises questions like: How is the UIComponent Tree written to the response or session? Is this the same as simply rendering the response using the UIComponent Tree, which in effect writes the current state out to the page?

Likewise, it is very possible that when the UI is being rendered, the number of UIComponents on the page will vary (if a JSF tag is in a loop for example). This would make it impossible to save the state of the UIComponent Tree to the response or the session unless section JSF 2.1 accounted for the possibility that the saved Tree and the Tree described by the request parameters are the same size.

A larger issue then that of saving state is determining where the values for a UIComponent are retrieved from during the render response phase. This seems trivial and it could be said that the values simply come from the local values of the UIComponent that is being encoded. However, it is possible that application logic could very easily have changed a value in the Application's Model. This would require that the UIComponent's local value be updated from the Application's Model value.

The specification does not cover this issue and it must because it will determine whether or not the application logic or the JSF implementation will be responsible for this transfer.

The best solution to this problem would be to add another phase to the lifecycle called "Update Local Values" which is responsible for updating the UIComponent's local values from the Application's Model, if necessary. Or JSF could simply do away with the UIComponent's local values altogether in favor of a more MVC oriented system where the view is directly backed by the Application's Model, as I mentioned above.

>> Page 5 (Validation and Error Messages)

<< Back to Programming