commandLink/commandButton/ajax backing bean action/listener method not invoked (转)
Whenever an UICommand
component fails to invoke the associated action method or an UIInput
element fails to update the model value, and you aren't seeing any obvious exceptions/warnings in the server log, then verify the following:
-
UICommand
andUIInput
components must be placed inside anUIForm
component, e.g.<h:form>
, andUICommand
components must not havetype="button"
attribute (get rid of it, that's only for push buttons, not for submit buttons). -
You cannot nest multiple
UIForm
components in each other. This is namely illegal in HTML. Watch out with include files! You can useUIForm
components in parallel, but they won't process each other during submit. -
No
UIInput
value validation/conversion error should have occurred. You can use<h:messages>
to show any messages which are not shown by any input-specific<h:message>
components. Don't forget to include theid
of<h:messages>
in the<f:ajax render>
, if any, so that it will be updated as well on ajax requests. -
If
UICommand
orUIInput
components are placed inside an iterating component like<h:dataTable>
,<ui:repeat>
, etc, then you need to ensure that exactly the samevalue
of the iterating component is been preserved during the apply request values phase of the form submit request. JSF will namely reiterate over it to find the clicked link/button and submitted input values. Putting the bean in the view scope and/or making sure that you load the data model in@PostConstruct
of the bean (and thus not in a getter method!) should fix it. -
The
rendered
attribute of the component and all of the parent components should not evaluate tofalse
during the apply request values phase of the form submit request. JSF will namely recheck it as part of safeguard against tampered/hacked requests. Making the bean@ViewScoped
or making sure that you're properly preinitializing the condition in@PostConstruct
of a@RequestScoped
bean should fix it. The same applies to thedisabled
attribute of the component, which should not evaluate totrue
during apply request values phase. -
The
onclick
attribute of theUICommand
component and theonsubmit
attribute of theUIForm
component should not returnfalse
or cause a JavaScript error. There should in case of<h:commandLink>
or<f:ajax>
also be no JS errors in the document. In recent browsers you can press F12 to get the web developer toolset with the JS console. All JS errors will be logged there. Usually googling the exact error message will already give you the answer. -
If you're using JSF 2.x
<f:ajax>
on the command component, make sure that you have a<h:head>
in the master template instead of the<head>
. Otherwise JSF won't be able to auto-include the necessaryjsf.js
JavaScript file which contains the Ajax functions. This would result in a JavaScript error like "mojarra is not defined" in the JS console. -
If a parent of the
<h:form>
with theUICommand
button is beforehand been rendered/updated by an ajax request coming from another form in the same page, then the first action will always fail. The second and subsequent actions will work. This is caused by a bug in view state handling which is reported as JSF spec issue 790 and currently scheduled to be fixed in JSF 2.3. For older JSF versions, you need to explicitly specify the ID of the<h:form>
in therender
of the<f:ajax>
, or to use the script in this answer. -
If the
<h:form>
hasenctype="multipart/form-data"
set in order to support file uploading, then you need to make sure that you're using at least JSF 2.2, or that the servlet filter who is responsible for parsing multipart/form-data requests is properly configured, otherwise theFacesServlet
will end up getting no request parameters at all and thus not be able to apply the request values. How to configure such a filter depends on the file upload component being used. For Tomahawk<t:inputFileUpload>
, check this answer and for PrimeFaces<p:fileUpload>
, check this answer. Or, if you're actually not uploading a file at all, then remove the attribute altogether. -
Be sure that the
ActionEvent
argument ofactionListener
is anjavax.faces.event.ActionEvent
and thus notjava.awt.event.ActionEvent
, which is what most IDEs suggest as 1st autocomplete option. -
Be sure that no
PhaseListener
or anyEventListener
in the request-response chain has changed the JSF lifecycle to skip the invoke action phase by for example callingFacesContext#renderResponse()
orFacesContext#responseComplete()
. -
Be sure that no
Filter
orServlet
in the same request-response chain has blocked the request fo theFacesServlet
somehow.
My bet that your particular problem is caused by point 2: nested forms. You probably already have a <h:form>
in the parent page which wraps the include file. The include file itself should not have a <h:form>
. You can also fix it the other way round, ensure that the parent page does not have a <h:form>
around the place of the include file.
【推荐】FlashTable:表单开发界的极速跑车,让你的开发效率一路狂飙
【推荐】Flutter适配HarmonyOS 5知识地图,实战解析+高频避坑指南
【推荐】博客园的心动:当一群程序员决定开源共建一个真诚相亲平台
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 为什么PostgreSQL不自动缓存执行计划?
· 于是转身独立开发者
· C#.Net筑基-泛型T & 协变逆变
· dotnet 代码调试方法
· DbContext是如何识别出实体集合的
· 免费开源 .NET OpenCV 迷你运行时全平台发布
· 10亿订单如何分库分表?
· C# 的深度强化学习框架RL_Matrix
· 【Cursor保姆级教程】零基础小白从安装到实战,手把手教你玩转AI编程神器!
· 如何基于three.js(webgl)引擎架构,实现3D医院、3D园区导航,3D科室路径导航