On 12/05/2005 16:34, "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> I've always felt the ActionForm had become something that wasn't > originally intended... I personally use it as something that applies to a > PAGE and not just a form, so it becomes an I/O object for me in the truest > sense. So you mean, on your actionform you use: The html form attributes + (this is what I understand for input) The collections needed to present combo/list boxes (and other options) (this is what I understand for output) I don't think #2 is this one. This is #4. > > I love the idea of something like a Velocity-type context. Before I came > to Struts I was using a custom framework that was similar in that fashion, > and went a step further in that there was a single WorkContext object that > handled communication between ALL layers. I don't think that's the > optimal solution now, but I think it was a step in the right direction... > This seems a little different approach > I toyed with implementing a true VTO/BTO pattern in Struts a while back, > that is, a single VTO (View Transfer Object) that handled all values > passed to and from the view, and the usual BTO or DTO (Business Transfer > Object when discussed in the context of a VTO, or just the usual Data > Transfer Object) to communicate between the controllers and the business > delegates. I do almost the same thing. (this seems #2) Use a ActionForms for retrieving only the HTML form data. The update of some data is a "special" case: - store the business object (only the bo id will not be enough... someone can override the form and set the property of the id) on a special attribute on the ActionForm and put the ActionForm with "session" scope This way I check for: - updating a bo with the same type and id? So I use only the actionform for: The html form attributes + (on updates) with one property to store the bo For the combo/list/etc I use a java bean stored on the request. So this approach is #2 +1 extra property. Just to finish I have to agree with Ted that "clarify whether by output we mean output that is being used within the <html:form> tags, or any arbitrary dynamic output." and maybe this is the source of all problem. I read Chuck Cavaness book and (correct if I am wrong... it has been 2 years) he usually retrieved the BOs from the model/persistence layer and then created view objects (POJOs). I remind him mixing this data on an ActionForm. Pedro Salgado > > Most people I think agree with the idea of a single object communicating > between the control and the model, i.e., I don't see too many people > saying we should have one object that goes TO a business delegate and one > that comes FROM that delegate, i.e., two DTOs per model call, although I > suppose there are some valid arguments for that. The point being, if you > agree with that approach, I can't see NOT taking the same approach between > the control and the view, and likewise, if you do see a two-object > communication between control and model as better than you likely feel the > same way about between view and control. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Thu, May 12, 2005 10:20 am, Ted Husted said: >> On 5/12/05, Pedro Salgado <[EMAIL PROTECTED]> wrote: >>> >>> Well, your option 1) matched the #2 >>> and >>> 2) matched the #4 >>> >>> :) >>> >>> Pedro Salgado >> >> It might be helpfult to clarify whether by output we mean output that >> is being used within the <html:form> tags, or any arbitrary dynamic >> output. >> >> The intended use of the ActionForm is to represent the values of the >> controls *within* a form. In Struts 1.1, the scope crept so as to >> include, for example, lists used to populate controls. >> >> The cannonical role of the ActionForm is to represent what the user >> might input into the form, or to default input on behalf of the user >> (e.g, to edit values previously input.) I don't know if the latter >> case, providing default input values, counts as "output" in this >> thread. >> >> Plunking into an ActionForm something like a result list from a search >> query is an unintended use. The ActionForm was not designed as a >> Velocity context, but as a way of vetting input from forms. >> >> If people are putting result lists on ActionForms, that don't >> represent input values, then I can understand why multiple ActionForms >> might be an issue. But, personally, I don't see a compelling argument >> for putting arbitrary dynamic data on an ActionForm. Any POJO would >> work as well. >> >> I could see a case for a Velocity-type Context that might include an >> ActionForm as a member, but I would not recommend trying to subvert >> ActionForms as a Velocity-type Context. If people want a Velocity-type >> Context, then let's do that, and put the ActionForm inside the page >> Context. >> >> -Ted. >> >> --------------------------------------------------------------------- >> 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]
