[scope] request ou session ?

Version imprimable

17/07/2007, 18h17
phoebe

[scope] request ou session ?

Bonjour à tous,
tout est dit dans le titre... je n'arrive pas vraiment à savoir pourquoi utiliser plus l'un ou l'autre donc j'aimerais avoir vos avis sur la question.

Généralement, pour vos développement vous mettez vos Form en Session ou en Requête ?

d'avance merci !
17/07/2007, 18h23
Sceener

Personnellement , pour partager des données entre divers formulaire , j'utilise le scope session sinon entre deux formulaires request est sufisante.
17/07/2007, 23h17
phoebe

en fait j'utilise un LookupDispatchAction et j'ai une List dans mon Form que j'aimerais ne charger qu'une seule fois, est-ce possible avec un scope request ?

parce qu'à chaque fois que je passe dans mon action la List est à nouveau vide, et donc actuellement je suis obligé de refaire une requête en base pour recharger la List...
18/07/2007, 08h14
OButterlin

C'est possible sous certaines conditions, mais il faut comprendre qu'avec le scope request, ton formulaire est instancié à chaque nouveau request (donc, en théorie, tu recharges ta liste à chaque fois)...
Cependant, si ta liste est sauvegardée en session (uniquement la liste j'entends), tu peux très bien l'affectée par la méthode reset à ta liste de l'ActionForm.
En pratique, le scope session semble mieux adapté pour ça (encore que...ça dépend des cas...)

A+
18/07/2007, 09h53
phoebe

Si toutes les actions de mon application sont en scope session, ça ne risque pas de surcharger inutilement la session et donc de ralentir l'application ?
18/07/2007, 10h20
OButterlin

Tu veux dire tes formulaires je suppose...
Bon, c'est sûr que tu charges la session mais de là à ralentir l'application, je ne crois pas, au contraire, l'extraction de données d'une base est bien plus coûteux ;)
La session peut aussi avoir des inconvénients :
si ton poste client ouvre 2 navigateurs, par défaut, ils auront la même session, donc attention aux écrasements de valeurs.
18/07/2007, 10h31
phoebe

oui je voulais dire les formulaires en effet...

Je viens de lire sur le net que le scope session n'est utile que lorsque plusieurs actions se partagent un formulaire, or dans mon cas je n'ai qu'une action mais c'est une DispatchAction, donc on pourrait considérer qu'il s'agit de plusieurs actions non ?
18/07/2007, 11h05
OButterlin

Oui, si on veut... plusieurs "actions" qui partagent la même définition (struts-config.xml)

L'utilisation (type) de la session serait du genre :

Action1 -> Page1 -> Action2 -> Page2 -(retour)-> Page1

Avec request, à ton retour sur Page1, il n'y aura plus de données (c'est bête :aie:)
18/07/2007, 11h21
phoebe

actuellement mes formulaires sont tous en scope request et les attributs de mon formulaire sont uniquement les données que l'utilisateur peut renseigner sur la page de saisie, je place les listes en session, est-ce une bonne démarche ?
18/07/2007, 11h42
OButterlin
Comme dit, ça peut être la bonne solution, tout dépend de ce que tu feras par la suite en terme de navigation...
Pour ce qui est de l'optimisation de ressources DB (en l'occurence tes listes) associées au formulaire, oui, c'est clairement une bonne solution.
Si tes listes sont figées, tu peux même passer au scope serveur plutôt que session, là, ce sera le ponpon :mouarf:
Code:

1 2 3 4 5 6 // Pour y accéder System.getProperties().get("maListeFigee1") // Pour la mettre en scope serveur System.getProperties().put("maListeFigee1", maListe1);
18/07/2007, 12h05
phoebe

scope serveur ??

tu veux dire ApplicationContext je suppose...
18/07/2007, 12h30
phoebe

Bon en fait je vais présenter la fonctionnalité que j'essaie de développer actuellement :
J'ai donc un écran avec 3 tableaux, lorsque je sélectionne une ligne du premier tableau le deuxième tableau est mis à jour et lorsque je sélectionne une ligne du deuxième tableau le troisième tableau est mis à jour et enfin quand on sélectionne une ligne du troisième tableau alors des champs de saisie apparaissent dessous les tableaux avec un bouton valider.

Comment feriez vous cela ? dans les grandes lignes...
18/07/2007, 13h39
OButterlin

1) oui pour ApplicationScope
2) dans les grandes lignes alors :

Solution 1 :

Si les questions sont fixes, je les mettrais dans ApplicationScope.
Ensuite, pour la suite d'écran, le scope request va très bien (par contre, j'interdirais de modifier la liste correspondant à la question source -> il y a le back pour revenir, sinon, il faut gérer onchange...) avec dans la méthode reset l'affectation de la liste qui va bien.

Pour ce qui est de l'écran de fin, si les paramètres dépendent des questions précédentes, j'utiliserais des include ou mieux, des tiles.

Solution 2 :

j'utiliserais AJAX pour le chargement des listes et le chargement des attributs à la fin.
L'avantage, tu ne gèrerais plus qu'une seule page.
L'incovénient, c'est plus lourd à mettre en place

Solution 3 :

