Passage de paramètres en GET (Encore :))

Bonsoir à vous,

Dans le cadre d'une appli web dans laquelle les utilisateurs sont invités à s'inscrire, et ensuite à activer leur compte en cliquant sur un lien dans un email qui leur a été envoyé, je tombe sur le problème du passage de paramètre en GET.

En fait le vrai problème n'est pas le passage de paramètres en GET. Ni même la technique pour les récupérer.
Le vrai problème c'est "Quand les récupérer ?"

Si un utilisateur appelle une url avec des paramètres dedans, la page est rendue et c'est terminé. Le développeur n'a pas eu de réelle opportunité de réaliser un traitement avec les paramètres de l'url avant de rendre la page.

Dans le cas d'une validation de compte (comme pour moi par exemple), on souhaite qu'il n'y ait pas d'autre intervention de l'utilisateur que le clic dans sa boite mail.

La solution la plus propre que j'ai trouvée à mon problème est d'utiliser un PhaseListener. Mais ça me semble être une usine à gaz.
Le fonctionnement est basé sur une déclaration des paramètres à rechercher.
Les paramètres en question sont définis dans un fichier de config. Ils sont associés à un nom, un managed bean (qui doit être déclaré dans le faces-config.xml), une méthode.
La méthode accepte un paramètre de type String (qui sera le contenu du paramètre trouvé dans l'url).
Le phase listener regarde si un ou des paramètres déclarés dans le fichier de config sont présents dans la request parameter map.
Si le paramètre est présent dans la request parameter map, la méthode donnée est appelée sur le managed bean donné.
Cette façon de fonctionner vient d'ici

Ca fonctionne bien et ça répond à ma demande, mais je trouve ça lourd et pas super propre comme façon de configurer le truc. Il y a peut-être moyen de faire plus propre avec Spring pour la configuration.

Depuis le temps que cette problématique est apparue, y a-t-il des solutions plus "standard" pour traiter ce genre de cas avec les JSF ?

Si tu peux te permettre d'avoir ce shéma:

clique sur le lien dans l'email
Affichage d'un formulaire, correspondant à un request-scope bean, dans lequel des champs ont été pré-remplis
Soumission du formulaire
Action


Alors y a plus simple que l'usine à gaz :)


Utilise simplement un request-scope bean avec un managed property:

Code:

---

1 2 3 4 5 6 7 8 9 10

<managed-bean> <managed-bean-name>validation</managed-bean-name> <managed-bean-class> package.validation.UserValidation </managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>validationKey</property-name> <value>#{param.key}</value> <!-- récupère ?key=.... sur l'url --> </managed-property>

---

tu peux le faire a vec une page jsf avec un backing bean de scope request
dans son constructeur tu fais ton traitement (recuperation et activation).

@tchize :

C'est sur c'est pas mal comme ça. Le seul (tout petit) problème c'est que ça ne se fait pas tout seul. Après avoir cliqué sur le lien dans un mail, l'utilisateur doit encore aller cliquer sur un bouton ou un lien dans la page qui s'ouvre.
Ne pas oublier que l'ATP d'un utilisateur ne se régénère pas assez vite pour lui permettre d'effectuer de telles prouesses sportives.

Non, sérieusement, je vais peut-être utiliser cette technique si je trouve que la mienne est chiante à faire évoluer ou à maintenir.
Merci.

@seddik_saber :
Je voulais justement éviter de faire des appels implicites à des méthodes (ou constructeurs) pour faire mon traitement. Cela dit ton idée devrait fonctionner. Mais je ne la trouve pas super propre.
Merci aussi ;)

Citation:

---

Envoyé par sir_gcc

@tchize :

C'est sur c'est pas mal comme ça. Le seul (tout petit) problème c'est que ça ne se fait pas tout seul. Après avoir cliqué sur le lien dans un mail, l'utilisateur doit encore aller cliquer sur un bouton ou un lien dans la page qui s'ouvre.

---

Ben a priori, dans le setter de la propriété, tu fait ce que tu veux, en ce e y compris, effectuer l'action demandée à ce moment au lieu d'attendre un submit ;) Dans la page qui utilise le bean tu peux alors juste afficher "Monsieur X, votre inscription est maintenant terminée, merci" :p

pourrais tu m'expliquer qu'es qui derange dans la solution avec un phaselistner ???

sinon attends jSF 2.0 il supporterais le get :D

@tchize :
C'est peu ce que disais seddik_saber, utiliser un appel automatique à une méthode (ou constructeur) pour faire le traitement. Non mais ça va pas ! ;) Non, c'est pas plus mal de demander à l'utilisateur de confirmer en cliquant sur un truc. Et ça fait plus sérieux. (Comment ça c'est vaseux comme argument ?)

@seddik_saber :
Il me semblait bien que ça serait dans la v2...
Je t'avoue que j'ai hâte de voir ce que propose la v2, mais pour l'instant je fais du v1.2 parce que je connais. Quand la v2 sera là je verrai pour migrer. Si ça vaut le coup.
Ce qui me dérange avec le phase listener c'est la configuration du truc. Mais au moins je sais que ça fonctionne bien.

un phase listner c'est tou simple a mettre en ouvre c'est une class qui implemente PhaseListener ou t'as une methode ou tu retourne la phase que tu veux y rattacher ton listener.
puis declarer ca dans faces-config c'est tres simple <phase-listener>tonpackage.TaClass</phase-listener>

As-tu lu ce que j'ai écrit ?
J'ai mis en place la solution avec le listener, mais la configuration ne me plait pas.
J'ai pas dit que c'était outrageusement compliqué à mettre en oeuvre.

Cela dit, merci de t'intéresser à ce sujet.

:)
(j'ai pas lu ton premier post en totalite :oops:)

cependant avez vous lit cet article : http://wiki.apache.org/myfaces/Invok...thStandardUrls
ca illustre plusieur methodes a acceder au parametre get