lifecycle saveview

[Jorge Fiallega]

Hello. I am trying to understand the lifecycle of JSF. Can somebody explain the following very simple behaviour:

I create a UIInput component and a UICommand to go with it


<h:inputText id="name">
</h:inputText>

<h:commandButton value="submit Here"
action="success"></h:commandButton>

The "success" action brings you back to the same page.

I would think that in the "apply request value" phase, if I enter lets
say "Peter" in the inputText, it would save "Peter" in the value for the inputText Component. No Backing bean associanted,so nothing to do in the "Update Model Values" phase. When the view is rendered in the "Render Response" page, I would think that "Peter" should be the value display in the page since it was saved in the "Apply Request Values" phase. Nevertheless is empty.

If I run the same code but now with an association to a backing bean property:

<h:inputText id="name" value="#{inbox.name}">
</h:inputText>

<h:commandButton value="submit Here"
action="success"></h:commandButton>

The page coming back contains "Peter" as I would have expected to happen, not only in this case but in the previous case.

I believe I have a big confusion on when do the component values get in sync with the model values. In the books it shows very simple. Component values get updated in Apply Request Values, and everything is synch in Update Model Values. But what happens if the model values or the component values are changed in the Invoke Application Phase. Do they get resync before it is rendered and sent back?
The only explanation that I can come up to my observation above is that prior to rendering the model and the component get resync and since there was not model, the value of the component gets reset to null.

Any help would be greatly appreciated since a lot of my JSF question have to do with this issue.

Thanks a lot

Jorge

[Varun Khanna]

Ideal situation i.e. request sent -- validation performed -- <(and if successful)> -- model updated -- and page rendered with updated values.

But you can play around with this cycle. You can change the values submitted in request, you can update model in apply request phase itself and directly move to render response (bypassing validation phase) or you can even change the model bean AFTER update model phase ...

It's all flexible and in your hand.

[Varun Khanna]

Originally posted by Jorge Fiallega:
In the books it shows very simple. Component values get updated in Apply Request Values, and everything is synch in Update Model Values.

No, in apply request phase component value isn't updated.

In apply_request_phase a) the request value is put into some temp variable b) value is validated thereafter in validation phase c) and if validation is successful only then the model bean is updated in update_model_phase.

[Jorge Fiallega]

> In apply_request_phase a) the request value is put into some temp variable > > b) value is validated thereafter in validation phase c) and if validation is > successful only then the model bean is updated in update_model_phase.

So, I still don't see at which point does the component value is saved, or is never saved and the value only exists in the model bean?

Thanks

Jorge Luis

[Varun Khanna]

Originally posted by Jorge Fiallega:
[QB
So, I still don't see at which point does the component value is saved, or is never saved and the value only exists in the model bean?
[/QB]

Not sure what you are asking here

In apply_request phase, component tree is created for UIViewroot. The value each component holds is not it's final value but it's just the component's "submitted value".

In validation_phase, the submitted value is validated for each component.

In update_model phase, if the validation of submitted value was successful, updateModel() method is called on each component in the tree and this method call updates the final value of each component by modifying the property it's bound to in the backing/model bean.

If the property can't be set, an error message is queued and the FacesContext renderResponse( ) method is called.


Hope it helps.
[ May 27, 2005: Message edited by: Varun Khanna ]