Je me demande : un bean ca peut servir pour l'aller retour ?
 
Je m'explique :  
J'ai un formulaire de recherche...quand je l'affiche vide, je me sers du formbean dans lequel je fous les infos à afficher (les infos à mettre dans les combos, etc...)
Qd la form est submit, le form bean me renvient avec les valeurs...
et là je voudrais réutiliser le form pour y mettre les valeurs déjà soumises, + le résultat de la recherche...
 
pour faire du bean mon intermédiaire unique entre ma vue et le reste, dans un sen ou dans l'autre
 
 
/** LE background */
 
Voilà, je reprend une appli partiellement basée sur Struts, qui a dérivé vers un modèle salement XML, lourdingue, bref...
 
là je dois concevoir une petite appli à part, et c l'occasion de faire mieux.
 
Mon pb, c que g des contraintes :  
 
- le modèle existe déjà
- à un moment donné, qqc doit générer du XML selon une DTD particulière, lequel XML est transformé pour donner du HTML....g cette contrainte, c pour réutiliser un savoir faire dans l'équipe : y'a un système de maquettage, qui permet en 3 coups de XML de générer une maquette avec un look&feel de l'appli impeccable...Et ce serait un gros plus de le garder
- le XML est également soutenu pour la raison que je dois sortir du excel et du pdf à la demande, de n'importe quel écran...plus tard, je v avoir du SVG à générer
- la localization a déjà un framework dédié...que je dois utiliser
 
==>je dois donc pervertir des bouts de struts...l'idée c d'en pervertir le moins possible
 
je pensais donc refactorer comme suit :  
- une actionServlet unique
- mapping vers des ActionForward qui appellent des Command (les command sont des objets métier à moi, qui se chargent d'appeller des services, et de populer des objets du modèle avec, et les refiler à l'action)
- là, soit c un écran pour lequel on a toute les données, j'appelle une méthode toXML sur les objets de mon modèle, pour générer un gros XML à passer à ma XSL en sortie
- soit je reroute le tout (form, req, etc...) à une autre action si y'a besoin de nouvelles données)
 
un exemple : je crée un formulaire d'inscription qui comporte 5 pages...j'ai un objet métier user que je garde en session, et que j'initialise au fur et à mesure des infos entrées...de sorte que meme si on veut revenir en arrière, on ne perd rien de ce qui a été saisi
==>c'est toujours la meme action qui est appellée, elle proceed juste un form différent à chaque fois...imaginons qu'à la fin je veuille conclure en affichant le user et d'autres infos qui n'ont rien à voir avec un user, je forward alors le tout à une autre action, qui va chercher les infos qui n'ont rien à voir, et les affiche...
 
ca vous semble correct ?
 
je sais que c pas super génial de chainer des actions, mais mon appli est de type workflow donc potentiellement à chaque nouvelle étape du workflow je prend les infos d'avant auquelles je rajoute de nouvelles infos

Pour la première partie, j'ai trop rien à redire vu comme ça.  
 
Mais ton exemple d'action class unique pour plusieurs forms me choque. Tu va commencer à mettre des switches en place, pour déterminer vers quel form caster; tu vas te taper des paramètres...
 
C'est comme ça qu'on se retrouve avec des action classes de 3000+ lignes. Et je dis pas ça pour rire.
 
Des actions classes différentes ne te feront rien perdre.

ouui ca à la rigueur...je suis pas fan des switch...
 
par contre, pour le chainage : si je fais un forward, je peux transmettre le bean avec ses valeurs actuelles ? g lu un trick qui consite à mettre un flag mutable ou pas ...et mettre tt les setters qui testent ce flag...ce qui permet de mettre le bean en read-only...
 
c pas plus propre de sous classer le actionForward pour pouvoir lui passer un form ?
ou vaut mieux foutre le form dans la request ?

up

un plugin du style struts-flow pourrait peut etre t'aider :
 
http://struts.sourceforge.net/struts-flow/index.html
 

up pour nouvelle question

Ouais c'est possible, tu remets ton bean rempli dans la request et voila, sinon tu peux aussi regarder du coté des dynaForm de struts .

De toute façon son bean est déjà dans la Request.
Si il ne crée pas un nouveau FormBean dans son action il n'a pas à le remettre dans le request.

ct plus sur le fait de le surcharger avec d'autres infos