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?
相关问题
- Laravel Option Select - Default Issue
- java.lang.NullPointerException at java.io.PrintWri
- HTML form is not sending $_POST values
- How to use Control.FromHandle?
- h:selectOneMenu in p:dataTable doesn't submit
相关文章
- Show a different value from an input that what wil
- How can I detect/watch “dirty-status” of an angula
- Why form submit opens new window/tab?
- How to allow numbers only using f:validateRegex
- Setting Angular 2 FormArray value in ReactiveForm?
- JSF 2.0: ajax request when press ENTER
- Rails: Using form fields that are unassociated wit
- How to get the “value” of a FilteringSelect <se
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 likerendered
,disabled
andreadonly
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 thejavax.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: