Appeler une méthode sur un managed bean si erreur lors de Validation phase

Bonjour à tous,

J'espère que cette question n'a pas déjà été posée.


J'ai une page qui contient deux parties :

1. Un formulaire avec des champs que l'utilisateur peut remplir (ils permettent de spécifier des critères de recherche) et un bouton 'Rechercher'.

2. L'affichage des résultats en fonction des critères de recherche.


Voici le scénario qui pose problème :

1. L'utilisateur remplit correctement certains critères de recherche, il clique sur le bouton 'Rechercher', ce qui a pour effet de recharger la page avec l'affichage des résultats correspondant.

2. Ensuite, l'utilisateur souhaite modifier un des critères, il le modifie et clique sur le bouton 'Rechercher'. Manque de chance, la nouvelle donnée n'a pas le bon format ! La page se recharge avec :
- le message d'erreur relatif au champ incorrect, et :
- l'affichage du résultat précédent qui est toujours affiché.

J'aimerais que l'affichage du résultat précédent ne soit plus affiché. En effet, en soit, la recherche n'a retourné aucun résultat ... il y a donc discordance entre la nouvelle recherche et l'affichage du résultat.

Je préfèrerais ne pas utiliser de Javascript pour résoudre le problème.

Comment faire pour appeler, malgré l'erreur, une méthode sur un backing bean qui irait mettre à zéro le nombre de résultat ?

J'utilise MyFaces 1.1.5 et Tomahawk 1.1.9.

Je vous remercie d'avance pour votre aide !

Bonjour Nis,

D'après ce que j'en comprends, tu dois avoir un champ lié à une propriété d'un bean ayant un type restrictif (par exemple integer). Si l'utilisateur mets des caractères dans le champs, un message d'erreur sur le format apparaît sans qu'aucun code Java à toi ne soit appelé.

Sans utiliser de javascript, je ne vois pas comment contourner le problème.

Ta question m'a d'ailleurs fait un petit déclic. J'ai vérifié dans mon application, et j'ai exactement le même problème (sauf que je n'affiche pas le message d'erreur, donc il ne se passe strictement rien quand l'utilisateur entre du texte dans un champ destiné à recevoir un nombre... pas vraiment excellent je te l'accorde). Je vais m'y pencher et si je trouve une solution, je te la ferai parvenir. Je pense toutefois qu'elle sera composée de javascript (de toute façon, tout est en javascript chez moi puisque j'utilise IceFaces ou RichFaces selon le projet).

Une solution m'intéresse donc également si quelqu'un en a une toute prête.

J'ai trouvé une méthode très simple qui fonctionne bien, mais qui a toutefois quelques désagréables effets secondaires.

En passant le bean à un scope "request" plutôt que "session", le problème n'apparaît plus. En effet, ta liste d'objet est perdue dès que l'affichage de la page est terminé. En conclusion, si l'utilisateur change un critère de sélection et place un mauvais format, la liste revient automatiquement vide. Par contre, le formulaire qui contient les informations saisies par l'utilisateur comme filtre est vidé à chaque fois qu'un lien ou un bouton d'un autre formulaire est cliqué sur le site. C'est peut être innacceptable dans le cadre de ton application. Je te conseille également de vérifier ton système de pagination (si tu en a un) car il se pourrait qu'il ne fonctionne plus comme prévu avec ce changement (j'ai en tout cas du adapter deux ou trois choses pour le faire fonctionner après le changement de scope du bean).

Sinon, il semble possible de court-circuiter la validation à l'aide de l'attribut immadiate="true". La validation n'étant plus effectuée, tu devras la faire manuellement dans le code Java (overhead de programmation). De plus, et c'est nettement plus difficile à gérer, la mise à jour du modèle (ton bean donc) est également court-circuité. D'après mes tests, la fonction java de recherche est bel et bien appelée. Toutefois, le filtre n'est pas appliqué car le bean ne contient pas les valeurs entrées par l'internaute. Si j'en crois la FAQ JST du site, les valeurs peuvent être récupérées depuis l'arbre des composants disponible dans le FacesContext. C'est possible mais doit demander une adaptation assez lourde à mon avis. Je n'ai donc pas poussé l'analyse plus loin que de placer l'option immediate="true" sur mon bouton de recherche ainsi que sur les champs du formulaire de filtre.

La dernière solution, qui me paraît la plus simple, consiste à mettre un attribut onclic (donc du javascript) sur le bouton. J'ai lié ça à une fonction qui supprime la liste des objets du bean en session. Cette méthode a l'avantage de conserver les filtres appliqués par l'internaute (sauf si il rentre une erreur de format, auquel cas le modèle n'est pas mis à jour, l'action n'est pas appelé, mais le onclic s'effectue quand même, ce qui vide la liste des objets). Attention toutefois si tu as de la pagination qu'il faut réinitialiser à la page 1 en même temps que le vidage de la liste d'objet. Fonctionne parfaitement chez moi.

Voilà, j'espère que l'une de ces trois solutions te satisfera.

Meilleures salutations !

Hello Lordsephiroth,

