Yes, the ActionForms exist to provide an input buffer for the HTML controls, just so that you can validate the input, and either return it for correction, or commit it to a business layer object.
The second, very important, service that ActionForms provide is to act as a firewall between the untrusted HTTP layer and the rest of your application. The Struts reflection mechanism can populate any property on your ActionForm, whether you put it on a form or not. This is a very important reason why ActionForms are not an interface. Most existing objects are not sufficiently paranoid to be exposed to the Web tier, where anything can happen. (: And usually does :) In practice, the ActionForms themselves are often just wrapper objects, with the real intelligence residing in classes in the business layer. The less done with an ActionForm, the better. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Alex Colic wrote: > > Thanks a lot I really appreciate all the advice. It really helped me out. > One thing you said really surprised me. You said: > > >For ActionForms, my preference is to use larger generic form beans. They > >are really a throw-away object, and linking them too closely to a > >hierarchy can be a waste of time. > > I have been doing the opposite of generic forms. My forms usually consist of > objects within object. For example I might have an invoice object that has > and employee and a part object within it. It would have been faster for me > to make on big flat form but I thought that it would be better to break it > up amongst a number of objects. Looking back though, most of my forms all > they do is collect data that is used somewhere else. > > Something for me to think about. > > Thanks > > Alex -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
