Quelques "précisions" sur Struts

**Atma_** · 30/10/2006, 15h59

Bonjour à tous

J'viens de passer une journée "d'autoformation" au framework struts .. et subsistent encore dans ma tête un certain nombre d'interrogations concernant des sujets divers et variés (que je n'ai pas trouvé dans la FAQ)

Donc j'y vais ... n'hésitez pas si vous connaissez la réponse à l'une d'entre elle ... je suis preneur ^^

1] Le "scope" des ActionForm est soit request, soit session ... il est dit que cela sauvegardera le FormBean dans la requete ou dans la session ...
Est-ce que vous auriez un exemple concret de la sauvegarde du FormBean en session ... parce que j'vois pas trop trop ...

2] Dans la balise <html:javascript>, que signifient les attributs "staticJavascript" et "dynamicJavascript" ?... Ils sont positionnés à true... mais je ne sais pas vraiment "pourquoi" et ce que cela signifie

3] Prenons le "validateur" intRange disponible dans tout bon validator-rules.xml

Ce validateur prend deux "paramètres", min et max, lorsqu'il est "utilisé" dans un depends ... Où peut-on connaître le nom des paramètres passés à un validateur donné ?... Je n'ai rien trouvé dans le validator-rules.xml ... faut-il avoir accès au code source de la classe Java censée réaliser le test pour connaître les noms des paramètres à passer ?
Ca me paraît bizarre ... (et pas du tout cohérent avec le comportement qu'on peut avoir, par exemple, avec les taglibs, où on a un descripteur qui nous permet de rapidement "voir" les attributs qu'on peut utiliser sur les taglibs utilisées)

4] Pourquoi est-ce que les codes "client" fournis dans le validator-rules.xml sont aussi "compliqués" ... par exemple, si je prend le code de "maxlength" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
      <validator name="maxlength"
            classname="org.apache.struts.validator.FieldChecks"
               method="validateMaxLength"
         methodParams="java.lang.Object,
                       org.apache.commons.validator.ValidatorAction,
                       org.apache.commons.validator.Field,
                       org.apache.struts.action.ActionErrors,
                       javax.servlet.http.HttpServletRequest"
              depends=""
                  msg="errors.maxlength">
 
         <javascript><![CDATA[
            function validateMaxLength(form, prefix) {
                var isValid = true;
                var focusField = null;
                var i = 0;
                var fields = new Array();
                oMaxLength = (prefix == null) ? new maxlength() : eval("new " + prefix + "maxlength()");
                for (x in oMaxLength) {
                    var field = form[oMaxLength[x][0]];
 
                    if (field.type == 'text' ||
                        field.type == 'textarea') {
 
                        var iMax = parseInt(oMaxLength[x][2]("maxlength"));
                        if (field.value.length > iMax) {
                            if (i == 0) {
                                focusField = field;
                            }
                            fields[i++] = oMaxLength[x][1];
                            isValid = false;
                        }
                    }
                }
                if (fields.length > 0) {
                   setFocus(focusField);
                   alert(fields.join('\n'));
                }
                return isValid;
            }]]>
         </javascript>
 
      </validator>

... Ca me parait bien compliqué pour quelque chose dont je m'attendais à ce qu'il fasse (a peu de chose pret) un :

Code :

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

1
2
3
4
5
6
7
 
         <javascript><![CDATA[
            function validateMaxLength(form, prefix) {
                var champVise = /*....*/
                return champVise.value.length < max;
            }
         </javascript>

Y a-t-il une raison à cette complexité ? J'avoue que je suis loin de piger tout ce qui est fait dans cette fonction javascript (et pourtant je n'en suis pas a mes premieres appli web ...)
Est-ce une question de portabilité inter navigateurs ? (j'ai pas trop l'impression mais bon ...)
Un comportement générique de Struts ? (mais dans quel but ?)

Merci d'avance à toutes les bonnes âmes qui participeront à ce thread

**zurich** · 30/10/2006, 17h02

1)
mettre un oblet en session:

Code :

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

1
2
3
 
HttpSession session = request.getSession(true);
session.setAttribute("monObjet", object);