Désolé de ne te répondre que maintenant, mais je n'ai pas eu le temps de me pencher sur ce problème depuis lors. Merci pour ta reponse.

En fait, comme je le disais, cette page est composée de deux parties et chaque partie possède son propre bean, exemple : searchBean et resultBean.

La solution en javascript me semble la plus envisageable ... Par contre, j'ai un léger soucis.

J'ai testé grosso-modo avec le code suivant :

Code:

---

1 2	<t:commandLink action="#{searchBean.search}" onclick="#{resultBean.emptyResult};" />

---

Le problème, c'est que le onclick #{resultBean.emptyResult} semble s'éffectuer après le #{searchBean.search} : du coup, il n'y a pas de résultats affichés (il fait la recherche, trouve des résultats et appelle #{resultBean.emptyResult}).

Pourrais-tu me montrer ta solution ?

Note que nous utilisons aussi RichFaces 3.0.1.

Je te remercie,
Nis

Bonjour,

Quand j'ai testé ma solution, qui est strictement la même que la tienne, je me suis posé la question de savoir si le onClick était effectué avant ou après le action. C'est peut être un hasard si mon onClick se réalise avant mon action, il suffirait que la recherche prenne plus de temps que le vidage de la liste (ce qui devrait normalement être le cas sachant qu'il y a un appel DB distant dans la recherche) pour que je n'aie pas vu le problème.

Je n'ai lu nulle part d'information concernant l'ordre d'exécution. Mon test était purement empirique et fonctionnait chez moi.

Ce que je te propose : colle un Thread.sleep() ou similaire (je ne sais pas la syntaxe exacte l'instant) à l'entrée de ta fonction de recherche afin d'y ajouter une bonne seconde de traitement. Si ton onClick qui vide ta liste est toujours exécutée après, c'est qu'il y a réellement une attente de la fin du action avant le lancement du onClick... ce qui serait incompatible avec mes observations...

Merci d'avance pour ton test.

Pour information :

Dans un composant bouton (ou link), les attributs action et actionListener pointent vers des actions côté serveur, donc en Java.
Le onclick, tout comme les onXXX fait référence à une fonction JavaScript lié à un événement particulier. onclick = action JavaScript - donc côté client - a exécuter au moment où l'utilisateur clique sur le bouton / lien. Donc onclick est toujours exécuté avant action(Listener) !

Certains composants proposent des actions à réaliser la fin d'un appel Ajax, comme par exemple <a4j:commandButton> qui propose d'exécuter du code JavaScript à la réception de la réponse Ajax grâce à son oncomplete.


Si tu as l'impression que onclick est exécuté après, montre nous un peu plus de code pour que l'on comprenne mieux ce qu'il se passe...

Merci pour ta réponse romaintaz.

J'ai mis une EL dans le onclick ... et je viens de voir que dans le source html, il n'y a plus de trace de la méthode jsf que je voudrais appeler ... logique puisque c'est évalué côté serveur ...

Je jette un coup d'oeil avec a4j:commandLink ...

En fait, on peut très bien mettre une EL dans un onclick, mais cela doit pointer vers une propriété qui va retourner le code JavaScript a exécuter. Ainsi, écrire ceci :

Code:

---

<h:commandLink ... onclick="#{monBean.monAction}"/>

---

doit être lié à ceci dans le code Java :

Code:

---

1 2 3

public String getMonAction() { return "alert('Ceci est du code JavaScript');"; }

---

qui est équivalent à écrire :

Code:

---

<h:commandLink ... onclick="alert('Ceci est du code JavaScript');"/>

---

L'avantage d'utiliser une EL c'est que le JavaScript retourné par le bean peut être conditionnel :

Code:

---

1 2 3 4 5 6 7

public String getMonAction() { if (uneCondition) { return "alert('Un code JavaScript');"; } else { return "alert('Un autre code JavaScript');"; } }

---

@LordSephiroth:

Oops, je n'avais pas vu ta réponse. Mettre un Thread.sleep() ne changeait rien.


@romaintaz:

Oui, en fait je me suis mal exprimé : ma méthode jsf retournait null, et donc il n'y avait plus de trace de la méthode dans le code html généré. Effectivement si la méthode retourne un string je m'attend à l'avoir dans mon code html.

J'ai essayé avec a4j:commandLink, mais avec le code suivant, les résultats de la recherche ne sont pas affichés :

Code:

---

1 2	<a4j:commandLink value="Search" action="#{searchBean.search}" reRender="resultDiv" />

---

Alors qu'avec le code suivant, elle s'affiche bien :

Code:

---

1 2	<t:commandLink value="Search" action="#{searchBean.search}" >

---

Pour info, #{searchBean.search} retourne l'outcome null.

Pour revenir au fait de continuer d'utiliser mon t:commandLink et d'utiliser l'event onclick, l'appel à #{searchBean.search} à bien lieu avant que #{resultBean.emptyResult} ne s'exécute (j'ai lancé le machin en debug pour voir).

C'est tout de même incroyable que quelque chose qui devrait être aussi simple soit si difficile ...

Tout le problème viens du manque de points d'entrés dans cycle de vie dans ce genre de cas.
Lors d'une erreur de validation il saute directement au rendu sans passé par du code applicatif "simple".

Sur un projet ou nous étions confronté au même projet, nous avions commencé a regarder pour implémenter une phase listener en session dans ce genre de page grâce au tag <f:phaseListener ... /> qui lors de la phase de validation, vérifiera si une erreur a eu lieu et soit exécutera du code soit présentera un booléen pour les rendered.

Après, par manque de temps, on est passé vers de la validation manuelle.

Merci pour ta réponse Shinzul.

J'ai aussi pensé au début qu'un PhaseListener pourrait peut-être résoudre le problème, mais je n'ai pas été plus loin dans cette idée : je trouve ça un peu lourd en fait. Devoir créer cela juste pour ça ...

Cela dit, ça aurait l'avantage d'être sans Javascript ;-)

Effectivement juste pour ça c'est un peu lourd.
Cependant une fois ce mécanisme mis en place, cela te donne une bien meilleure accessibilité au framework pour des cas spéciaux.

Nous avions plus pensé à cette solution comme un point d'entré pour des traitements spécifique qui viennent s'inscrire dans le cycle de vie JSF, quitte a faire une classe générique. Mais bon comme d'habitude, pas de temps, pas d'argent toussa toussa ...

Bon entre temps on est passé sur Seam nous donc on a moins de problème ^^

Bonjour,

Un des messages de Romain ci-dessus m'a procuré un petit déclic cérébral qui pourrait expliquer la différence de comportement entre nos applications. Je travaille dans un contexte RichFaces et je suppose que ça a une influence sur le onclic. Je n'ai par exemple pas besoin que le résultat de l'expression EL situé dans le onclick retourne du code javascript. J'ai simplement mis dans le onclick quelque chose ressemblant à #{searchBean.emptyList}. Je suppose que c'est le support AJAX de RichFaces qui permet d'exécuter ça correctement.

Je suis navré d'avoir donné une piste qui ne marche pas forcément pour JSF sans le support RichFaces, j'ai parfois de la peine à situer la limite entre JSF et RichFaces, n'ayant jamais travaillé sans le support étendu de la librairie riche...

J'espère que le phase-listener te permettra de réaliser ce que tu cherches. Pour avoir utilisé ça ailleurs, je confirme que c'est un peu verbeux pour une fonctionnalité aussi évidente que ce que tu cherches à faire ;)

