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

Introduction

chaque fois qu'un composant UICommand ( <h:commandXxx> , <p:commandXxx> , etc) ne parvient pas à invoquer la méthode d'action associée, ou un composant UIInput ( <h:inputXxx> , <p:inputXxxx> , etc) ne traite pas les valeurs soumises et/ou ne met pas à jour les valeurs du modèle, et vous ne voyez pas d'exceptions et/ou d'Avertissements googlables dans le journal du serveur, pas plus que lorsque vous configurez un gestionnaire d'exception ajax comme par exemple traitement des exceptions dans les JSF ajax demande , ni lorsque vous définissez le paramètre de contexte 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 la Console onglet), puis travaillez à travers la liste ci-dessous des causes possibles.

causes possibles

Les composants

1. UICommand et UIInput doivent être placés à l'intérieur d'un composant UIForm , par exemple <h:form> (et donc pas simplement HTML <form> ), sinon rien ne peut être envoyé au serveur. Les composants UICommand ne doivent pas non plus avoir l'attribut type="button" , 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 invoquer une méthode dans JSF bean et ne prend pas l'initiative d'une publication .

2. Vous ne pouvez pas imbriquer plusieurs "1519100920," les éléments les uns dans les autres. Cette pratique est illégale en HTML. Le comportement du navigateur n'est pas spécifié. Attention à inclure des fichiers! Vous pouvez utiliser les composants UIForm en parallèle, mais ils ne seront pas traités les uns les autres pendant la soumission. Vous devriez également faire attention avec "forme de Dieu" antipattern; assurez-vous que vous ne faites pas involontairement traiter/valider toutes les autres entrées (invisibles) dans la même forme (par exemple avoir un dialogue caché avec les entrées nécessaires dans la même forme). Voir aussi comment utiliser dans la page JSF? Le formulaire unique? Plusieurs formulaires? Des formes imbriquées? .

3. No UIInput une erreur de conversion/validation de la valeur aurait dû se produire. Vous pouvez utiliser <h:messages> pour afficher tous les messages qui ne sont pas affichés par une entrée spécifique <h:message> composant. N'oubliez pas d'inclure le id de <h:messages> dans le <f:ajax render> , s'il y a lieu, afin qu'il soit mis à jour sur les requêtes ajax. Voir aussi h: les messages n'affichent pas les messages lorsque p:commandButton est appuyé sur .

4. si UICommand ou UIInput composants sont placés à l'intérieur d'un composant itératif comme <h:dataTable> , <ui:repeat> , etc, alors vous devez vous assurer que exactement le le même value de la composante itérative est conservé pendant la phase d'application des valeurs de la demande du formulaire soumettre la demande. JSF répétera dessus pour trouver le lien/bouton cliqué et les valeurs d'entrée soumises. Mettre la fève dans le champ de vision et / ou s'assurer que vous chargez le modèle de données dans @PostConstruct de la fève (et donc pas dans une méthode getter!) devrait résoudre le problème. Voir aussi comment et Quand dois-je charger le modèle à partir de la base de données pour h:dataTable .

5. si UICommand ou UIInput composants sont inclus par une source dynamique telle que <ui:include src="#{bean.include}"> , alors vous devez vous assurer que exactement la même valeur #{bean.include} est conservée pendant le temps de construction de la vue de la requête submit. JSF va le réexécuter pendant la construction de l'arbre des composants. Mettre la fève dans la portée de vue et/ou en s'assurant que vous chargez le modèle de données dans @PostConstruct de la fève (et donc pas dans un getter la méthode!) devrait résoudre le problème. Voir aussi comment faire pour ajax-rafraîchir dynamique inclure le contenu par menu de navigation? (JSF SPA) .

6. l'attribut rendered du composant et de tous ses parents et l'attribut test de l'un quelconque des parents <c:if> / <c:when> ne doivent pas être évalués à false au cours de la phase appliquer les valeurs de la demande du formulaire soumettre la demande. JSF la revérifiera dans le cadre de la protection contre trafiqué piraté demandes. Stocker les variables responsables de la condition dans un haricot @ViewScoped ou en s'assurant que vous êtes correctement préinitialiser la condition dans @PostConstruct d'un haricot @RequestScoped devrait le fixer. Il en va de même pour l'attribut disabled du composant, qui ne devrait pas être évalué à true pendant la phase appliquer les valeurs de requête. Voir aussi JSF CommandButton action non appelée et soumettre le Formulaire dans certaines conditions le composant Rendu n'est pas traité .

7. l'attribut onclick du composant UICommand et l'attribut onsubmit du composant UIForm ne doivent pas retourner false ou causer une erreur JavaScript. Dans le cas de <h:commandLink> ou <f:ajax> , il ne doit pas y avoir d'erreurs JS visibles dans la console JS du navigateur. Habituellement googler le message d'erreur exact vous donnera déjà la réponse. Voir aussi L'ajout de jQuery à PrimeFaces donne lieu à une erreur de typographie non corrigée à tous les endroits .

8. si vous utilisez Ajax via JSF 2.x <f:ajax> ou p.ex. PrimeFaces <p:commandXxx> , assurez-vous que vous avez un <h:head> dans le modèle maître au lieu du <head> . Sinon JSF ne sera pas en mesure d'auto-inclure les fichiers JavaScript nécessaires qui contiennent les fonctions Ajax. Il en résulterait une erreur JavaScript comme "mojarra est pas défini" ou "PrimeFaces n'est pas défini" dans le navigateur JS console. Voir aussi h: commandLink actionlistener n'est pas invoqué lorsqu'il est utilisé avec f:ajax et ui:repeat .

