commandButton / commandLink / ajax action / méthode d'écoute non invoquée ou valeur d'entrée non définie / mise à jour

Parfois, lors de l' utilisation <h:commandLink>, <h:commandButton>ou <f:ajax>la action, actionListenerou listenerméthode associée à l'étiquette sont tout simplement pas être invoquée. Ou, les propriétés du bean ne sont pas mises à jour avec les UIInputvaleurs soumises .

Quelles sont les causes et les solutions possibles à cela?

introduction

Chaque fois qu'un UICommandcomposant ( <h:commandXxx>, <p:commandXxx>, etc.) ne se réfère à la méthode d'action associée, ou un UIInputcomposant ( <h:inputXxx>, <p:inputXxxx>, etc.) ne parvient pas à traiter les valeurs soumises et / ou mettre à jour les valeurs du modèle, et vous ne voyez pas des exceptions googlable et / ou avertissements dans le journal du serveur, également lorsque vous configurez un gestionnaire d'exceptions ajax conformément à la gestion des exceptions dans les demandes ajax JSF , ni lorsque vous définissez le paramètre de contexte ci-dessous dans web.xml,

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
</context-param>

et vous ne voyez pas non plus d'erreurs et / ou d'avertissements googlables dans la console JavaScript du navigateur (appuyez sur F12 dans Chrome / Firefox23 + / IE9 + pour ouvrir la boîte à outils du développeur Web, puis ouvrez l' onglet Console ), puis parcourez la liste ci-dessous des causes possibles.

Causes possibles

1. UICommandet les UIInputcomposants doivent être placés à l'intérieur d'un UIFormcomposant, par exemple <h:form>(et donc pas du HTML simple <form>), sinon rien ne peut être envoyé au serveur. UICommandles composants ne doivent pas non plus avoir d' type="button"attribut, sinon ce sera un bouton mort qui n'est utile que pour JavaScript onclick. Voir aussi Comment envoyer des valeurs d'entrée de formulaire et appeler une méthode dans le bean JSF et <h: commandButton> n'initie pas de publication .

2. Vous ne pouvez pas imbriquer plusieurs UIFormcomposants les uns dans les autres. Ceci est illégal en HTML. Le comportement du navigateur n'est pas spécifié. Attention aux fichiers include! Vous pouvez utiliser des UIFormcomposants en parallèle, mais ils ne se traiteront pas lors de la soumission. Vous devriez également faire attention avec l'anti-modèle "Forme Dieu"; assurez-vous de ne pas traiter / valider involontairement toutes les autres entrées (invisibles) sous la même forme (par exemple, avoir une boîte de dialogue cachée avec les entrées requises sous la même forme). Voir aussi Comment utiliser <h: form> sur la page JSF? Formulaire unique? Plusieurs formulaires? Formes imbriquées? .

3. Aucune UIInputerreur de validation / conversion de valeur n'aurait dû se produire. Vous pouvez utiliser <h:messages>pour afficher tous les messages qui ne sont affichés par aucun <h:message>composant spécifique à l'entrée . N'oubliez pas d'inclure le idof <h:messages>dans le <f:ajax render>cas échéant, afin qu'il soit également mis à jour lors des requêtes ajax. Voir aussi h: messages n'affiche pas les messages lorsque p: commandButton est enfoncé .

4. Si UICommandou les UIInputcomposants sont placés à l' intérieur d' un composant itérer comme <h:dataTable>, <ui:repeat>, etc, alors vous devez vous assurer que exactement le même valuedu composant est itérer été conservée lors de la demande d' appliquer des valeurs phase du formulaire soumettre la demande. JSF réitérera dessus pour trouver le lien / bouton cliqué et les valeurs d'entrée soumises. Mettre le bean dans la portée de la vue et / ou vous assurer que vous chargez le modèle de données dans @PostConstructle bean (et donc pas dans une méthode getter!) Devrait le corriger. Voir aussi Comment et quand dois-je charger le modèle à partir de la base de données pour h: dataTable .

5. Si UICommandou les UIInputcomposants sont inclus par une source dynamique telle que <ui:include src="#{bean.include}">, vous devez vous assurer qu'exactement la même #{bean.include}valeur est préservée pendant le temps de génération de la vue de la demande de soumission de formulaire. JSF l'exécutera de nouveau lors de la construction de l'arborescence des composants. Mettre le bean dans la portée de la vue et / ou vous assurer que vous chargez le modèle de données dans @PostConstructle bean (et donc pas dans une méthode getter!) Devrait le corriger. Voir aussi Comment ajax-refresh dynamic inclure du contenu par le menu de navigation? (JSF SPA) .

6. L' renderedattribut du composant et de tous ses parents et l' testattribut de tout parent <c:if>/ <c:when>ne doivent pas être évalués falsependant la phase d'application des valeurs de demande de la demande de soumission de formulaire. JSF le revérifiera dans le cadre de la protection contre les demandes falsifiées / piratées. Le stockage des variables responsables de la condition dans un @ViewScopedbean ou la vérification de la préinitialisation correcte de la condition dans @PostConstructun @RequestScopedbean devrait le corriger. Il en va de même pour l' disabledattribut du composant, qui ne doit pas être évalué truependant la phase d'application des valeurs de demande. Voir aussi l' action JSF CommandButton non invoquée , la soumission de formulaire dans le composant rendu conditionnellement n'est pas traitée eth: commandButton ne fonctionne pas une fois que je l'ai enveloppé dans un <h: panelGroup rendu> .

7. L' onclickattribut du UICommandcomposant et l' onsubmitattribut du UIFormcomposant ne doivent pas renvoyer falseou provoquer une erreur JavaScript. Il ne devrait y avoir en cas <h:commandLink>ou <f:ajax>aucune erreur JS visible dans la console JS du navigateur. Généralement, googler le message d'erreur exact vous donnera déjà la réponse. Voir aussi L' ajout / chargement manuel de jQuery avec PrimeFaces résulte dans les TypeErrors Uncaught .

8. Si vous utilisez Ajax via JSF 2.x <f:ajax>ou par exemple PrimeFaces <p:commandXxx>, assurez-vous que vous en avez un <h:head>dans le modèle principal au lieu de <head>. Sinon, JSF ne pourra pas inclure automatiquement les fichiers JavaScript nécessaires qui contiennent les fonctions Ajax. Cela entraînerait une erreur JavaScript comme «mojarra n'est pas défini» ou «PrimeFaces n'est pas défini» dans la console JS du navigateur. Voir aussi h: commandLink actionlistener n'est pas invoqué lorsqu'il est utilisé avec f: ajax et ui: repeat .

9. Si vous utilisez Ajax, et les valeurs soumises finissent par être null, assurez - vous que les UIInputet UICommandcomposants d'intérêt sont couverts par le <f:ajax execute>ou par exemple <p:commandXxx process>, sinon ils ne seront pas exécutées / traitées. Voir aussi Valeurs de formulaire soumises non mises à jour dans le modèle lors de l'ajout de <f: ajax> à <h: commandButton> et Comprendre le processus / mise à jour PrimeFaces et JSF f: ajax exécuter / rendre les attributs .

10. Si les valeurs soumises finissent toujours par être nullet que vous utilisez CDI pour gérer les beans, assurez-vous que vous importez l'annotation de portée à partir du package correct, sinon CDI par défaut @Dependentrecréera efficacement le bean à chaque évaluation de l'EL expression. Voir aussi @SessionScoped bean perd l'étendue et est recréé tout le temps, les champs deviennent nuls et Quelle est l'étendue par défaut du bean géré dans une application JSF 2?

11. Si un parent du <h:form>avec le UICommandbouton a été préalablement rendu / mis à jour par une requête ajax provenant d'un autre formulaire de la même page, la première action échouera toujours dans JSF 2.2 ou une version antérieure. La deuxième action et les actions suivantes fonctionneront. Cela est dû à un bogue dans la gestion de l'état des vues, signalé comme problème 790 de spécification JSF et actuellement corrigé dans JSF 2.3. Pour les anciennes versions de JSF, vous devez spécifier explicitement l'ID du <h:form>dans le renderdu <f:ajax>. Voir aussi h: commandButton / h: commandLink ne fonctionne pas au premier clic, ne fonctionne qu'au deuxième clic .

12. Si le <h:form>a été enctype="multipart/form-data"défini pour prendre en charge le téléchargement de fichiers, vous devez vous assurer que vous utilisez au moins JSF 2.2 ou que le filtre de servlet qui est responsable de l'analyse des demandes en plusieurs parties / données de formulaire est correctement configuré, sinon la FacesServletvolonté finissent par ne recevoir aucun paramètre de demande et ne peuvent donc pas appliquer les valeurs de demande. La configuration d'un tel filtre dépend du composant de téléchargement de fichiers utilisé. Pour Tomahawk <t:inputFileUpload>, vérifiez cette réponse et pour PrimeFaces <p:fileUpload>, vérifiez cette réponse . Ou, si vous ne téléchargez en fait aucun fichier, supprimez complètement l'attribut.

13. Assurez-vous que l' ActionEventargument de actionListenerest un javax.faces.event.ActionEventet donc pas java.awt.event.ActionEvent, ce que la plupart des IDE suggèrent comme première option de saisie semi-automatique. Ne pas avoir d'argument est également mauvais si vous utilisez actionListener="#{bean.method}". Si vous ne voulez pas d'argument dans votre méthode, utilisez actionListener="#{bean.method()}". Ou peut-être que vous souhaitez réellement utiliser à la actionplace de actionListener. Voir aussi Différences entre action et actionListener .

14. Assurez-vous qu'aucun PhaseListenerou aucun élément EventListenerde la chaîne de demande-réponse n'a modifié le cycle de vie JSF pour ignorer la phase d'action d'appel en appelant par exemple FacesContext#renderResponse()ou FacesContext#responseComplete().

15. Assurez-vous qu'aucun Filterou Servletdans la même chaîne de demande-réponse n'a bloqué la demande de FacesServletquelque façon. Par exemple, des filtres de connexion / sécurité tels que Spring Security. Particulièrement dans les requêtes ajax qui se retrouveraient par défaut sans aucun retour sur l'interface utilisateur. Voir aussi Gestion des demandes Spring Security 4 et PrimeFaces 5 AJAX .

16. Si vous utilisez un PrimeFaces <p:dialog>ou un <p:overlayPanel>, assurez-vous qu'ils ont les leurs <h:form>. Parce que, ces composants sont par défaut par JavaScript déplacés à la fin de HTML <body>. Donc, s'ils étaient à l'origine assis à l'intérieur d'un <form>, alors ils ne s'asseoiraient plus maintenant dans un <form>. Voir aussi l' action p: commandbutton ne fonctionne pas dans la boîte de dialogue p:

17. Bug dans le framework. Par exemple, RichFaces a une " erreur de conversion " lors de l'utilisation d'un rich:calendarélément d'interface utilisateur avec un defaultLabelattribut (ou, dans certains cas, un rich:placeholdersous-élément). Ce bogue empêche la méthode du bean d'être invoquée lorsqu'aucune valeur n'est définie pour la date du calendrier. Le traçage des bogues du framework peut être accompli en commençant par un exemple de travail simple et en construisant la page de sauvegarde jusqu'à ce que le bogue soit découvert.

Conseils de débogage

Si vous êtes toujours bloqué, il est temps de déboguer. Côté client, appuyez sur F12 dans le navigateur Web pour ouvrir le jeu d'outils de développeur Web. Cliquez sur l' onglet Console pour voir le conosle JavaScript. Il doit être exempt de toute erreur JavaScript. La capture d'écran ci-dessous est un exemple de Chrome qui illustre le cas de la soumission d'un <f:ajax>bouton activé sans avoir <h:head>déclaré (comme décrit au point 7 ci-dessus).

Cliquez sur l' onglet Réseau pour voir le moniteur de trafic HTTP. Soumettez le formulaire et vérifiez si les en-têtes de demande et les données du formulaire et le corps de réponse sont conformes aux attentes. La capture d'écran ci-dessous est un exemple de Chrome qui montre une soumission ajax réussie d'un formulaire simple avec un seul <h:inputText>et un seul <h:commandButton>avec <f:ajax execute="@form" render="@form">.

(avertissement: lorsque vous publiez des captures d'écran à partir d'en-têtes de demande HTTP comme ci-dessus dans un environnement de production, assurez-vous de brouiller / masquer tous les cookies de session dans la capture d'écran pour éviter les attaques de piratage de session!)

Côté serveur, assurez-vous que le serveur est démarré en mode débogage. Mettez un point d'arrêt de débogage dans une méthode du composant JSF d'intérêt que vous attendez à être appelé lors du traitement de la soumission du formulaire. Par exemple, en cas de UICommandcomposant, ce serait UICommand#queueEvent()et en cas de UIInputcomposant, ce serait UIInput#validate(). Passez simplement par l'exécution du code et vérifiez si le flux et les variables sont conformes aux attentes. La capture d'écran ci-dessous est un exemple du débogueur d'Eclipse.

Si vous êtes à l' h:commandLinkintérieur d'un, h:dataTableil y a une autre raison pour laquelle cela h:commandLinkpourrait ne pas fonctionner:

La source de données sous-jacente qui est liée à h:dataTabledoit également être disponible dans le deuxième cycle de vie JSF qui est déclenché lorsque le lien est cliqué.

Donc, si la source de données sous-jacente est étendue à la demande, le h:commandLinkne fonctionne pas!

Bien que ma réponse ne soit pas applicable à 100%, mais la plupart des moteurs de recherche trouvent cela comme le premier succès, j'ai décidé de le publier néanmoins:

Si vous utilisez PrimeFaces (ou une API similaire) p:commandButtonou p:commandLink, il est probable que vous ayez oublié d'ajouter explicitement process="@this"à vos composants de commande.

Comme l'indique le Guide de l'utilisateur de PrimeFaces dans la section 3.18, les valeurs par défaut de processet updatesont les deux @form, ce qui s'oppose à peu près aux valeurs par défaut que vous pourriez attendre de JSF ordinaire f:ajaxou RichFaces, qui sont execute="@this"et render="@none"respectivement.

Ça m'a juste pris beaucoup de temps pour le découvrir. (... et je pense que c'est plutôt onclever d'utiliser des valeurs par défaut différentes de JSF!)

Je voudrais mentionner encore une chose qui concerne Primefaces p:commandButton!

Lorsque vous utilisez un p:commandButtonpour l'action qui doit être effectuée sur le serveur, vous ne pouvez pas l'utiliser type="button"car il s'agit de boutons poussoirs qui sont utilisés pour exécuter du javascript personnalisé sans provoquer de demande ajax / non-ajax au serveur.

À cette fin, vous pouvez distribuer l' typeattribut (la valeur par défaut est "submit") ou vous pouvez utiliser explicitement type="submit".

J'espère que cela aidera quelqu'un!

Je suis moi-même coincé avec ce problème et j'ai trouvé une autre cause à ce problème. Si vous n'avez pas de méthodes de définition dans votre bean de sauvegarde pour les propriétés utilisées dans votre * .xhtml, alors l'action n'est tout simplement pas invoquée.

J'ai récemment rencontré un problème avec une commande UIC n'appelant pas dans une application JSF 1.2 utilisant des composants IBM Extended Faces.

J'avais un bouton de commande sur une ligne d'une table de données (la version étendue, donc <hx:datatable>) et l'UICommand ne se déclencherait pas à partir de certaines lignes de la table (les lignes qui ne se déclencheraient pas étaient les lignes supérieures à la taille d'affichage de ligne par défaut).

J'avais un composant déroulant pour sélectionner le nombre de lignes à afficher. La valeur sur laquelle reposait ce champ était RequestScope. Les données qui soutiennent le tableau lui-même étaient dans une sorte de ViewScope(en réalité, temporairement dans SessionScope).

Si l'affichage des lignes a été augmenté via le contrôle dont la valeur était également liée à l'attribut de la table de données rows, aucune des lignes affichées à la suite de cette modification ne pourrait déclencher la commande UIC lorsque vous cliquez dessus.

Placer cet attribut dans la même portée que les données de table elles-mêmes a résolu le problème.

Je pense que cela est mentionné dans BalusC # 4 ci-dessus, mais non seulement la valeur de la table doit être définie à la vue ou à la session, mais également l'attribut contrôlant le nombre de lignes à afficher sur cette table.

J'ai également eu ce problème et je n'ai vraiment commencé à chercher la cause profonde qu'après avoir ouvert la console Web du navigateur. Jusque-là, je n'ai pas pu obtenir de messages d'erreur (même avec <p:messages>). La console Web a montré un code d'état HTTP 405 revenant du <h:commandButton type="submit" action="#{myBean.submit}">.

Dans mon cas, j'ai un mélange de vanilla HttpServlet fournissant une authentification OAuth via des facettes et des beans Auth0 et JSF réalisant mes vues d'application et ma logique métier.

Une fois que j'ai refactorisé mon web.xml et supprimé un servlet intermédiaire, cela a fonctionné "par magie".

En fin de compte, le problème était que le servlet intermédiaire utilisait RequestDispatcher.forward (...) pour rediriger de l'environnement HttpServlet vers l'environnement JSF tandis que le servlet appelé avant lui redirigeait avec HttpServletResponse.sendRedirect (.. .).

Fondamentalement, l'utilisation de sendRedirect () a permis au "conteneur" JSF de prendre le contrôle alors que RequestDispatcher.forward () ne l'était évidemment pas.

Ce que je ne sais pas, c'est pourquoi le facelet a pu accéder aux propriétés du bean mais n'a pas pu les définir, et cela hurle clairement de supprimer le mélange de servlets et de JSF, mais j'espère que cela aidera quelqu'un à éviter de nombreuses heures de tête- à-table-frapper.

J'ai eu beaucoup de plaisir à déboguer un problème où <h:commandLink>l'action de a richfaces datatablerefusait de se déclencher. La table fonctionnait à un moment donné mais s'est arrêtée sans raison apparente. Je n'ai laissé aucune pierre non retournée, seulement pour découvrir que j'utilisais rich:datatablele mauvais rowKeyConverterqui renvoyait des valeurs nulles que les richfaces utilisaient avec bonheur comme clés de ligne. Cela a empêché mon <h:commandLink>action d'être appelée.

Une autre possibilité: si le symptôme est que la première invocation fonctionne, mais pas les suivantes, vous utilisez peut-être PrimeFaces 3.x avec JSF 2.2, comme détaillé ici: Aucun ViewState n'est envoyé .

J'ai résolu mon problème de placement de:

<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>

Dans:

<h:form>
     <h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
</h:form>

C'est la solution, qui fonctionne pour moi.

<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
                    actionListener="#{userGroupSetupController.saveData()}" 
                    update="growl userGroupList userGroupSetupForm" />

Ici, l'attribut process = "userGroupSetupForm" est obligatoire pour l'appel Ajax. actionListener appelle une méthode à partir de @ViewScope Bean. Mise à jour du message de grognement, Datatable: userGroupList et Form: userGroupSetupForm.

<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>

Résoudre;

<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>