iteration de html:text et récup value

je suis désolé mais même en faisant la recherche sur le forum et en regardant les diverses exemples, je ne trouve pas la solution à mon problème. je ne récupere toujours pas toutes les valeurs de ma generation de html:text dynamique!!

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

//je commence par recuperer la liste de mon formulaire <bean:define id="liste" name="formParam" property="listparams" type="java.util.List" />   <html:form styleId="valparam" action="/validparam" >     <logic:iterate id="parametre" name="liste" type="*****.ParametrePopup">   bean:write name="parametre" property="libparam" />   <html:text name="parametre" indexed="true" property="valp" value="<%=parametre.getValdefaut()%>" />   </logic:iterate   </html:form>

---

Dans la plupart des posts du forums, a chaque fois dans le <logic:iterate>
, pour l'attribut name vous renseignez "formbean", c'est -à-dire la clé du form, or moi c'est une liste que j'ai dans mon logic:iterate pour le name, en conséquence, je ne peux donc pas mettre property=hasmap comme je l'ai vu souvent, sinon il me sortira une belle erreur, car il ne trouvera pas la proprieté hasmap dans le bean List.
Bref sur ce coup là jsuis un peu flingué et je sais plus trop quoi faire malgré tous les posts à ce sujet que j'ai pu lire!


Ce qu'il faut savoir c'est que moi j'envoie une list(listparams) avec mon bean form ,ensuite je récupere avec le bean-define.
Dans mon form j'ai declarer une HashMap pour recuperer les valeurs des champs de text, mais comment faire le lien entre ma hashMap et mon formulaire, etant donné que je ne peux pas mettre property="nom hashmap" dans mon logic:iterate

:cry: :cry: :cry:

J'ai déjà répondu à ce problème il y a quelques jours.

Pour résumer :

Pour le post de tes valeurs, Struts ne tient pas compte, dans ton iterate, du fait que "parametre" est un item de "liste" (contrairement à l'affichage). Ce qui est logique en fait, car Struts, quand il traite des données entrantes, ne se base que sur les "name" et les "value" de tes champs (pour faire simple), et pas du tout sur le code Struts de ta JSP.
Il fait donc, quand il voit un paramètre de name "parametre[0].valp" (c'est ce qui doit être généré dans ton HTML actuellement), un appel du genre "formParam.getParametre(0).setValp(taValeur)". Garde bien ça en mémoire dans ton dev.

Donc, dans ton form bean, tu as besoin d'une méthode getParametre(int index) du genre (le setter setParametre(int index, Object value) n'est apparemment pas utile, en tout cas pour ça) :

Code:

---

1 2 3 4 5 6

public ParametrePopup getParametre(int index) { while (liste.size() <= index) { liste.add( new ParametrePopup() ); } return (ParametrePopup)liste.get(index); }

---

C'est un peu à l'arrach', je connais pas la vraie bonne façon de faire, mais j'utilise ca actuellement pour un problème similaire, et ça marche.

moi j'avait ca

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public ParametrePopup getValparam(int i) { return (ParametrePopup) this.listparams.get(i); }   public void setValparam(int i,ParametrePopup paramp) { this.listparams.set(i,paramp) ; }

---

et devine quoi quand je fais un test en faisant un System.out dans ma classe Action pour savoir si je recupere bien ma valeur du form, et bien il me renvoie les valeurs qui sont inseres en base et ne tient pas compte des nouvelles valeurs entrés par l'utilisateur???


ta méthode permet de reinitialiser la lsit avec les valeurs de l'utilisateur ,jme trompe?

Non, ce n'est pas ce que tu fais, l'accesseur doit être sur la propriété indexée, c'est-à-dire ici "parametre", et non "valparam".
Relis mon post et regarde si ton HTML est OK.

Citation:

---

Envoyé par mnemonic78

ta méthode permet de reinitialiser la lsit avec les valeurs de l'utilisateur ,jme trompe?

---

Ma méthode renvoie un objet ParametrePopup, qu'il crée et place d'abord dans la liste si l'objet d'index "index" n'existe pas dans la liste.
Struts utilise ensuite cet objet pour faire un parametrePopup.setValp(xxx) dessus. Et remplit ainsi ta liste de ParametrePopup avec les valeurs de l'utilisateur.

P.S. : Attention, j'ai édité mon premier post tout-à-l'heure, je teste la taille de la liste à présent et non le get(xxx) == null ).

