intercepter l'évènement de changement d'un formulaire

salut

le titre décrit ce que je cherche, je travaille sur jsf et richfaces, et j'ai lue ca :

Code:

---

1 2 3 4 5 6

En cas de modification, un évènement est déclenché automatiquement par le Framework et l'utilisateur a la possibilité de le gérer afin d'interagir directement avec l'arbre des contrôles. La dernière étape consiste à mettre à jour le modèle de présentation et à générer la réponse HTML en fonction de la hiérarchie des composants. Cette opération s'appelle le Rendu ou "Rendering".

---

dans un article.

alors la question est comment intercepter si il y un changement dans un champs du formulaire au niveau a4J.

Code:

---

1 2 3 4

<h:inputText value=......> <a4j:support event="onchange" reRender="sectionARafficher" actionListener="#{monBean.maMethodListener}"/> </h:inputText>

---

par exemple

merci pour ta réponse mais est'il possible d'avoir un onchange sur tout le form ???
surtout que je risque de me retrouver avec des formulaires énorme ...

le but du on change c'est de réagir pendant que l'utilisateur tappe dans les champ, il n'est donc en général utilisé que pour des composants particulier (exemple faire une liste qui dépend de l'entrée tappée dans le formulaire, vérifier dans un formulaire d'enregistrement automatiquement que le numéro de tél est correct, que le login n'est pas déjà pris, etc).

Ne pas confondre avec le fait de vouloir savoir, au moment du submit, tout ce qui a été changé par l'utilisateur, ça ce n'est pas le boulot de a4j, mais c'est à ton action de comparer les nouvelles et ancienne valeur. Par définition, si tu soumet tout le formulaire, pour JSF, tout a changé, tout subit un cycle de conversion et d'appel aux setters, même si au final la valeur settée est la même que la précédente.

Salut,
J'ai rencontré la même difficulté dans mon app, effectivement s'il y a une possibilité d'écouter tout changement sur le formulaire ce serait génial. Finalement, j'ai travaillé avec des a4j:support sur les champs clés de mon formulaire. Mais si tu as des formulaires énormes, c'est pas gagné. je serai aussi preneur pour toute solution pouvant globaliser.

c'est exactement pour quoi je me suis dis que ca serais parfait si dans jsf ils'ont prévue le cas ou il y'a pas de changement ou bien au cas ou je veut fermer la page alors qu'il y a des changement non sauvgarder, donc mon but au moment ou j'appuis sur un bouton avant de soumettre la requête a jsf pouvoir remonter des alertes pour les deux cas ... et donc au pire comment récupere les valeur avec les quelles le formulaire a était initialisé pour prendre la décision de passer a la couche métier ou plutôt remonter l'alerte ..

au moment de l'action qui précède le premier affichage du formulaire, tu dois stocker en session des copies de tes beans metiers. Lors de l'action qui suit l'envoi du formulaire, tu compare les beans sauvegardés aux nouveau beans.

Citation:

---

Lors de l'action qui suit l'envoi du formulaire, tu compare les beans sauvegardés aux nouveau beans.

---

Je trouve ca très lourd tchize_, j'avais déjà été confronté à ce pb lors de mon dernier projet, j'y ai palié en javascript comme suit, tous mes formulaires avaient un champ hidden initialisé à 0, et tous mes composants faisaient un appel javascript d'une fonction "onchange", la fonction js appelée passait simplement mon hidden à 1. et donc la soumission d'un formulaire n'était faite qu'en fonction de ce champ hidden. Je trouvais ça plus léger comme gestion.

dans le document que j'ai cité plus haut

Citation:

---

En cas de modification, un évènement est déclenché automatiquement par
le Framework et l'utilisateur a la possibilité de le gérer afin d'interagir directement
avec l'arbre des contrôles.

---

puisque j'ai l'impression que un listener global n'existe pas ... au lieux que je garde mes donnée dans un bean session est ce possible de récupérer l'arbre des données avec le quel compare jsf lui même ???

Citation:

---

Envoyé par DevServlet