Cordialement,
Patrick

Ce que j'ai expliqué est tout à fait valable pour Richfaces (je l'utilise moi même). onclick fait forcément référence à du code JavaScript qui sera exécuté avant l'envoi du formulaire. Y a pas de magie :)

Concernant le problème initial, effectivement le cycle de vie de JSF est fait ainsi. Si une validation échoue, le reste du cycle de vie n'est pas effectué. Donc soit on peut court-circuiter ce comportement en mettant son propre PhaseListener, soit on réalise cela en JavaScript.

Citation:

---

Envoyé par romaintaz

Ce que j'ai expliqué est tout à fait valable pour Richfaces (je l'utilise moi même). onclick fait forcément référence à du code JavaScript qui sera exécuté avant l'envoi du formulaire. Y a pas de magie :)

---

Ta remarque m'a dans un premier temps intrigué, car ce code fonctionne chez moi :

Dans le bean j'ai :

Code:

---

1 2 3 4

public int getClear(){ this.agendas.clear(); return 1; }

---

Code:

---

<a4j:commandButton value="#{messages.search}" onclick="#{AgendaSearchBean.clear}" action="#{AgendaSearchBean.find}" reRender="content" />

---

Après avoir collé des affichages dans mes méthodes de recherche et le getClear(), je me rend compte que le fait que ça marche n'est qu'un hasard. Le clear ne se fait pas lorsque je clique sur le bouton mais lorsque le rendu de la page est réalisé. Le seul point qui fait fonctionner le truc, c'est que ma liste d'objet est située avant mon bouton dans la page HTML. Du coup, la page affiche les objets dans la dataTable, puis vide la liste lors du rendu du bouton. Du coup, au prochain affichage j'ai l'impression que la liste a été vidée lorsque j'ai cliqué sur le bouton, alors qu'elle était déjà vide depuis le dernier affichage.

J'ai testé de déplacer le formulaire de recherche avant la dataTable, et effectivement plus aucun objet ne s'affiche à l'écran.

Merci pour ta remarque Romain, tu m'évites quelques prises de têtes futures. Je vais partir également dans la direction du phaseListener et regarder si j'arrive à quelque chose.

Cordialement,
Patrick

Oui, c'est effectivement cela. En gros, ta méthode getClear() est appelée lors de la génération du HTML du bouton, et cela va vider ta liste, mais seulement pour la requête d'après. Sauf, a priori, si tu déplaces ton bouton avant le tableau, l'appel au getter devrait vider ta liste, et donc ton tableau devrait apparaitre toujours vide.

Merci pour vos réponses.

J'ai finalement utilisé un phase listener qui va vider ma liste si il y a eu un problème de validation.