Discussion :

[Nis]

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 !

[Lordsephiroth]

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.

[Lordsephiroth]

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 !

[Nis]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Lordsephiroth]

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.

[romaintaz]

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