Je trouve ca très lourd tchize_, j'avais déjà été confronté à ce pb lors de mon dernier projet, j'y ai palié en javascript comme suit, tous mes formulaires avaient un champ hidden initialisé à 0, et tous mes composants faisaient un appel javascript d'une fonction "onchange", la fonction js appelée passait simplement mon hidden à 1. et donc la soumission d'un formulaire n'était faite qu'en fonction de ce champ hidden. Je trouvais ça plus léger comme gestion.

---

peut tu me donnée un petite exemple pour faire ca ??? j'arrive pas a suivre ton explication :(

j'ai pas le projet ici avec moi, mais en fait dans chaque formulaire tu mettrais un champ

Code:

---

<input type ="hidden" value="0"

---

et dans chacun de tes composants du formulaire tu ferais un appel du genre

Code:

---

<ton_composant onchange="ma_fonction_js(this)"

---

et dans ton js tu mettrais :

Code:

---

this.value="1"

---

et dans ton submit tu ne fais un appel serveur que si cette valeur a changé. Tu vois le truc?

JSF ça fonctionne comme çà


Beans de Donnée -> Formulaire -> utilisateur -> soumission -> transfert vers Beans de données -> appel de l'action

autrement dit, dans l'action, tu peux scanner tout ce que tu veux, t'aura les nouvelle valeur puisque JSF a déjà fait le transfert vers les beans. La solution javascript c'est joli, mais c'est fort sensible aux bidouille du client, si le but est de faire de l'audit sur un formulaire, celui qui voudra se cacher aura vite compris qu'il suffit de remettre ces champs à 0 avant le submit ou de désactiver JS pendant que tu remplis le formulaire ;).

Je rajoute aussi que

T'as aussi la possibiltié de mettre des Listener sur les evènements globaux de JSF, dans le faces-config et faire du travail à cet endroit là si ça te chante. Mais il n'y a pas à ma connaissance de méthode magique dans JSF qui va te retourner la liste des composant qui ont subit une différence entre la valeur soumise et la valeur d'origine. Sans compter que des mises à jour partielles de beans peuvent avoir lieu dans certaines conditions, sans pour autant aller jusqu'à l'action (erreurs dans les converters par exemple).

Code:

---

cacher aura vite compris qu'il suffit de remettre ces champs à 0 avant le submit ou de désactiver JS pendant que tu remplis le formulaire

---

C'est un champ en hidden, envoyé avec la methode post, le client n'a pas connaissance, et 2emement richFaces repose completement sur du full js, tu desactives le js et rien ne marche. Je suis hostile aux solutions de comparaison de bean pour la simple raison qu'on perd , en mémoire, occupation de la bande passante, et j'en passe inutilement. Imagines qu'un utilisateur ne fait rien sur un formulaire et valide, (avec eventuellement plusieurs champs ou composants sur le formulaire) l'appli passera toutes les phase JSF et fera une comparaison completement inutiles coté serveur.

Citation:

---

Envoyé par tchize_

T'as aussi la possibiltié de mettre des Listener sur les evènements globaux de JSF, dans le faces-config et faire du travail à cet endroit là si ça te chante.

---

tchize_ peux tu détailler un peu cette soluce 8O
Je crains aussi que n'importe quel évènement puisse être catché pourtant la saisie du champ n'a pas été faite. Par exemple tu as un radio button qui va juste activer ou desactiver un champ du form.

il s'agit d'évènement globaux liés uniquement aux 5 Phases JSF, Phase ayant lieu uniquement coté serveur. Mais je suppose que tu peux t'en servir pour scanner l'arbre avant le ApplyRequestValue et après le Render afain de faire des comparaisons.

finalement je crois que je vais opter pour la vérification coté serveur ... au moins ca seras plus sur que on va pas modifier le texte par le même et passé pour une modification je préfère que ca charge mon serveur d'application plutôt que de faire appel a ma BD...

je ré-ouvre ce post car j'ai trouver l'évènement "ValueChangeEvent" et je voudrais savoir comment je peut l'utiliser ??
est ce que c'est possible de l'activer sur tout le formulaire?

Non, ValueChangeEvent ne peut être lié à un formulaire complet. En gros, cet attribut te permet de disposer d'une méthode qui dispose de l'ancienne valeur et de la nouvelle valeur d'un unique champ.