Discussion :

[hocdz]

Bonjour,

Dans mon application Struts, j'ai besoin d'un formulaire qui peut parfois être initialement vide MAIS d'autres fois initialisé avec des valeurs présentes dans un bean qui lui est alors présent dans la session. Mon formulaire est validé dans l'action Struts et peut revenir à la même page si une erreur se produit, via un redirect (mapping.getInput()). Actuellement j'utilise dans mes html:text, le paramètre value="${bean.property}" pour obtenir une valeur initiale si le bean est présent dans la session. LE PROBLEME, c'est que quand le bean n'est pas dans la session, ET si je rentre des données dans le formulaire ET que la validation me renvoi vers la page input à nouveau, je perds les données précédemment rentrées. Ceci est bien génant dans le cas d'un formulaire avec plusieurs champs. Pouvez vous me dire quelle est la démarche à suivre au nivea de mon ActionForm et de ma JSP (html:text...) pour que le formulaire soit correctement initialisé (si le bean est dans la session) sans pour autant écraser le valeurs rentrées si je reviens de l'Action, après validation, à la même page? J'espère que c'est assez clair!! Merci.

[c_nvy]

En principe, on définit deux Actions : une qui initialise le formulaire et une qui s'exécute au submit du formulaire :

Code xml :

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

1
2
3
4
5
6
7
8
<action path="/pathInitAction" type="nomdupackage.InitAction"
        name="nomDuFormBean" validate="false">
   <forward name="success" path="/page1.jsp"/>
</action>
<action path="/pathAction" type="nomdupackage.Action"
        name="nomDuFormBean" validate="true" input="/pathInitAction.do">
   <forward name="success" path="/page2.jsp"/>
</action>

et pour initialiser le formulaire dans l'Action qui s'exécute avant l'affichage du formulaire, on code ceci :

Code :

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

1
2
3
TonActionForm tonActionForm=(TonActionForm) form ;
tonActionForm.setChamp1(bean.getChamp1()) ;
tonActionForm.setChamp2(bean.getChamp2()) ;

Dans ce cas, on enlève l'attribut value des tags html:text.

Et quand il y a une erreur de validation, on redirige vers l'Action d'initialisation du formulaire en codant input="/pathInitAction.do" dans le mapping de cette Action.

[hocdz]

Bonjour,

Merci pour la réponse, que j'essayerai prochainement. Celà dit, je ne comprends pas comment on puisse récupérer le formulaire dans l'action d'initialisation avant même qu'il ne soit soumis?! (TonActionForm tonActionForm=(TonActionForm) form). Ma 2eme question est: est ce qu'en cas d'erreur et retour au formulaire, les éventuels changements dans le formulaire seront maintenues et vont bien remplacer, à l'affichage, les valeurs initiales du bean produites par la première action? Ma 3eme question est de savoir quel est le "life cycle" (création, initialisation (reset...), validation...destruction) d'un ActionForm Struts? Celà me permettrait de mieux cerner ce type de problèmes avec Struts.
Merci beaucoup.

[c_nvy]

Celà dit, je ne comprends pas comment on puisse récupérer le formulaire dans l'action d'initialisation avant même qu'il ne soit soumis?! (TonActionForm tonActionForm=(TonActionForm) form).

Tu peux récupérer l'ActionForm dans l'Action d'initialisation tout simplement parce que tu l'as référencé dans le mapping de l'Action via l'attribut name="nomDuFormBean".
Dans ce cas, à l'appel de l'Action d'initialisation, l'instance de l'ActionForm est créée et la méthode reset et les setters sont appelés, tout ceci avant l'appel de la méthode execute de l'Action.
Ceci explique pourquoi, dans la méthode execute, tu peux récupèrer l'instance de l'ActionForm via TonActionForm tonActionForm=(TonActionForm) form et initialiser chacune de ses propriétés avec les valeurs du bean via ses setters.

Ma 2eme question est: est ce qu'en cas d'erreur et retour au formulaire, les éventuels changements dans le formulaire seront maintenues et vont bien remplacer, à l'affichage, les valeurs initiales du bean produites par la première action?

