All the form submitted even if ajaxSingle or a4j:region used
Action/actionListener isn't called
Conditional components rendering
Passed parameter is null in actionListener
Can't use Navigation via a4j controls
All the form submitted even if ajaxSingle or a4j:region used
Yes, all the form submitted as usually. And only processing/conversion/validation/model values applying limited. Some time ago we tried to implement submitting not all the form for ajaxSingle components but the component values only - but then for example third party components which adds some hidden inputs processed in the thirdparties ViewHandlers becames broken. So we could not limit submitting itself without such side effects for the other libraries. So this approach can't be changed.
Ajax request not fired
1) At first RichFaces Ajax calls are made via the same form submit as for the standard h:command* controls. The first thing you should check is that you don't forget the form around your Ajax controls.
2) Also check for js errors. Ajax call are made by invoking utility js method. Hence, if some event handler e.g. is defined by application developer and called before the request rises errors, then Ajax call script will also not be invoked.
Action/actionListener isn't called
Add rich-messages to the page or phaseTracker to the application jars. 90% of such questions are caused by failed conversion/validation.
Conditional components rendering
Storing rendered between request
rendered property of the component should be kept the same between requests in order to work properly. So it should be placed into session scoped object. If you defined property to which rendered will be pointed in request scoped bean - it will not works. Request scoped bean recreated on every request so your changes made for previous instance will not really afftect the component state.
look there for sample: http://livedemo.exadel.com/richfaces-demo/richfaces/keepAlive.jsf;jsessionid=0F37C1DD9FDA7270387C0F71B5109B15?c=keepAlive&tab=usage
Except session scope usage - you could store the bean with keepAlive or use Seam long-running Conversations.
Client Side updates:
reRender attribute should not be pointed to conditionally rendered elements, because the framework has no idea where to add the element which wasn't in DOM before. Parents of such components should be reRendered instead.
Wrong usage:
<h:inputText id="myinput" value="#{userBean.name}">
<a4j:support event="onkeyup" reRender="outtext" />
</h:inputText>
<h:outputText id="outtext" value="#{userBean.name}" rendered="#{userBean.rendered}"/>
Should be
<h:inputText id="myinput" value="#{userBean.name}">
<a4j:support event="onkeyup" reRender="outtext" />
</h:inputText>
<a4j:outputPanel id="outtext">
<h:outputText value="#{userBean.name}" rendered="#{userBean.rendered}"/>
</a4j:outputPanel>
Passed parameter is null in actionListener
<a4j:support actionListener="#{userBean.actionListener}">
<aj4:actionparam name="param" value="param" assignTo="#{bean.param}">
<a4j:support>bean.param will be null in this case. It not a RichFaces problem, but the particularity of JSF action listeners invocations. According to JSF specification the component action listener is invoked and then nested actionListeners (defined withf:actionListener) should be fired. And actionparam works as jsf Action Listener. Thus, calling of the #{bean.actionLisntener} happens before the parameter is set. This problem can be resolved by moving the actionLisnter definition to the param tag or using nested <f:actionListener>
Should be
<a4j:support>
<aj4:actionparam name="param" value="param" assignTo="#{bean.param}"
actionListener="#{userBean.actionListener}">
<!-- OR <f:actionListener .../ -->
<a4j:support>In this case both listeners will access the param which is already set before a call.
Can't use Navigation via a4j controls
Actually a4j components was not designed to be used for navigation. Ajax should be used for partial page updates by design and we don't consider the navigation case. As you see, currently there are only three options to organize navigation via a4j controls:
- Using a4j:include. JSF navigation via ajax fully supported inside.
- Using ajax controls for </redirect> navigation cases. It could be used even without the include component.
- Non JSF navigation but just using include which src bound to some bean property and managing the src in actions with further reRender.
For all other cases standard JSF navigation should be used via h:command.
The question at forum often followed by "non-redirect navigation outside include works in FF but not works in IE" statements. Actually it could works somewhere, but is not designed to be used in this way.
Components Binding's usage
Scope of the object which holds bindings
Object which holds components bindings should not live longer than request. It's not defined directly in JSF 1.2 specification but speciication specifies that view should be rebuilt on each requests. Difefrent problem will occurs if you trying session scoped bindings - duplicate id's as most popular problem, concurrent calls to components in session and so on. It's not related to RichFaces anyhow but just JSF specific point. So if you still believe that you encountered that problems just because of RichFaces usage - visit any JSF knowledgebase resources and check for that.
keepAlive and Object which holds bindings
Such usage will have even worst results. Because beans stored with keep alive will be restored after restore phase. So your bean which holds binding will be instantiated on call to component creation and then after phase created component instance will be replaced with store with keepAlive one.
Client side updates failed
All the points above could be partially the reasons of that. E.g. actually request was not sent at all, or some server side updates was not occured in listeners, or DOM elements for conditionally rendered component was not found etc.. But after you checked all that stuff and believe that things goes fine but just DOM model not updated properly - please consult the ajax request log using a4j:log component to get the info about possible problem during client side updates. Refer to component documentation to learn how to use it.
Comments