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.
UICommand
et les UIInput
composants doivent être placés à l'intérieur d'un UIForm
composant, par exemple <h:form>
(et donc pas du HTML simple <form>
), sinon rien ne peut être envoyé au serveur. UICommand
les 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 .
Vous ne pouvez pas imbriquer plusieurs UIForm
composants 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 UIForm
composants 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? .
Aucune UIInput
erreur 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 id
of <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é .
Si UICommand
ou les UIInput
composants 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 value
du 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 @PostConstruct
le 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 .
Si UICommand
ou les UIInput
composants 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 @PostConstruct
le 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) .
L' rendered
attribut du composant et de tous ses parents et l' test
attribut de tout parent <c:if>
/ <c:when>
ne doivent pas être évalués false
pendant 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 @ViewScoped
bean ou la vérification de la préinitialisation correcte de la condition dans @PostConstruct
un @RequestScoped
bean devrait le corriger. Il en va de même pour l' disabled
attribut du composant, qui ne doit pas être évalué true
pendant 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> .
L' onclick
attribut du UICommand
composant et l' onsubmit
attribut du UIForm
composant ne doivent pas renvoyer false
ou 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 .
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 .
Si vous utilisez Ajax, et les valeurs soumises finissent par être null
, assurez - vous que les UIInput
et UICommand
composants 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 .
Si les valeurs soumises finissent toujours par être null
et 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 @Dependent
recré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?
Si un parent du <h:form>
avec le UICommand
bouton 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 render
du <f:ajax>
. Voir aussi h: commandButton / h: commandLink ne fonctionne pas au premier clic, ne fonctionne qu'au deuxième clic .
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 FacesServlet
volonté 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.
Assurez-vous que l' ActionEvent
argument de actionListener
est un javax.faces.event.ActionEvent
et 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 action
place de actionListener
. Voir aussi Différences entre action et actionListener .
Assurez-vous qu'aucun PhaseListener
ou aucun élément EventListener
de 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()
.
Assurez-vous qu'aucun Filter
ou Servlet
dans la même chaîne de demande-réponse n'a bloqué la demande de FacesServlet
quelque 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 .
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:
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 defaultLabel
attribut (ou, dans certains cas, un rich:placeholder
sous-é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.
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).
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 UICommand
composant, ce serait UICommand#queueEvent()
et en cas de UIInput
composant, 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.