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'.
Related
Is the ui:fragment's rendered attribute evaluated during every phase in the JSF lifecycle. I am sure it is evaluated in the RENDER_RESPONSE phase as I would expect it to be, but isn't it also evaluated through APPLY_REQUEST_VALUES, PROCESS_VALIDATIONS, UPDATE_MODEL_VALUES and INVOKE_APPLICATION as well.
The reason is we render some ui:fragment based on data from the database. It is a tag we have authored. We only render the contents of the ui:fragment i.e the authored tag, if there is some data in the database. Is there some way to avoid all these calls and only do it once per request-response life cycle. This is what it looks like
<ui:fragment rendered="{some values exist in db}">
<ourtags:sometag>
</ui:fragment>
That depends on the children. If there are UIInput children, then it's also evaluated during apply request values, validations and update model values phases. If there are UICommand children, then it's also evaluated during apply request values and invoke application phases. This all is part of safeguard against forged requests wherein the enduser (read: hacker) attempts to manipulate the way the submitted data is processed.
As to the concrete problem, just don't do business logic in getter methods. Getter methods should not be interacting with the database. There they are not for. Getter methods should, as their name says, just return already-prepared data. You need to perform the business logic in bean's constructor or #PostConstruct method instead and assign it to a property. The getter method should merely return that property. Then it absolutely doesn't matter how often it's been invoked.
See also:
Why JSF calls getters multiple times
Why is the getter called so many times by the rendered attribute?
My page has Ajax show/hide functionality.
During the initial page load my bean methods that are inside a non rendered <f:subview> or <h:panelGroup> are not called. When re-render the #form using Ajax, my bean methods are getting called although the relevant subviews are not rendered. Is this what should happen? (I am using JSF 2.2)
This is the expected behaviour as per my comment above. Unfortunately it comes with some ugly behaviour.
If you an object that is doing anything when using the list, it will work fine on your first request. Even if you have taken your precautions say by loading something with f:event this will not save you on the following AJAX request.
Example:
If you use JPA with each bean managed for the scope of the request and that bean has a lazy collection that is not rendered this will cause the following:
Request 1: Non-rendered components will not be touched i.e. Lazy collections will not initialize
Request 2(Ajax): JSF will try to restore the full view calling your non-loaded lazy collection resulting to an exception.
When I call a method in a page with a param in its URI, the method is not invoked unless I pass the parameters of the uri again. For example if I have:
http://maywebsite/myapp/mypage.xhtml?mykey=myvalue
This method results in error (obviously because it renders the page again without params, but the method foo is never invoked):
<h:commandLink value="Do Action" actionListener="#{mybean.foo}"/>
So I added an ajax to only update the component, but the button is not getting fired:
<h:commandLink value="Do Action" actionListener="#{mybean.foo}">
<f:ajax render="somecomponent"/>
</h:commandLink>
When I passed the param values again, the button invokes the method just fine:
<h:commandLink value="Do Action" actionListener="#{mybean.foo}">
<f:param name="mykey" value="myvalue"/>
<f:ajax render="somecomponent"/>
</h:commandLink>
However, this button is included (ui:include) in many pages with different param keys and values. How can I invoke the method without passing the param values?
Im using glassfish 3.1.2, jsf 2.0
Apparently the bean is request scoped and the parameter plays a role in the way how the command link is rendered (e.g. by the rendered attribute on one of its parent components, or by a dynamic include of the template containing the command link).
All those conditions are namely re-evaluated during apply request values phase of the form submit. The developer has to make sure that all those conditions are exactly the same as when the form was presented to the enduser. So, when the bean is request scoped and the parameter is absent, then the command link appears as non-rendered in the component tree and this way its action won't be invoked.
Putting the bean in the view scope is the easiest way to fix this (unless you're using a dynamic <ui:include>, this is then more complicated, you'd need to turn off partial state saving for the particular view).
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not updated - point 5
Sometimes, if I click a commandButton that calls an action method, it will just do a page refresh without actually calling the method!
I set a breakpoint in that method and if this behavior takes place, the method is not called. What is also strange about it: It also does that if I didn't fill values in input components that have "required=true". I would expect that a valdiation error appears. The error appears only if the action method would be called fine. But not if it will just issue that strange page refresh.
The call looks pretty normal and works in most cases:
<h:commandButton value="Do something"
action="#{bean.doSomething(someBean.value)}" />
I can't exactly figure out when this behavior appears (and when not), but it should have something to do with the values chosen in some of the other components. But... how?
(I have two forms in a xhtml file. I just mention that because I don't know if it is important or not. However, there are no nested forms and h:messages displays nothing after page refresh.)
I'm using JSF 2 (MyFaces) + Tomahawk.
there are no nested forms and h:messages displays nothing after page refresh
You've likely a rendered attribute on the component or one of its parents which evaluated false during the processing of the form submit request. You need to ensure that it evaluates the same as it did during displaying the page. You can do this by putting the bean responsible for this in the view scope instead of the request scope.
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not updated
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.