HI,
I have a doubt on setting the immediate attribute for the command button. I would like to know what will be the changes in the life cycle?
I have read that setting immediate attribute will call the action listener or action methods in the apply request values phase. My doubts is it only the difference of preponding the phase. Also it will execute the all the business logic in the action methods regardless of setting the immediate attribute.
Please clarify my doubts.
If immediate="true" is set in an UICommand component, then the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s) in the same UIForm. Use this to skip the entire processing of the form. E.g. "Cancel" or "Back" button.
If immediate="true" is set in both UIInput and UICommand components in the same UIForm, then the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s) in the same form 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
Debug JSF lifecycle
Related
I have a commandLink which has a "rendered" which is calculated based on values in a #RequestScoped bean. The commandLink uses f:ajax to call a listener but it appears that the method is never executed.
It turns out if I set rendered="#{true}" or no rendered attribute at all, the listener is executed properly. Is it possible that because the rendered is based on request scoped values which no longer exist at the time of the ajax postback (and hence result in a 'false'), that the listener is being skipped? Note that the f:ajax also performs a few execute actions which are performed successfully.
You should never use a request scoped bean to define the value of a rendered attribute of any UI component. Unless you take special care, the original bean is destroyed losing its values, a new one is created instead with each request. Thus the component will be hidden as the rendered attribute value is most probably not evaluated to true for the next request.
You should use the view scope instead for your bean. See an example here, but you should easily find other examples searching for something like 'jsf rendered attribute request scope bean'.
Initially immediate flag was only intended for ActionSource interface. But later on it was added to the EditableValueHolder interface also. What was the reason for design decision ?
It's to be used to prioritize validation on several EditableValueHolder components in the same form.
Imagine a form containing input components with immediate="true" as well as input components without this attribute. The immediate inputs will be validated during apply request values phase (which is one phase earlier than usual). The non-immediate inputs will be validated during validations phase (which is the usual phase). If validation fails for at least one of the immediate inputs, then the non-immediate inputs won't be converted/validated at all and thus won't generate any conversion/validation error messages. This is particularly useful in forms with complex validation rules where it doesn't make sense to validate component Y when validation for (immediate) component X has failed anyway.
When used in combination with immediate="true" on a command button in the same form, this will cause all non-immediate inputs being completely skipped. A good real world example is a login form with 2 fields "username" and "password" with required="true" and 2 buttons: "login" and "password forgotten". You could put immediate="true" on the "username" field and the "password forgotten" button to skip the required="true" check on the password field.
In the dark JSF 1.x ages, the immediate="true" was also often (ab)used as a hack in combination with valueChangeListener and FacesContext#renderResponse(), more than often in cascading dropdown lists. Long story short, here's an old blog article on that. To the point, it enables developers to execute a backing bean method on change of a <h:selectOneMenu> without that all other inputs in the same form are been validated. But these days, with the ajax awesomeness, this hack is unnecessary. You can find a concretre example of this case at the bottom of our <h:selectOneMenu> wiki page.
These days, the immediate="true" is still often (ab)used in order to have a specific button which completely bypasses all other inputs, such as a logout button in a "God-form" antipattern (whereby everything is been thrown together in a huge <h:form>), or a cancel button which incorrectly submits the form. Such a button would break when you start to actually need the immediate="true" the right way on one of the inputs. You'd better put such a logout button in its own form, or to change it to process only itself (process="#this" in PrimeFaces). And you'd better change such a cancel button to just refresh the page synchronously by <h:button value="Cancel" />. This works fine if the form is tied to a request/view scoped bean and browser caching is disabled on dynamic pages.
See also:
Should immediate="true" never be used when dealing with an AJAXified JSF 2.0 component?
Trying to understand immediate="true" skipping inputs when it shouldn't
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 the didSomething 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 variable didSomething 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?
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 the UIInput 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 the UIInput component(s). Use this to skip the entire processing of the form. E.g. "Cancel" or "Back" button.
If set in both UIInput and UICommand components, the apply request values phase until with update model values phases will be skipped for any of the UIInput 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?
I am new to JSF framework and Facelets as view, I am stuck with a problem now. I have got a page where i show some dropdown menu using <h:selectOneMenu> tag. On each selection i used to fire an ajax event using <f:ajax> event it all are working fine. But my problem is, if i select an option 2 on a select box and if I reloads the page again that particular select box will be selected with option 2 by default. I dont need this. I have to reload the select boxes along with page refresh. Please help me to solve this issue.
The selectbox shows the option that is set in the backing bean (and bound by the value attribute of <h:selectOneMenu>). The behavior after a page refresh depends on the scope of your backing bean. If it is session scoped, a page refresh doesn't reset the bean. You could change the scope to #ViewScoped to get the desired behavior. The bean then will be recreated after a full request.
Just set null to backing bean property that used in selectonemenu value after the selected action or set default value in property get method.
HI,
I have a doubt on calling the ActionListener method in the JSF beans. For example every request or submission of JSF form is gone through the life cycle of six phases. But, when we are triggering the particular event like action listener or value change listener, is there any lifecycle associated with that request?
Please clarify me.
Any action listener is invoked during invoke action phase, before the real action method. Which action listener methods are to be invoked are determined based on the actionListener attribute of the UICommand component which is associated with the submit.
Any value change listener is invoked during validations phase (or apply request values phase when immediate="true" for the particular UIInput component) after a succesful conversion/validation of the submitted value and only when the submitted value differs from the initial value. Which value change listener methods are to be invoked are determined based on the valueChangeListener attribute of the UIInput components which are associated with the submit.
And no, they do not have their own lifecycle. When they finish executing and return, it's still inside the same phase of the lifecycle. After invoking the valueChangeListener, JSF will continue with conversion/validation of the next UIInput component, or if there are none, then proceed to the next phase. After invoking the actionListener, JSF will continue with the next actionListener or if there are none, invoke the real action method.
Update: after reading your comments again, I think that I now see your doubt about particularly the value change listener. You seem to think that it by default immediately fires a brand new request to the server side during the client side change event. It does that not by default. You can only achieve this by adding a little piece of JavaScript code which submits the entire HTML form during the change event of the HTML input field.
onchange="this.form.submit()"
This part has nothing to do with JSF. It's a simple HTML attribute. Open the page in webbrowser, rightclick and choose View Source. You'll see that it's there. Disable JavaScript in your browser or remove it in JSF code and you'll see that it won't work anymore. You would need to press the submit button yourself to get it all to run.