recuperer l'objet de la session:

Code :

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

ClassDeObjet objet =( ClassDeObjet ) session.getAttribute("monObjet");

**Atma_** · 30/10/2006, 17h13

merci je sais utiliser l'objet session

Ce que je demandais c'était un exemple concret dans lequel il y avait besoin de sauvegarder un formbean en session (parce que la, comme ca, je vois pas trop ce à quoi ca peut servir à part "mal utiliser" l'objet session ...)

**fr1man** · 30/10/2006, 18h18

Ca peut permettre à un utilisateur qui reviendrait sur une page de saisie, de ne pas avoir à tout ressaisir. Les informations s'afficheraient dans les champs.

**zurich** · 30/10/2006, 18h34

Exemple:
Dans un site d'achat en ligne tant que l'acheteur ne s'est pas deconnecter lui faire savoir ce qu'il a commandé comme article, et lors du payement lui rappeler ce qu'il a dans sa corbeille et calculer le prix de ses articles.

Exemple
ramener des information d'une base de donnée et les montrer dans une jsp.
il faut que ces informations soient dans un scope afin de pouvoir les recuper via struts-tag ou autre dans la jsp

Exemple:
utilisation des memes données dans plusieurs jsp ou plusieurs actions. Cela evite de faire appelle plusieurs fois a la meme methode

...etc

**Atma_** · 30/10/2006, 21h12

ok soit, je valide

Mais ca m'étonne quand meme... en gros, tout ce que ca nous évite, c'est de faire un request.getSession().setAttribute("monForm", form); dans l'Action ... bizarre =)

**yolepro** · 31/10/2006, 11h29

Bonjour Atma_,

Plus que de ne simplement pas avoir a faire un request.getSession().getAttributes("tonForm") de maniere manuel (tu peux d'ailleurs etre anemer a le faire parfois si tu as besoin de données saisies 3 form avant...), Le but de Struts est de te remplir automatiquement ton objet Form de ce qu'a saisie l'utilisateur sans le faire a la mano, et ca c'est beaucoup de temps gagné.

**Atma_** · 31/10/2006, 11h43

oui mais ca, il n'a pas besoin d'un scope session pour le faire ... admettons que j'ai un validate qui soit pas passé, il me redirige comme un grand sur mon formulaire en préremplissant les champs que j'ai saisi

En fait, moi, ce qui m'ennuie avec cette propriété, c'est de pas savoir comment struts gère ca ... quand supprime-t-il les ActionForm qu'il a mis en session ? (puisque j'ose espérer qu'il fait le ménage parce que sinon, c'est pas très viable comme framework si beaucoup de formulaires doivent être soumis...)
=> tout ca pour dire que personnellement, je préfère "savoir ce que je fais" quand je met des trucs en session, et que ca soit à moi de dire quand je n'ai plus envie qu'ils y soient (mon formulaire global a été "validé" par exemple)
=> d'où le peu d'intéret que je trouve a ce scope selon moi...

**fr1man** · 31/10/2006, 14h10

Struts a fait ses preuves.
Si tu n'as pas besoin du scope session, c'est ton problème.
Il y a des fois où on est bien content de l'avoir.
Et puis c'est une configuration individuelle selon chaque formulaire.
Donc rien n'empeche d'avoir 50 formulaires request et 2 session.
Je ne vois pas en quoi on aurait une application non viable.

**Atma_** · 31/10/2006, 14h39

Attention, je n'ai pas dit que struts était un framework pourri... j'suis bien content, tout comme vous, de l'utiliser ... je me pose simplement certaines questions (qui fâchent visiblement

)