Si le volume global des listes n'est pas trop important, tu peux aussi gérer des listes dépendantes avec du javascript.
En gros, tu envoies tout pour construire des objets javascript et tu construits les listes à la volée en fonction des choix de l'utilisateur.
L'avantage, il n'y a plus d'aller/retour au serveur jusqu'à la validation
L'inconvénient, c'est plus lourd

Il y aurait d'autres possibilités, voir des mixes, mais bon, on ne va pas faire de liste exhaustive non plus :P
18/07/2007, 14h13
phoebe

bon alors je précise un peu, quand je dis 3 tableaux dépendants les uns des autres il s'agit de trois listes (entêtes sur la première ligne puis 3 à 4 colonnes dans chaque liste) les listes sont dépendantes du référentiel donc nécessite une requête en base pour les charger.

point important : les 3 listes sont sur une même et unique page

et on oubli Ajax, je souhaite faire sans... c'était possible avant donc ça doit toujours être possible.
18/07/2007, 14h26
OButterlin

C'est un traitement du genre :

liste1 = en-tête de commande
liste2 = lignes d'une commande
liste3 = lots choisis par article

que tu veux faire ?

Si oui, ça change un peu les données et du coup, j'utiliserais le scope session (pour ne pas recharger les listes au-dessus tout le temps et limiter les accès DB)
avec une gestion de sélection de ligne par tableau (un truc que struts-layout rend assez simple en fait) et une action différente en fonction du niveau d'appel (en-tête, ligne, lot), avec LookupDispatchAction c'est OK (perso, j'utilise DispatchAction, je trouve ça plus intuitif)

(et effectivement, on peut oublier ajax)

oui c'est ce genre de listes dépendantes que je souhaite faire et en fait j'utilise DispatchAction et non LookupDispatchAction.
Donc en fait il faut que je déclare mon action avec un scope="session" dans mon struts-config.xml si je comprend bien et mon Form sera alors :

Code:

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
 
public class RefForm extends AbstractForm {
 
	private String	indexSelected_1;
	private String	indexSelected_2;
	private String	indexSelected_3;
 
	private List liste_1;
	private List liste_2;
	private List liste_3;
 
 
    public RefForm() {}
 
    public void reset(ActionMapping mapping, HttpServletRequest request) {
        super.reset(mapping, request);
        indexSelected_1 = "";
        indexSelected_2 = "";
        indexSelected_3 = "";
        liste_1 = null;
        liste_2 = null;
        liste_3 = null;
    }
 
    public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
        ActionErrors errors = new ActionErrors();
 
        if (getDispatch() != null && getDispatch().equals("ref_valider")){
        	//Vérification des données saisies par l'utilisateur
        	//...
        }
 
        return errors;
    }
}

c'est bien ça ?

18/07/2007, 14h44
OButterlin

Surtout pas !
Avec le scope session, il ne faut pas remettre tes listes à NULL ou tes valeurs sélectionnées dans reset (il faut juste ne pas oublier de faire un "clear" sur les "sous-listes" et les valeurs sélectionnées associées quand tu charges un élément au-dessus, mais dans tes actions)
18/07/2007, 14h48
phoebe

donc avec un scope="session" on utilise pas du tout le reset ?
18/07/2007, 14h57
OButterlin

en l'occurence, non
18/07/2007, 15h04
phoebe

OK merci, je pense que je vais utiliser un scope session pour toutes mes actions, ça sera moins compliqué et donc gérer le "reset" dans mes Actions.

en tout cas un grand merci pour tes lumières ;)
18/07/2007, 15h20
OButterlin

Je t'en prie... A une autre fois peut-être et bonne continuation...
18/07/2007, 17h04
phoebe

heu... finalement il me reste une dernière question suite au fait que j'utilise désormais le scope="session" :

Comment faire pour réinitialiser mon formulaire ?

en fait j'aimerais que le formulaire soit réinitialisé à partir du moment où on change d'action parce que là quand je change d'action (à partir du menu de mon application) et que je reviens dessus alors là elle reste dans le même état que je l'avais laissée...

Je sais bien que c'est en session donc normal mais comment fonctionne les struteurs habituellement ?
18/07/2007, 17h34
OButterlin

Tu peux créer une action d'initialisation par exemple, c'est comme ça que je procède...
Tu pourrais aussi supprimer l'objet de la session, ou le remplacer par un nouveau dans une action, mais j'aime moins...
18/07/2007, 17h41
phoebe

j'avais pensé à la même chose que toi concernant l'action d'initialisation mais ça veut dire qu'au lieu d'avoir N actions dans mon application j'en aurais 2*N

tout le monde fonctionne comme ça ? c'est la philosophie de Struts ?
18/07/2007, 17h44
OButterlin

Je dirais plutôt N + 1, il te faut une action d'initialisation du formulaire (entier)
18/07/2007, 17h51
phoebe

oui mais pour toutes mes actions j'aurai besoin d'une action d'initialisation, enfin toutes celles qui sont en scope="session"
18/07/2007, 18h02
OButterlin

C'est un prix a payer pour limiter les accès DB.
C'est quand même pas la mer à boire non plus...
19/07/2007, 00h39
phoebe

bon en tout cas merci beaucoup, ça me permet d'avancer