How does different phases of JSF lifecycle behave in a stateless view containing a form

486 views Asked by At

If I have a stateless view in JSF containing a form. How does the different phases will behave when I filled out the form and submit it? since the state of the view is not stored anywhere, how does the phases "appy request values", "update model" etc. will work now?

1

There are 1 answers

0
BalusC On

All phases of the JSF lifecycle will continue to run. Only the restore view and render response phases will behave a bit differently. The restore view phase will now only build the view, but not restore its state. The render response phase will now only render the view, but not save its state. That's basically it. All other phases behave exactly the same.

For the developer, the major difference is in how @ViewScoped beans will behave. They will in stateless views behave exactly like @RequestScoped beans. So you'd just make them @RequestScoped right away. Also, any programmatic changes to component tree's state will not be preserved for postback, but developers shouldn't programmatically manipulate the component tree anyway (e.g. binding, findComponent(), etc, that's all simply fishy).

Just treat such a form as if you can only use it with a @RequestScoped bean. In case you're binding conditional attributes like rendered, disabled and readonly to a bean property and are changing it via ajax on the same view, then you need to make sure that you reinitialize the same bean properties (read: view scoped state) during bean's @PostConstruct. JSF will namely as part of safeguard against hacked requests re-check them before applying the request values. One way is passing them through via hidden input fields and manually extracting as request parameters (you're basically reinventing what the javax.faces.ViewState did). But you should realize that this opens possibilities for hackers to manipulate them. This is especially harmful if e.g. the conditional rendering of an admin-only command button becomes dependent on a simple request parameter instead of the JSF view state this way (exaggerated example, but it should give the picture).

See also: