Sometimes, when using <h:commandLink>
, <h:commandButton>
or <f:ajax>
, the action
, actionListener
or listener
method associated with the tag are simply not being invoked. Or, the bean properties are not updated with submitted UIInput
values.
What are the possible causes and solutions for this?
This question is related to
jsf
jsf-2
action
commandbutton
commandlink
I would mention one more thing that concerns Primefaces's p:commandButton
!
When you use a p:commandButton
for the action that needs to be done on the server, you can not use type="button"
because that is for Push buttons which are used to execute custom javascript without causing an ajax/non-ajax request to the server.
For this purpose, you can dispense the type
attribute (default value is "submit"
) or you can explicitly use type="submit"
.
Hope this will help someone!
Got stuck with this issue myself and found one more cause for this problem. If you don't have setter methods in your backing bean for the properties used in your *.xhtml , then the action is simply not invoked.
If your h:commandLink
is inside a h:dataTable
there is another reason why the h:commandLink
might not work:
The underlying data-source which is bound to the h:dataTable
must also be available in the second JSF-Lifecycle that is triggered when the link is clicked.
So if the underlying data-source is request scoped, the h:commandLink
does not work!
I had lots of fun debugging an issue where a <h:commandLink>
's action in richfaces
datatable
refused to fire. The table used to work at some point but stopped for no apparent reason. I left no stone unturned, only to find out that my rich:datatable
was using the wrong rowKeyConverter
which returned nulls that richfaces happily used as row keys. This prevented my <h:commandLink>
action from getting called.
This is the solution, which is worked for me.
<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
actionListener="#{userGroupSetupController.saveData()}"
update="growl userGroupList userGroupSetupForm" />
Here, process="userGroupSetupForm" atrribute is mandatory for Ajax call. actionListener is calling a method from @ViewScope Bean. Also updating growl message, Datatable: userGroupList and Form: userGroupSetupForm.
I fixed my problem with placing the:
<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
In:
<h:form>
<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
</h:form>
<ui:composition>
<h:form id="form1">
<p:dialog id="dialog1">
<p:commandButton value="Save" action="#{bean.method1}" /> <!--Working-->
</p:dialog>
</h:form>
<h:form id="form2">
<p:dialog id="dialog2">
<p:commandButton value="Save" action="#{bean.method2}" /> <!--Not Working-->
</p:dialog>
</h:form>
</ui:composition>
To solve;
<ui:composition>
<h:form id="form1">
<p:dialog id="dialog1">
<p:commandButton value="Save" action="#{bean.method1}" /> <!-- Working -->
</p:dialog>
<p:dialog id="dialog2">
<p:commandButton value="Save" action="#{bean.method2}" /> <!--Working -->
</p:dialog>
</h:form>
<h:form id="form2">
<!-- .......... -->
</h:form>
</ui:composition>
I recently ran into a problem with a UICommand not invoking in a JSF 1.2 application using IBM Extended Faces Components.
I had a command button on a row of a datatable (the extended version, so <hx:datatable>
) and the UICommand would not fire from certain rows from the table (the rows that would not fire were the rows greater than the default row display size).
I had a drop-down component for selecting number of rows to display. The value backing this field was in RequestScope
. The data backing the table itself was in a sort of ViewScope
(in reality, temporarily in SessionScope
).
If the row display was increased via the control which value was also bound to the datatable's rows
attribute, none of the rows displayed as a result of this change could fire the UICommand when clicked.
Placing this attribute in the same scope as the table data itself fixed the problem.
I think this is alluded to in BalusC #4 above, but not only did the table value need to be View or Session scoped but also the attribute controlling the number of rows to display on that table.
While my answer isn't 100% applicable, but most search engines find this as the first hit, I decided to post it nontheless:
If you're using PrimeFaces (or some similar API) p:commandButton
or p:commandLink
, chances are that you have forgotten to explicitly add process="@this"
to your command components.
As the PrimeFaces User's Guide states in section 3.18, the defaults for process
and update
are both @form
, which pretty much opposes the defaults you might expect from plain JSF f:ajax
or RichFaces, which are execute="@this"
and render="@none"
respectively.
Just took me a looong time to find out. (... and I think it's rather unclever to use defaults that are different from JSF!)
I had this problem as well and only really started to hone in on the root cause after opening up the browser's web console. Until that, I was unable to get any error messages (even with <p:messages>
). The web console showed an HTTP 405 status code coming back from the <h:commandButton type="submit" action="#{myBean.submit}">
.
In my case, I have a mix of vanilla HttpServlet's providing OAuth authentication via Auth0 and JSF facelets and beans carrying out my application views and business logic.
Once I refactored my web.xml, and removed a middle-man-servlet, it then "magically" worked.
Bottom line, the problem was that the middle-man-servlet was using RequestDispatcher.forward(...) to redirect from the HttpServlet environment to the JSF environment whereas the servlet being called prior to it was redirecting with HttpServletResponse.sendRedirect(...).
Basically, using sendRedirect() allowed the JSF "container" to take control whereas RequestDispatcher.forward() was obviously not.
What I don't know is why the facelet was able to access the bean properties but could not set them, and this clearly screams for doing away with the mix of servlets and JSF, but I hope this helps someone avoid many hours of head-to-table-banging.
One more possibility: if the symptom is that the first invocation works, but subsequent ones do not, you may be using PrimeFaces 3.x with JSF 2.2, as detailed here: No ViewState is sent.
Source: Stackoverflow.com