Ce que je dis, c'est que, prenons un exemple :
Typiquement à ce que vous me dites (et que j'ai "validé" quelques posts auparavant), l'utilisation du scope session pourrait intervenir lorsqu'on aurait par exemple un formulaire "par onglets" : on a une grosse entité avec tout plein de champs, et pour rendre le tout un minimum ergonomique, on préfère répertorier ces attributs en "onglets"
=> lorsqu'on change d'onglet, on change de formulaire, mais on a pas envie de perdre les infos qu'on a saisi dans l'onglet précédent de manière à, lors de la "validation finale" posséder toutes les informations nécessaires au bon enregistrement de la grosse entité
=> on utilise un scope session pour chacun des formulaires de ces onglets histoire que lorsqu'on revienne sur un onglet déja précédemment saisi, on ait tous les champs -qui, du coup, sont en session- qui sont correctement pré-remplis

.. ok, sur le principe, je suis d'accord..

Maintenant, ce que je ne trouve pas "propre" dans ce comportement, c'est qu'on a pas la main sur ce que fait struts avec les choses qu'il met en session.
Typiquement, je ferais les choses "a la mano" (pour reprendre l'expression de yolepro ^^), je mettrais également les informations de mes "FormBean" en session mais, une fois la création de ma grosse entité terminée, je viderais tout ce que j'ai mis en session pour faire un peu le ménage (et pour décharger un peu le serveur aussi, tant qu'a faire ...)

Si ça se trouve, struts le fait tout seul, il y a peut-être des mécanismes de garbage collector pour les choses en session, je n'en sais rien ... et c'est ça le problème : "on ne sait pas" ce qui se passe

Certes, j'exagérais lorsque je parlais de "framework non viable" à cause de cela... mais imaginons un site très fréquenté avec plusieurs milliers d'utilisateurs chaque jour, qui saisissent justement ce type de "grosse information" répertoriée en onglets (et pas forcément "nettoyée" en session) => ça peut prendre pas mal d'espace dans les session ce genre de choses, et donc peser sur les performances du serveur d'appli

=> d'où mon interrogation sur l'utilisation de l'attribut scope=session lorsqu'on veut "bien faire" (entendez par la "optimiser ce qui est stocké en session" << je suis bien d'accord que tout le monde n'a peut être pas en tête ces priorités... ou en tous cas préfère ne pas s'embêter avec des choses à la mano quand un mécanisme tout prêt existe déjà, mais moi j'ai cette préoccupation et ce n'est pas une raison pour me dire que "c'est mon problème" ... je ne pense pas être seul au monde a penser ça

)

Maintenant, je peux tout à fait me tromper hein, je ne dis pas du tout que j'ai la science infuse et c'est un peu une des raisons pour lesquelles je suis venu discuter des points qui m'interpellent ici : j'aimerais construire mon "expérience" struts à l'aide de celle des autres

**fr1man** · 31/10/2006, 14h55

Mon point de vue est le suivant:
utiliser le scope request autant que possible et garder le scope session
quand on a pas le choix.
De plus, la plupart du temps, un formulaire contient des données simples et donc n'occupe pas beaucoup de place en mémoire.
Il s'agit juste de faire attention à ce qu'on fait, qu'on utilise Struts ou pas.

Pour finir, je ne pense pas que Struts nettoie quoi que ce soit en session, puisque l'intérêt d'une session est d'y stocker des données.
Si tu veux nettoyer, tu peux le faire toi même, comme tu le ferais avec tes objets.

**Atma_** · 31/10/2006, 15h05

... le problème est que je ne sais pas réellement ce que struts met en session

Par exemple, quelles clefs initialise-t-il lorsque je met un scope session ?
D'autre part, d'un point de vu "responsabilité" de ce qui est entrepris, je trouve "casse gueule" le fait de trifouiller des données session dont je ne suis pas le "gestionnaire" (sait-on jamais... si struts les a initialisé, peut-être est-ce qu'il les flush a un moment donné... ou qu'il les réutilise pour des choses auquel on n'aurait pas pensé => c'est "risqué" de bidouiller quelque chose dont on est pas "maître"

... et c'est principalement en ça que je trouve ce scope session dérangeant

)

Sinon, content de voir qu'on peut être d'accords sur certains points =)

**fr1man** · 31/10/2006, 15h10

Pour moi, Struts fait lui même un session.setAttribute de l'objet formulaire en question. Je ne pense pas que ce soit plus compliqué que ça.

**Atma_** · 31/10/2006, 15h30

je confirme, il met comme clef le "name" de mon ActionForm ... et c'est tout ce que j'ai en session

**yolepro** · 03/11/2006, 11h31

Rebonjour Alma_,

Le comprend ton attention particulier a vouloir maitriser ce que tu mets en session (et c'est bien normal).

Maintenant sache que les formulaires Struts ne doivent normalement contenir que ce qui s'affiche a l'ecran (quelques champs String), donc disons que tu ais 50 champs / form tu peux en mettre avant de faire exploser ta session.
Ce sont des formulaires de navigation et non des formulaires devant transporter tes objets metiers.

Si tu veux y mettre des objets metiers, alors libre a toi, mais il faudra effectivement faire attention a ta session. Tu peux très bien suprimer un form Struts de la session en faisant un session.removeAttributes("nomdetonFormStruts").

**yolepro** · 03/11/2006, 11h36

Envoyé par Atma_

... le problème est que je ne sais pas réellement ce que struts met en session

Par exemple, quelles clefs initialise-t-il lorsque je met un scope session ?
D'autre part, d'un point de vu "responsabilité" de ce qui est entrepris, je trouve "casse gueule" le fait de trifouiller des données session dont je ne suis pas le "gestionnaire" (sait-on jamais... si struts les a initialisé, peut-être est-ce qu'il les flush a un moment donné... ou qu'il les réutilise pour des choses auquel on n'aurait pas pensé => c'est "risqué" de bidouiller quelque chose dont on est pas "maître"

... et c'est principalement en ça que je trouve ce scope session dérangeant

)

Sinon, content de voir qu'on peut être d'accords sur certains points =)

Je ne comprend pas en quoi tu n'es pas maitre de ce qui est mis en session. C'est toi qui nomme ton form dans ton action donc derriere dans ta tête tu sais que ca sera sous ce nom qu'il sera mis en session.
Maintenant, il n'y a rien de magique derriere Struts, pour t'en assurer, il suffit de jetter un oeil sur les Classes qu'il implémente (les sources sont disponibles) : RequestProcessor, ActionServlet...

**Atma_** · 03/11/2006, 11h43

Je suis d'accord avec tout ça

J'pense que c'est un peu plus clair dans ma tête depuis 2-3 jours en effet (merci aux participants)

(cela dit, je sais pas si, dans une Action, je supprime mon Form de la session, tout va marcher correctement ensuite... m'enfin j'm'en fiche, je ne suis *pour l'instant* pas confronté au problème ^^)

=> ya d'autres questions sans réponses dans mon post initial !!

**yann2** · 03/11/2006, 13h42

Salut

=> ya d'autres questions sans réponses dans mon post initial !!

Je sais mais je n'y répondrai pas

.

Pour revenir sur le scope... Ca permet également à struts de savoir où chercher l'instance de l'ActionForm à utiliser.

Si tu fais une gestion manuelle, Struts ne peux pas savoir s'il doit chercher dans la session, la requête ou utiliser une nouvelle instance d'ActionForm

. D'ailleurs JSF utilise également l'attribut scope. Comme quoi...

**yolepro** · 03/11/2006, 14h59

Pour les autres questions :

La deuxieme, je pense qu'il suffit de lire la doc de Struts ou sur google tu trouveras une réponse rapidement.

Pour la derniere question, il y a une notion de potitionnement du curseur lorsqu'une erreur est remontée qui fait que cela complique le code (en gros quand tu as une erreur, il mets le contenu du champs en erreur en rouge et il met le curseur sur ce champs).

Et pour la question 3... c'etait quoi déjà la question 3...

**Atma_** · 03/11/2006, 15h20

En gros, si je reformule : où est-ce qu'on peut connaître les "paramètres" passés aux différents "validateurs" (définis dans le validator-rules.xml) ?
Un exemple de ces paramètres : pour le validateur minlength, on a un paramètre "minlength" à passer ... pour le validateur intRange, on a deux paramètres "min" et "max"

=> si je ne connais pas le validateur en question (voir, si je veux faire mon propre validateur

), où est-ce que je trouve les paramètres passés ?

Quelques "précisions" sur Struts

Struts 1 Java

Discussions similaires

Partager

Partager