mince alors, j'en reviens pas!!!
Donc maintenant j'ai juste a changer le header de ma methode en "getParametre" au lieu de getValparam"?

Oui, mais ca ne suffira que si la taille de ta liste ne change pas et que ton form est en session. Sinon ton form sera réinitialisé au post de ta requête, et Struts essaiera à un moment ou un autre d'accéder à un item qui n'existe pas (xxx.get(5) sur une liste de 3 par exemple) => exception.
Il faut donc gérer aussi l'instanciation des items, par exemple comme fait dans mon exemple.

PUT11111111111111 CA ME SAOULEEEEEEEEEEEEEE MERDEEEEEEEUUHHHH

vas y mais nervous breakdown, c'est dingue ca!!
Je suis pas loin de trouver, mais mon soucis c'est que les valeurs que je recupere ne sont pas celle que l'utilisateur a entré, ce sont celles en base, je pige pas pourquoi, c'est pas croyable.Pour tant dans mon action je fais

formulaire.getParametre(i).getValdefaut()

Par contre quand je fais un
formulaire.setParametre(i,objet) ca marche il me remplace bien ma valeur dans le champs de texte.
Mais lorsque la personne valide le formulaire en changeant les valeurs, au lieu de recuperer les nouvelles valeurs, je recuperes les anciennes (celle du set).


Au final ca ne marche quand dans un seul sens!!!!!




Je sais plus quoi faire bordel!!!

Le plus simple pour récupérer la liste avec les valeurs modifiées est de déclarer cette liste comme propriété de ton formulaire avec getter et setter et de l'initialiser via le setter comme indiqué dans certaines discussions que tu as déjà lu.

Pourquoi ne veux-tu pas utiliser cette solution ? Tu te prendrais moins la tête.;)

mais c'est ce que j'ai fait nvy
voici mon actionForm avec ma listeparams avec get/set + methode d'idexation

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

private List listparams;   public ParametrePopup getParametre(int i) { return (ParametrePopup) this.listparams.get(i); }   public void setParametre(int i,ParametrePopup paramp) { this.listparams.set(i,paramp) ; }     public void setListparams(List listparams) { this.listparams = listparams; }     public List getListparams() { return listparams; }

---

dans mon action j'ai fais un test:
j'ai utiliser la méthode d'indexation
Param pa=new Param("code","valeur242")
formulaire.setParametre(1,pa)

Voila et devine quoi sur mon champs de texte numero 1 j'ai retrouvé "valeur242" la j'etais tout content et jme suis dis ca doit être bon!!!

Ensuite j'ai changé la valeur du champs 1 en "243", j'ai validé mes champs , et je retourne dans mon action et j'ai fais cette fois

formulaire.getParametre(1);
Ahah il me retourne "valeur242" au lieu de "243"
c'est la misere, il n'a pas mis a jour la nouvelle valeur que j'ai entré, il a gardé l'ancienne, non mais c'est pas croyable!!

Quest ce que je fais de mal???c'est moi ou quoi?

En fait, je n'avais pas fait attention mais dans le code de la jsp, tu fais un bean:define pour récupérer la liste du formulaire alors qu'il faut faire comme ceci :

Code:

---

1 2 3 4 5 6 7

<html:form styleId="valparam" action="/validparam" > <logic:iterate name="formParam" property="listparams" id="parametre"> <bean:write name="parametre" property="libparam" /> <html:text name="parametre" property="valp" indexed="true"/> </logic:iterate> <html:submit value="Valider"/> /html:form>

---