Si tu veux conserver les valeurs saisies dans le formulaire en cas d'erreur de validation, contrairement à ce que j'ai dit, il ne faut pas spécifier l'Action d'initialisation dans l'attribut input mais plutôt la jsp qui affiche le formulaire.

Au submit du formulaire, les setters de l'ActionForm étant appelés, tu devrais retrouver, au réaffichage du formulaire, les valeurs saisies, même en cas d'erreur de validation.

Ma 3eme question est de savoir quel est le "life cycle" (création, initialisation (reset...), validation...destruction) d'un ActionForm Struts? Celà me permettrait de mieux cerner ce type de problèmes avec Struts.
Merci beaucoup.

Le cycle d'une ActionForm est la création d'une instance de l'ActionForm, l'appel de la méthode reset, l'appel des setters et si validate="true", l'appel de la méthode validate, et tout ceci, avant l'appel de la méthode execute de l'Action.

Si par contre, un même form-bean est lié à plusieurs Actions et qu'il est stocké dans le scope session, l'instance de l'ActionForm est créée à l'appel de la première Action liée à ce form-bean et ensuite récupérée dans le scope session par les autres.
Et contrairement à ce que beaucoup pensent, la méthode reset est systématiquement appelée, que le form-bean soit dans le scope request ou session.

[hocdz]

D'accord...donc pour résumer, je doit avoir deux actions utilisant le même ActionForm (initAction et Action), la première pour initialiser les champs du formulaire (si le bean est présent) et la deuxième pour traiter ce formulaire. En cas d'erreur de validation, le retour se fait à la même jsp (via input=majsp) et les dernières données rentrées seront ainsi maintenues. Je rajoute juste que dans mon cas je fais le validation dans l'action! (je ne sais pas si c'est une bonne ou mauvaise pratique?). Je reviens aussi au cycle de vie de l'ActionForm et pose une question sur le reset. Cette méthode est apparement d'initialisation aussi, mais je ne comprends pas bien son utilité et la manière dont on peut en tirer profit? Mon autre question concerne le scope du formulaire. Dans la documentation Struts, le scope par défaut et le request (je crois...?). Dans mon application, j'ai +ieurs liens qui ouvrent tous une nouvelle fenêtre avec le même formulaire en passant un paramètre différent à chaque fois. Quand je clique sur un deuxième lien (donc nouvelle requête), la fenêtre qui s'ouvre contient au départ les données saisies dans la fenêtre d'avant, alors que le formulaire n'est pas précisé avec scope=session, Est ce normal? Merci.

[c_nvy]

Je rajoute juste que dans mon cas je fais le validation dans l'action! (je ne sais pas si c'est une bonne ou mauvaise pratique?).

Tout dépend quelle genre de validation tu fais dans l'Action.
Par exemple, pour vérifier que les données saisies sont bien dans la forme attendue, comme par exemple vérifier qu'une valeur est bien saisie dans un champ ou bien encore que la valeur saisie ne doit pas dépasser tant de caractères, la bonne pratique est d'utiliser la méthode validate de l'ActionForm ou bien le Validator.
Par contre, pour une validation métier, comme par exemple vérifier que l'identifiant saisi existe bien dans la base de données, on la fait généralement dans l'Action.
Il y a aussi le cas des DispatchAction ou LookupDispatchAction où généralement, la validation n'est pas sensée être faite pour toutes les actions sur le formulaire. Dans ce cas, on met validate à false dans le mapping de l'Action et on fait appel à la méthode validate de l'ActionForm seulement dans la(ou les) méthode(s) de l'Action pour lesquelles la validation est justifiée.

Je reviens aussi au cycle de vie de l'ActionForm et pose une question sur le reset. Cette méthode est apparement d'initialisation aussi, mais je ne comprends pas bien son utilité et la manière dont on peut en tirer profit?

La méthode reset est utile par exemple dans le cas où tu souhaites réinitialiser certains champs, au réaffichage d'un formulaire stocké dans le scope session.

Elle est également très utile dans le cas où il y a des checkbox dans un formulaire, parce qu'elle permet de forcer le décochage des checkbox, et donc de pallier au fait que, lorsqu'une checkbox est décochée, sa valeur n'est pas transmise au submit du formulaire.

