Saving model state in ApplicationHandler (or where?)

Question

Where is the right place to save the state of a model bean during the request lifecycle? In the ApplicationHandler?
Suppose I have a form and want to persist the data to a database after the user submits the form (and validation is complete).
<jsp:useBean id="user" class="my.User" scope="session"/>
<faces:usefaces>
<faces:form id="simpleForm" formName="simpleForm">
<faces:textentry_input id="name" modelReference="user.name"/>
<faces:command_button id="submit" commandName="save"/>
</faces:form>
</faces:usefaces>
In my ApplicationHandler, I have:
User user = (User)(context.getHttpSession().getAttribute("user"));
boolean returnValue = false;
String treeId = null;
if (formEvent.getCommandName().equals("save")) {
user.save(); // update the database here?
treeId = "/faces/acknowledge.jsp";}
return returnValue;
This doesn't seem to work for me because the bean properties do not seem to be set from the form at this stage. I have to intervene with something like
user.setName(context.getServletRequest().getParameter("/simpleForm/name"));
to get the properties set from the form. (This doesn't seem right!)
Are the form values supposed to be applied to the model properties by the time the ApplicationHandler is called? If not, where is the right place to save the state of a model?
I'd rather not save state from the ApplicationHandler if possible. It'd be nice if after all the properties were automatically set in the model, some finalize method could be called to save state or otherwise process before the next page is displayed. Is there a way to do this?

Answer 1

Hi, I'm not yet an expert an JSF but aas far as my comprehension goes,
the lifecycle state for updating model values should be prior to the application events phase.
You can see this as well in the JSF spec chapter 2, where the "Update Model Values" phase comes prior to the "Invoke Application" phase.
From what you have written, I assume that you are interested in persisting the state of all UIComponents of a page, since there is a difference in saving state ob business objects or their corresponding components. The JSF spec seems to mention the possibility of persisting state automatically, which I think might be a very interesting and powerful feature. Such state should be persisted to a distributable cache so that clustered systems work fine with JSP and are at the same time capable of preserving user specific UI state accross all nodes.
However, I do not understand the concrete ideas of the tree-factory and I also do not yet understand, what exactly gets stored in the user session: whether only the current UI tree gets persisted there, or ALL trees that a user accesses during a session. The last scenario would not be so good, since clustered systems are often not capable of replicating more than 20K of session data without preformance degradation.
Renderers could save UIState by coding it into an html form param, but if this approach is not chosen, then I agree that I am also a little bit puzzled as to where and when and how UIComponents are to be persisted.
What I dislike is that UIComponents jsut have to implement the Serializable interface. Somehow I'd rather like the JSF people to address Serialization of UI components in a more general way. Java 1.4 comes with Long term beans persistance, other people might want to persist components to either databases or caching frameworks. There should be a more elaborate persistance approach for components in my view...