<snip> I think whatever you do you can't make JSP and Action Class independent. Where are you populating ActionForm Object from the results from service layer? In Action class only right? Which you know very well for which JSP page it will be applicable. </snip>
True <snip> How one can populate resultset in action form which will automatically get populated in html table.. </snip> Shouldnt be passing a resultset to the JSP. Better to extract the info you need from it so you can free up the connection before forwarding to the JSP. Take a look at: http://jakarta.apache.org/commons/beanutils/api/ -----Original Message----- From: Pradeep, PK [mailto:[EMAIL PROTECTED] Sent: Friday, 27 February 2004 15:02 To: Struts Users Mailing List Subject: RE: FormBeans: A question of Style I think whatever you do you can't make JSP and Action Class independent. Where are you populating ActionForm Object from the results from service layer? In Action class only right? Which you know very well for which JSP page it will be applicable. Also is it easy to populate all what you need in ActionForm? How one can populate resultset in action form which will automatically get populated in html table.. -----Original Message----- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 11:41 AM To: Struts Users Mailing List Subject: Re: FormBeans: A question of Style I consider the ActionForms to be part of the view primarily. They should both collect submitted data and provide the JSP (or other view components) with most or all the data they need to render the page (camp 2). I say 'most' only because sometimes custom tags can be useful for getting data for list boxes, etc. All the data that the Action collects, however, should be carried to the JSP in the ActionForm. The alternatives for carrying data from Actions to JSPs for the camp 1 gang are not attractive, in my opinion. Having an Action put a bunch of stuff into the request or session scope creates a lot of coupling between the Action and JSP. The Action must know where to put it and the JSP must know where to find it with that scenario. I prefer to keep the Actions and JSPs loosely coupled by having them both depend on the ActionForm, rather than depending on each other. The Action populates the ActionForm, and the JSP renders it. For complex pages, the ActionForm can be the root of an object graph that contains all the data you need to render the page. Stashing additional info all over the session and request is "sloppy" by comparison, in my opinion. I think the "ActionForm is the root of all view data" approach promotes more concentrated thought about the structure of the data, which is a good thing. It provides a more concrete interface between the controller (Action) and view (JSP) components. Maintaining JSPs that get their data from one place is much easier than maintaining JSPs that have to collect, organize, and display data from multiple sources. JSPs that pull data from the ActionForm, stuff stashed in the session, and/or stuff stashed in the request are harder to maintain. Where do I find it? How does it all relate? Yuk! -Max On Thu, 2004-02-26 at 17:57, [EMAIL PROTECTED] wrote: > We have 2 camps of thought on the subject of the appropriate use of Struts > form beans. Here are the thoughts: > > Camp 1: Form beans are controller components and should be used only to > transport user input data between JSP forms (or across JSP forms) and > Action classes. > > Camp 2: Form beans should be use for what "Camp 1" thinks, plus they should > also contain all the data a JSP uses to render a page (i.e. All the model > data is inserted into the form bean as well as the form data.) > > Any thoughts? > > Scott > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