Mon autre question concerne le scope du formulaire. Dans la documentation Struts, le scope par défaut et le request (je crois...?). Dans mon application, j'ai +ieurs liens qui ouvrent tous une nouvelle fenêtre avec le même formulaire en passant un paramètre différent à chaque fois. Quand je clique sur un deuxième lien (donc nouvelle requête), la fenêtre qui s'ouvre contient au départ les données saisies dans la fenêtre d'avant, alors que le formulaire n'est pas précisé avec scope=session, Est ce normal? Merci.

Et bien non, le scope par défaut d'un form-bean n'est pas request mais session, ce qui explique le comportement que tu observes.
Si tu veux que le form-bean soit stocké dans le scope request, il faut ajouter l'attribut scope="request" dans le mapping de la (ou des) Action(s) concernée(s).

[hocdz]

Merci. Au fait pour la validation dans l'action, je l'ai choisi surtout pour deux raisons: La première c'est que je voulais que les messages d'erreur s'affichent dans la page (la même=input) sans utiliser javascript, or je n'arrivais pas à le faire sans javascript avec le validator! La deuxième c'est que la méthode validate utilise un forward alors que j'avais besoin d'un redirect. Aurais-je pu faire autrement? Pour le reset, est ce toujours appellé dans le formulaire (même non surchargé), y a t-il des situations ou un developpeur l'appelle (le reset) explicitement dans l'action ou dans la jsp? Je reviens au forward et au redirect. Avec le forward (par exemple: mapping.getInputForward()), j'ai eu des problèmes d'affichage de css et d'image. J'ai beau essayé de modifier les paths...rien à faire, c'est pourquoi j'ai fini par utiliser un redirect pratiquement à chaque fois. Avez-vous une idée de pourquoi ya problème de css et d'images non affichées avec le forward? Y a t'il un inconvenient à utiliser le redirect à la place du forward? Merci beaucoup.

[c_nvy]

Merci. Au fait pour la validation dans l'action, je l'ai choisi surtout pour deux raisons: La première c'est que je voulais que les messages d'erreur s'affichent dans la page (la même=input) sans utiliser javascript, or je n'arrivais pas à le faire sans javascript avec le validator!

Avec le Validator, tu peux très bien afficher les messages d'erreur dans la même page via le tag <html:errors/> et ce, sans utiliser Javascript.
Il suffit pour cela de ne pas activer la validation Javascript dans la jsp en ne codant ni tag <html:javascript formName="nomDuFormBean">, ni attribut onsubmit dans le tag html:form.

La deuxième c'est que la méthode validate utilise un forward alors que j'avais besoin d'un redirect. Aurais-je pu faire autrement?

Si tu as besoin d'un redirect, je ne vois effectivement pas d'autre solution.

Pour le reset, est ce toujours appellé dans le formulaire (même non surchargé), y a t-il des situations ou un developpeur l'appelle (le reset) explicitement dans l'action ou dans la jsp?

La méthode reset est automatiquement exécutée à chaque appel d'Action liée à un form-bean. Il n'y a donc pas de raison de l'appeler explicitement dans une Action et encore moins dans une jsp.
Ce n'est d'ailleurs je pense pas conseillé car ça va à l'encontre des mécanismes automatiques de Struts.

Je reviens au forward et au redirect. Avec le forward (par exemple: mapping.getInputForward()), j'ai eu des problèmes d'affichage de css et d'image. J'ai beau essayé de modifier les paths...rien à faire, c'est pourquoi j'ai fini par utiliser un redirect pratiquement à chaque fois. Avez-vous une idée de pourquoi ya problème de css et d'images non affichées avec le forward?

Pour ton problème de css et d'image, tu peux ajouter le tag <html:base/> dans la balise <head>. Il permet d'utiliser des url relatives basées sur l'url de la page elle-même.
Ainsi, tu ne devrais plus avoir besoin de faire des redirect et tu pourras donc de nouveau faire les validations via la méthode validate ou le Validator.

Y a t'il un inconvenient à utiliser le redirect à la place du forward? Merci beaucoup.

Le seul inconvénient c'est que le redirect générant une nouvelle requête, tu perds tout ce qui est stocké dans le scope request.

[hocdz]

