Discussion :

[Mister Nono]

Bonjour à tous,

Je me renseigne depuis plusieurs jours sur Struts et sa philosophie.

Voilà donc ma question à ce sujet qui sera certainement évidente pour beaucoup mais les tutoriels sont souvent flous pour cette réponse.

Quant un formulaire (dans un JSP) est validé, les valeurs sont transmises à l'ActionForm qui contrôle les saisies. Celui-ci ressemble très fortement à un Bean avec d'autres méthodes comme reset, validate...
Les propriétés doivent être similaires aux balises du formulaire : String nom; pour <input name="nom"...> dans le JSP.

Ensuite l'Action s'occupe de la partie métier en récupérant le contenu du Bean associé au formulaire.

Donc et si je ne me trompe pas on obtient :

Code :

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

1
2
3
4
5
 
Le JSP (personne.jsp)
Le Bean associé (PersonneBean.java)
Le ActionForm (PersonneForm.java)
Le Action (PersonneAction.java)

Maintenant, et c'est là que je ne comprend pas :

Pourquoi définir un Bean ET un ActionForm puisque les deux classes sont quasi identiques : en faite, ActionForm pourrait être un descendant (ou quelque chose comme cela) du Bean ?

Existe-t-il donc un moyen de simplifier ce modèle de conception et de réduire le nombre de lignes à écrire ?

Par exemple, un DynaActionForm permet le retrait des get et set dans le ActionForm.

Merci pour vos suggestions.

[Lil'Ing]

Hello.
l'ActionForm represente le bean associé a l'Action.
vous pourrez utiliser simplement le jsp, l'Action et l'ActionForm. pour creer un bean l'ActionForm sera appelé directement par l'action en utilisant le struts-config.xml.
De là, le bean represente des lignes de codes de +.

[Mister Nono]

Hello.
l'ActionForm represente le bean associé a l'Action.
vous pourrez utiliser simplement le jsp, l'Action et l'ActionForm. pour creer un bean l'ActionForm sera appelé directement par l'action en utilisant le struts-config.xml.
De là, le bean represente des lignes de codes de +.

Alors pourquoi, dans de nombreux exemples il y a l'ActionForm, l'Action ET le Bean associé au formulaire ?
Il semble que de nombreux informaticiens utilisent ce dernier modèle. Qu'est-ce que cela apporte de plus par rapport au modèle sans Bean ?

Merci encore.

[Mister Nono]

Et bien alors, je ne déchaine pas les passions.

Moi qui voulais des avis de personnes averties.

A+

[david06600]

A mon avis c'est pour mieux séparé differentes couches de l'application, la rendre réutilisable et plus facile à maintenir et aussi dans le cas ou tu changerai de techno (struts à swing ou autre). Voila mon avis, mais je ne suis pas un expert donc je ne m'avance pas trop. Tu peux recherché sur les antipatterns de conception d'application web Servlet/jsp, je pense que tu devrais trouvé des réponses.
++

[OButterlin]

Il faudrait voir les choses comme ceci :

l'actionForm représente les données de la page
l'action représente le controleur de la page
le bean (généralement), est un objet métier (et on peut en utiliser plusieurs pour charger un actionForm)

Donc, l'actionForm est une instance liée au request (ou session), il y en a autant que d'instance de pages alors qu'il n'y a (ou qu'il ne pourrait y avoir) qu'un bean métier.

C'est plus clair comme ça ?

A+

[Mister Nono]

Merci pour ton avis et c'est bien ce que j'avais compris, mais je voulais avoir une confirmation.

Mais que veux-tu dire par cette phrase :

le bean (généralement), est un objet métier (et on peut en utiliser plusieurs pour charger un actionForm)

Comment peut-on utiliser plusieurs beans pour charger un actionForm ?

Merci encore.

[OButterlin]

Quand tu as une page complexe, qui fait référence à des "entités" différentes, on utilise généralement un bean métier par entité, c'est plus simple à maintenir.
Par exemple, tu as une page représentant une facture, tu pourrais avoir des onglets, un pour les informations facture, un autre pour des informations client.
Dans ce cas, ton actionForm aura des données de "types" différents, et on utilisera un bean facture et un bean client.
A vrai dire, ça va dépendre de ton découpage "métier".
Il faut voir l'actionForm comme l'objet d'interface avec la page JSP et le bean métier comme l'objet d'interface fonctionnelle.

C'est plus clair pour toi ?

[Mister Nono]

Merci pour tes remarques.