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