Should immediate="true"
never be used when dealing with an AJAXified JSF 2.0 component?
The example might be:
If I want to implement a "Cancel" button on JSF 2.0 page where if the user hits "Cancel", no validations should run, should I set immediate="true"
on the component if it is an ajaxified component or should specify that no components on the form should be processed? If so, what is the way to implement this functionality using the AJAXified features of the component and not the "old way" of using immediate="true"
?
Indeed, the purpose of using immediate="true"
on a cancel button has become useless since <f:ajax>
which you can just set to execute="@this"
(which is the default already) to skip the processing of all input components in the same form.
You may only run into problems when the form was already been submitted beforehand but failed due to a conversion/validation failure. If you hit the cancel button by ajax and render the form thereafter, the inputs would still be marked invalid and any changes in the model value are not reflected (you're probably doing a entity = new Entity();
or something in cancel action method to clear out the old values of the form). This problem does not happen when using a synchronous (non-ajax) request with immediate="true"
. This issue has actually nothing to do with immediate="true"
, but with the JSF lifecycle of ajax requests. You basically need to reset the invalidated state of the involved input components by calling EditableValueHolder#resetValue()
on the components which are not included in the ajax execute
, but are included in the ajax render
. OmniFaces has a ResetInputAjaxActionListener
for exactly this purpose.
来源:https://stackoverflow.com/questions/10502326/should-immediate-true-never-be-used-when-dealing-with-an-ajaxified-jsf-2-0-com