问题
Just when I thought I had understood immediate... *sigh*
Consider the following JSF page:
<h:inputText value=\"#{testBean.text}\" required=\"true\" />
<h:commandButton actionListener=\"#{testBean.doFoo}\" value=\"Do Foo\" />
<h:commandButton immediate=\"true\" actionListener=\"#{testBean.doBar}\" value=\"Do Bar\" /><br />
<h:outputText value=\"#{testBean.didSomething}\" />
And this backing bean:
public class TestBean {
private String didSomething = \"Nothing done yet\";
// + getter
public void doFoo() {
didSomething = \"Did foo!\";
}
public void doBar() {
didSomething = \"Did bar!\";
}
From all I read about immediate I would expect the following:
When trying to do foo while not providing a value for the input field, the action is never executed because during
processValidationsPhase
an error occurs, resulting in the page to be re-rendered directly after this phase with an error message. The value of thedidSomething
remains unchanged. (This works as expected)When trying to do bar while not providing a value for the input field, the action is executed during
applyRequestValuesPhase
because of the immediate attribute. The variabledidSomething
is changed. (This works as expected)
On what happens next, this description states:
\"A null return value (as outcome of the action method) causes processing to continue as normal, ie non-immediate components are validated then update-model is executed (if no validation errors occurred). For an action listener method that returns void, it is necessary to call facesContext.renderResponse(); if the normal flow is not desired.\"
From this I had the idea that processing continues as normal (as my action method does neither return an outcome nor force renderResponse()
), resulting in the same validation error. Only difference would be that it occurs after setting didSomething
. However, this does not happen. Instead, it feels like the site still skips all remaining phases, with the input field not being touched. It re-renders without error message.
Can someone explain to me where my understanding of how this works is amiss?
回答1:
With immediate="true"
on the button, the action is indeed invoked during apply request values phase and all the remaining phases are skipped. That's also the sole point of this attribute: process (decode, validate, update and invoke) the component immediately during apply request values phase.
All inputs which do not have immediate="true"
are ignored anyway. Only inputs which do have immediate="true"
are also processed, but this happens also during apply request values phase. Why should the remaining phases be invoked if everything has already taken place in the apply request values phase?
In the Debug JSF lifecycle article you can find the following summary which should enlighten when to (not) use the immediate"true"
:
Okay, when should I use the immediate attribute?
If it isn't entirely clear yet, here's a summary, complete with real world use examples when they may be beneficial:
If set in
UIInput
(s) only, the process validations phase will be taken place in apply request values phase instead. Use this to prioritize validation for theUIInput
component(s) in question. When validation/conversion fails for any of them, the non-immediate components won't be validated/converted.If set in
UICommand
only, the apply request values phase until with update model values phases will be skipped for any of theUIInput
component(s). Use this to skip the entire processing of the form. E.g. "Cancel" or "Back" button.If set in both
UIInput
andUICommand
components, the apply request values phase until with update model values phases will be skipped for any of theUIInput
component(s) which does not have this attribute set. Use this to skip the processing of the entire form expect for certain fields (with immediate). E.g. "Password forgotten" button in a login form with a required but non-immediate password field.
See also:
- Why was "immediate" attribute added to the EditableValueHolders?
来源:https://stackoverflow.com/questions/12960718/trying-to-understand-immediate-true-skipping-inputs-when-it-shouldnt