Merci pour les réponses. Pour ce qui est du reset, j'ai relu un peu la javadoc et effectivement la méthode reset est systématiquement appelée, mais ne fait rien si elle n'ai pas implémentée. je voulais aussi aborder le sujet du Forward et du Redirect. Dans un redirect on perd "tout ce qui est dans la requête", celà veut dire que les eventuels paramètres de la requête sont perdus après un redirect? Existe t il d'autres choses que les paramètres dans la requête qui peuvent être perdues? J'ai lu aussi que le redirect est "une nouvelle requête" alors que le forward est une requête relayée en quelques sortes. Si je prends cet exemple: req+param1--> action a1-->jsp1 et je fais un forward vers le input (getInputFprward()), quelle serait la différence dans le flux avec un redirect (new ActionForward(mapping.getInput(),true))? Je prend aussi un autre exemple, mais je ne sais pas si ça a un rapport avec! Admettons que j'ai une page qui m'affiche la liste des employés, dans cette page je fais un update des salaires de certains. Quand je clique update ou Ok, je devrais normalement avoir à nouveau la liste mise à jour, donc je sarait passé à nouveau par la même requete (lister) à la base de données. Cette requête est dans mon action. Est ce que avec un getInputForward (donc un forward) celà est automatiquement exécuté à nouveau (repasser par le même chemin) et que ce n'est pas le cas avec un redirect vers le input (où est ce une autre question!)? Merci.

[c_nvy]

Dans un redirect on perd "tout ce qui est dans la requête", celà veut dire que les eventuels paramètres de la requête sont perdus après un redirect?

oui

Existe t il d'autres choses que les paramètres dans la requête qui peuvent être perdues?

non

J'ai lu aussi que le redirect est "une nouvelle requête" alors que le forward est une requête relayée en quelques sortes. Si je prends cet exemple: req+param1--> action a1-->jsp1 et je fais un forward vers le input (getInputFprward()), quelle serait la différence dans le flux avec un redirect (new ActionForward(mapping.getInput(),true))?

Si dans l'Action a1, tu mets un objet dans le scope request, avec un forward, tu pourras récupérer l'objet dans la jsp, avec un redirect, non.

Je prend aussi un autre exemple, mais je ne sais pas si ça a un rapport avec! Admettons que j'ai une page qui m'affiche la liste des employés, dans cette page je fais un update des salaires de certains. Quand je clique update ou Ok, je devrais normalement avoir à nouveau la liste mise à jour, donc je sarait passé à nouveau par la même requete (lister) à la base de données. Cette requête est dans mon action. Est ce que avec un getInputForward (donc un forward) celà est automatiquement exécuté à nouveau (repasser par le même chemin) et que ce n'est pas le cas avec un redirect vers le input (où est ce une autre question!)? Merci.

Là, j'ai beau relire plusieurs fois, j'ai du mal à te suivre.
Si tu veux que la liste soit mise à jour après l'update, il suffit de re-exécuter le code qui la constitue avant de réafficher la page.
Si tu mets la liste dans le scope request et que tu fais un redirect, tu ne pourras pas la récupérer dans la jsp alors qu'avec un forward si.
Si tu la mets dans le scope session, tu pourras la récupérer dans la jsp que ce soit avec un forward ou un redirect.

Enfin, rien ne vaut un bon test pour lever le doute sur un quelconque fonctionnement.

[hocdz]

Pour essayer d'être plus clair sur mon exemple: Si par exemple j'ai un lien link1 qui en cliquant dessus lance la requête req1 avec le paramètre rh pour afficher la liste des employés rh (link1-->action1-->jsp1). Dans action1 j'ai dao.getEmployeeList. Je fais donc mon update dans cette liste et à la fin de mon action action1 je fais soit un forward vers le input soit un redirect. Je pensais donc qu'un forward (getInputForward) va relancer toute la chaine (req1-->action1-->jsp1), donc réexécuter dao.getEmployeeList, alors qu'un simple redirect vers le input va juste reafficher la page avec les données qui sont déjà en mémoire (liste employés) avant l'update(?) Ou bien est ce que tout le truc c'est justement de mettre input=action1 au lieu de input=jsp1 dans le strutsconfig, comme j'ai fait moi? Merci.

