Discussion :

[mnemonic78]

je n'ai pas spécifié le scope!! alors je suppose qu'il a du mettre scope="session" par defaut non?

[c_nvy]

Effectivement, le scope par défaut est session.

[mnemonic78]

ca se trouve si j'avais mis scope=request ca serait faux alors? non je ne pense pas

[c_nvy]

Si tu as deux actions liées au même form-bean, une Action d'initialisation et une qui s'exécute au submit du formulaire, il faut mettre le scope="session".

[mixouille]

Si tu as deux actions liées au même form-bean, une Action d'initialisation et une qui s'exécute au submit du formulaire, il faut mettre le scope="session".

Pourquoi ? Personnellement dans ce genre de cas j'utilise systématiquement le scope request

ca se trouve si j'avais mis scope=request ca serait faux alors? non je ne pense pas

Moi j'en suis persuadé. Car si scope request, ton objet form est détruit à l'affichage de ta JSP. Ton getXXX(index) au submit foirera vu que ta liste sera nulle ou vide. Le choix entre scope session et request n'est pas anodin et a de nombreux impacts sur la façon de coder.

[c_nvy]

Pourquoi ? Personnellement dans ce genre de cas j'utilise systématiquement le scope request.

En fait, la requête commence à l'appel de l'Action qui initialise le formulaire.
Quand la jsp s'affiche, la réponse a été construite et envoyée au navigateur, ce qui signifie que la requête est terminée.
Si tu es en scope request, le form-bean rempli n'est plus accessible au submit du formulaire, parce que c'est une nouvelle requête qui est envoyée.
Voilà pourquoi il faut utiliser le scope session dans ce cas-là.

EDIT : mixouille, après relecture de ton message, c'est bizarre car tu te contredis.
Tu dis que tu utilises systématiquement le scope request dans ce genre de cas, et après, tu expliques à mnemonic78 qu'il doit mettre son form-bean en scope session.

[mixouille]

En fait, la requête commence à l'appel de l'Action qui initialise le formulaire.
Quand la jsp s'affiche, la réponse a été construite et envoyée au navigateur, ce qui signifie que la requête est terminée.
Si tu es en scope request, le form-bean rempli n'est plus accessible au submit du formulaire, parce que c'est une nouvelle requête qui est envoyée.
Voilà pourquoi il faut utiliser le scope session dans ce cas-là.

Non non non. En scope request, au submit de la page, Struts va réinstancier un nouveau form-bean (vierge), va appeler la méthode reset() dessus (on s'en fout), et va le remplir avec les valeurs qui sont submittées. La plupart du temps, c'est bien suffisant.
Maintenant, si tu as besoin de garder des données que tu ne repostes pas (une liste de référence pour une combobox, par exemple), ou si tu as besoin de garder la référence vers ton form-bean initialement créé, le scope session est évidemment plus approprié.

EDIT : mixouille, après relecture de ton message, c'est bizarre car tu te contredis.
Tu dis que tu utilises systématiquement le scope request dans ce genre de cas, et après, tu expliques à mnemonic78 qu'il doit mettre son form-bean en scope session.

C'est pas parce que je le fais comme ca que je vais obliger tout le monde à faire pareil ! Je n'ai pas du tout dit à mnemonic78 d'utiliser le scope session, je lui ai juste dit qu'en scope session, son code marchait tel quel, alors qu'en request, non. Personnellement j'aurais fait ca en scope request.

Pour rappel, le scope session est surtout préconisé pour les beans qui ont besoin de "persistence" au fil des pages, comme pour un questionnaire sur plusieurs pages par exemple.
Utiliser le scope session pour une simple page comme ici relève plus de la bidouille, pour moi, et ne constitue pas une bonne habitude. Après, à chacun son école. L'important est de bien saisir la différence et de coder en conséquence.

[c_nvy]

Désolée mais je ne vois pas comment tu peux arriver à faire fonctionner le cas de mnemonic78 en scope request.

EDIT : L'Action qui s'exécute avant l'affichage de la jsp initialise le formulaire avec la collection.
Lorsqu'il modifie les éléments de la collection dans la jsp et qu'il soumet le formulaire, s'il est en scope request, il perd le contenu de la collection et il se retrouve avec un beau message d'erreur.

[mixouille]

Ben je fais comme je disais hier :

Code :

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

1
2
3
4
5
6
public ParametrePopup getParametre(int index) {
  while (liste.size() <= index) {
     liste.add( new ParametrePopup() ); 
  }
  return (ParametrePopup)liste.get(index);
}

Ce qui permet à Struts, à partir d'une liste vide (je l'initialise à la construction du bean), de la remplir avec les données du form, ET de créer au fur et à mesure les items nécessaires. Pour les détails, je te renvoie au début du thread où j'en ai un peu parlé. Evidemment, ca ne permettra que d'accéder aux données contenues dans le formulaire.

Tu me diras que tout ça c'est vraiment pour le principe de pas utiliser de scope session, et que ca n'a pas grand intéret à part celui de se compliquer la vie. Je te répondrais que tu as peut-être bien raison.

[c_nvy]

Mais cela suppose que ta collection de beans est vide au départ.
Or, dans le cas de mnemonic78, vu qu'il a codé un bean:write sur la propriété libparam dans la jsp, cela signifie que sa collection contient des beans ParametrePopup dont la propriété libparam est renseignée et via le logic:iterate et les html:text avec indexed="true", il permet la modification de la propriété valp.

Enfin, en tout cas, c'est comme ça que je l'ai compris.

[mixouille]

Oui, c'est ce que j'ai compris aussi.
Non, avec des cas similaires, je n'ai pas de problème, Struts reconstruit ma collection en fonction des index des champs de l'iterate, et remplit (uniquement) les propriétés renseignées dans le formulaire (le reste est évidemment perdu).
Je ne comprends pas trop le problème, je n'ai peut-être pas bien compris ton explication.

[c_nvy]

Ben désolée mais moi non plus je n'ai toujours pas compris ton explication.

[mixouille]

lol, laisse tomber, c'est pas sur un forum qu'on arrivera à se comprendre, y a manifestement quelque chose qui coince. je propose donc de laisser tomber cette discussion.

[c_nvy]

En fait, pour se comprendre, il aurait fallu que chacun poste un code exemple mais bon, comme tu dis, on arrête là la discussion.