9. si vous utilisez Ajax, assurez-vous que les composants UIInput et UICommand d'intérêt sont couverts par le <f:ajax execute> ou par exemple <p:commandXxx process> , sinon ils ne seront pas exécutés/traités. Voir Aussi soumis valeurs du formulaire Non mises à jour dans le modèle lors de l'ajout de à et comprendre les PrimeFaces processus/mise à jour et JSF f:ajax exécuter/rendre attributs .

10. si un parent du <h:form> avec le bouton UICommand est préalablement Rendu/mis à jour par une demande ajax provenant d'un autre formulaire dans la même page, alors la première action sera toujours un échec. Le deuxième et les suivants les actions fonctionneront. Ceci est causé par un bug dans le traitement d'état de vue qui est rapporté comme JSF spec issue 790 et actuellement prévu pour être corrigé dans JSF 2.3. Pour les versions JSF plus anciennes, vous devez spécifier explicitement L'ID du <h:form> dans le render du <f:ajax> . Voir aussi h:commandButton/h:commandLink ne fonctionne pas sur le premier clic, fonctionne seulement sur le deuxième clic .

11. si le <h:form> a enctype="multipart/form-data" défini afin de prendre en charge le téléchargement de fichiers, alors vous devez vous assurer que vous utilisez au moins JSF 2.2, ou que le filtre servlet qui est responsable de l'analyse des requêtes multipart/form-data est correctement configuré, sinon le FacesServlet finira par ne recevoir aucun paramètre de requête et ne sera donc pas en mesure d'appliquer les valeurs de requête. Comment configurer un tel filtre dépend du composant de téléchargement de fichier utilisé. Pour Tomahawk <t:inputFileUpload> , cochez la case cette réponse et pour PrimeFaces <p:fileUpload> , cochez la case cette réponse . Ou, si vous n'êtes pas en train de télécharger un fichier du tout, alors supprimez l'attribut complètement.

12. assurez-vous que l'argument ActionEvent de actionListener est un javax.faces.event.ActionEvent et donc pas java.awt.event.ActionEvent , ce qui est ce que la plupart des IDEs suggèrent comme 1ère option autocomplete. N'avoir aucun argument est mal ainsi, si vous utilisez actionListener="#{bean.method}" . Si vous ne voulez pas d'argument dans votre méthode, utilisez actionListener="#{bean.method()}" . Ou peut-être voulez-vous réellement utiliser action au lieu de actionListener . Voir aussi différences entre action et actionListener .

13. assurez-vous qu'aucun PhaseListener ou aucun EventListener dans la chaîne request-response n'a changé le cycle de vie du JSF pour sauter la phase d'action invoke en appelant par exemple FacesContext#renderResponse() ou FacesContext#responseComplete() .

14. assurez-vous qu'aucun Filter ou Servlet dans la même chaîne request-response n'a bloqué la requête du FacesServlet d'une manière ou d'une autre.

15. Bug dans le cadre. Par exemple, RichFaces a une " erreur de conversion "lorsqu'on utilise un élément rich:calendar UI avec un attribut defaultLabel (ou, dans certains cas, un rich:placeholder ). Ce bug empêche la méthode bean d'être invoquée lorsqu'aucune valeur n'est définie pour la date du calendrier. Tracer les bogues de framework peut être accompli en commençant par un exemple de travail simple et en construisant la page de retour jusqu'à ce que le bogue est découvert.

16. si vous utilisez un PrimeFaces p:dialog ou un p:overlayPanel , assurez-vous que vous ne courez pas dans p: action du bouton de commande ne fonctionne pas à l'intérieur de P: dialog

conseils de débogage

dans le cas où vous STACKS toujours, il est temps de déboguer. Du côté client, appuyez sur F12 dans webbrowser pour ouvrir l'ensemble des outils de développement web. Cliquez sur l'onglet Console pour voir l'onglet JavaScript conosle. Il doit être exempt de toute erreur JavaScript. Ci-dessous screenshot est un exemple de Chrome qui montre le cas de la soumission d'un bouton <f:ajax> activé tandis que ne pas 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 la demande et les données du formulaire et l'organisme de réponse sont conformes aux attentes. Ci-dessous screenshot est un exemple de Chrome qui montre un ajax soumettre avec succès d'un formulaire simple avec un seul <h:inputText> et un seul <h:commandButton> avec <f:ajax execute="@form" render="@form"> .

(attention: lorsque vous postez des captures D'écran des en-têtes de requêtes HTTP comme ci-dessus d'un environnement de production, alors assurez-vous de brouiller/brouiller les cookies de session dans la capture d'écran pour éviter les attaques de détournement de session!)

côté serveur, assurez-vous que le serveur est démarré en mode de débogage. Mettez un point de rupture de débogage dans une méthode de la composante JSF d'intérêt que vous vous attendez à être appelé pendant le traitement du formulaire soumettre. Par exemple: dans le cas du composant UICommand , qui serait UICommand#queueEvent() et dans le cas du composant UIInput , qui serait UIInput#validate() . Il suffit de passer par l'exécution du code et d'inspecter si le flux et les variables sont conformes aux attentes. Capture d'écran ci-dessous est un exemple du débogueur D'Eclipse.