Cela suppose bien évidemment que le form-bean formParam est bien référencé dans le mapping de l'Action de path /validparam dans le struts-config.xml.

Sinon, pour initialiser la propriété valp avec une valeur par défaut, pourquoi ne pas le faire directement lorsque tu constitues la liste de beans ParametrePopup ?

ui il est bien referencé!
euh sinon valp est la propriété de mon beanMetier ParametrePopup, et je crois qu'il n'ya que ca que je puisse mettre dans property, non?
Tu penses que je ne dois pas renseigner l'attribut value?

je ne recupere toujours pas les nouvelles valeurs, c'est encore les anciennes,decidemment c'est pas mon jour!!
Mais c'est normal en fin de compte puisque le fait de valider les champs ne provoquent pas automatiquement l'exécution de la méthode setParametre(i,param).

Citation:

---

Envoyé par mnemonic78

ui il est bien referencé!
euh sinon valp est la propriété de mon beanMetier ParametrePopup, et je crois qu'il n'ya que ca que je puisse mettre dans property, non?
Tu penses que je ne dois pas renseigner l'attribut value?

---

Peux-tu me montrer comment tu constitues la liste listparams ?

Citation:

---

Envoyé par mnemonic78

je ne recupere toujours pas les nouvelles valeurs, c'est encore les anciennes,decidemment c'est pas mon jour!!
Mais c'est normal en fin de compte puisque le fait de valider les champs ne provoquent pas automatiquement l'exécution de la méthode setParametre(i,param).

---

Sinon, dans le code que tu as posté, je ne vois pas le html:submit dans le html:form. Tu en as bien mis un ?
Si oui, lorsque tu fais les modifs et que tu soumets le formulaire, dans l'Action de path /validparam, tu récupères la liste via la méthode getListparams() de l'ActionForm et tu balayes la liste et à ce moment-là, tu dois voir les modifications.

Citation:

---

Envoyé par mnemonic78

Code:

---

formulaire.getParametre(i).getValdefaut()

---

---

Ce serait pas plutôt ca qu'il faudrait faire ?

Code:

---

formulaire.getParametre(i).getValp()

---

C'est bon j'ai trouvé mon erreur, et serieux jsuis vraiment flingué du crâne!!
désolé pour ce post inutile, jle met en delestage direct!!!
Merci pour votre aide et votre patience !!!

Je cracherais pas sur le pourquoi du comment de l'histoire...

j'ai honte m'enfin bon j'avais oublié un indexed="true", sur cette jsp c'est tellement le bordel aussi, je croyais l'avoir mis, bref, une etourderie de plus quoi!!!
Sinon je n'ai pas utilisé ton bout de code où tu parcours la liste

while (liste.size() <= index) {
liste.add( new ParametrePopup() );

j'ai laissé mes méthodes d'indexation telles qu'elles étaient et ça marche quel que soit la taille de la liste, donc c'est buen!

Oui, c'est probablement (reprends moi si je me trompe) que ton form est en session et que sa taille ne change pas entre l'affichage et le submit, non ?
Dans ce cas, pas de problème, ta liste reste toujours à la bonne taille, aucun controle à faire.

A vrai dire je n'ai pas défini mon formulaire en session. A acun moment je n'ai codé session.setAttribute("monform",fomulaire);

En ce qui concerne ma liste, c'est clair qu'elle ne varie pas entre le moment ou je l'affiche et le moment ou l'utilisateur soumet ses choix!

Le form-bean est dans le scope session si tu as spécifié scope="session" dans le mapping de l'Action lié au form-bean.

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

Effectivement, le scope par défaut est session.;)

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

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".

Citation:

---

Envoyé par 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".

---

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

Citation:

---

Envoyé par mnemonic78

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.

Citation:

---

Envoyé par mixouille

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.:roll:

Citation:

---

Envoyé par c_nvy

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é.

Citation:

---

Envoyé par c_nvy

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.:roll:

---

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.

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

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.

Ben je fais comme je disais hier :

Code:

---

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.

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.;)

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.

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

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.

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.;)