[c_nvy]

Si tu références une jsp dans l'attribut input, alors il fera un forward vers la jsp.
Si tu y références une Action, alors il fera un forward vers l'Action.
C'est aussi simple que ça.

Bon, sinon, t'en es où côté mise en oeuvre ?
As-tu testé tout ça ?

[hocdz]

Ma question sur l'exemple avec liste employés est plutôt un faut problème lié à une mauvaise conception objet et probablement aussi une fausse compréhension du forward dans Struts! Pour l'implémentation, j'ai effectivement essayé l'initialisation du formulaire dans l'action (1ere), j'ai enlevé les values des tags dans ma jsp et mis input=majsp dans le strutsconfig. Maintenant quand la page est chargée pour la première fois, l'initialisation est faite dans l'action1 (bean.property si le bean y est sinon null) et quand je reviens à la page après erreur de validation (validation dans action2) les valeurs rentrées sont maintenues. Donc ca marche parfaitement bien! Et je comprends mieux le cycle de vie de l'ActionForm. J'ai aussi constaté, en rajoutant name="formBean" à la config de l'action1, Struts demande un input qui si j'ai bien compris est obligatoire pour envisager une validation sur le formulaire, comme je l'ai fais dans l'action j'ai rajouté validate="false" et ca a suffit! Par contre je n'ai pas encore essayé le tag <html:base/> pour mes problèmes de css. Je vais probablement l'essayer, mais si j'ai bien compris il n'y a pas grande différence entre forward et redirect qui nécessiterait que je les remplace partout dans mon code. J'ai d'autres questions concernant Struts mais pas forcément l'initialisation du formulaire, Est ce que le mieux c'est de mettre résolu ici et de poster mes autres questions sous un autre titre? Merci beaucoup.

[c_nvy]

J'ai aussi constaté, en rajoutant name="formBean" à la config de l'action1, Struts demande un input qui si j'ai bien compris est obligatoire pour envisager une validation sur le formulaire, comme je l'ai fais dans l'action j'ai rajouté validate="false" et ca a suffit!

Le fait de mettre l'attribut validate à false dans le mapping de l'Action d'initialisation est logique parce que si tu le mets à true, à l'appel de l'Action, comme rien n'a encore été saisi dans le formulaire, la méthode validate s'exécutera et tu auras des messages d'erreur qui s'afficheront dans la page.
D'ailleurs, dans l'exemple de mapping pour l'Action d'initialisation que j'avais donné au début de la discussion, l'attribut validate avait bien pour valeur false.

Par contre je n'ai pas encore essayé le tag <html:base/> pour mes problèmes de css. Je vais probablement l'essayer, mais si j'ai bien compris il n'y a pas grande différence entre forward et redirect qui nécessiterait que je les remplace partout dans mon code.

Et si, il y a une grande différence entre le forward et le redirect.
Dans le cas du forward, l'URL affichée dans la barre d'adresse est celle de l'Action appelée avant l'affichage de la page, ce qui explique ton problème d'accès aux css et aux images.
Dans le cas du redirect, comme une nouvelle requête est générée, l'URL affichée dans la barre d'adresse est l'adresse véritable de la page, ce qui explique que dans ce cas, tu n'as pas de problème pour accèder aux css et aux images si tu as codé un chemin relatif par rapport à cette page.
Voilà pourquoi je t'ai conseillé d'utiliser le tag <html:base/> dans le cas où tu optes pour les forward.

J'ai d'autres questions concernant Struts mais pas forcément l'initialisation du formulaire, Est ce que le mieux c'est de mettre résolu ici et de poster mes autres questions sous un autre titre?

A partir du moment où les questions n'ont rien à voir avec le sujet initial de cette discussion, il est préférable de mettre le tag Résolu sur celle-ci et d'en ouvrir une nouvelle avec le titre adéquat.

Avant de poster une nouvelle discussion, au cas où le sujet aurait déjà été traité sur le forum.
De plus, il existe de très bon tutoriels dans lesquels sont très bien décrits les mécanismes de Struts.
Je t'invite donc à en consulter au moins un si tu veux gagner du temps dans tes développements.