ActionForms should not contain business objects (to be explained soon). (What we use to advocate - to be corrected soon..._you can stuff biz objects directly into an ActionForm (and not flatten them out; i.e. you don't need to create fields in the form for each field in the biz object). Struts is able to deal with populating and returning nested objects. For example, you might have a "customer" bean on your ActionForm,_ and then refer to the property "customer.name" in your presentation page. This would correspond to the methods customer.getName() and customer.setName(String Name) on your customer bean. See the Apache Struts Taglib Developer Guides for more about using the nested syntax.)
ActionForms can be stored in either the request (preferable) or session (default) scope. If they're in the session scope it's important to implement the form's reset method to initialize the form before each use. ActionForms should be request based unless they are carried across more than one page, as is the case for our mortar ActionForm, SearchHelpParamsForm, used in all or our OAS apps which implement search help with action path /SearchHelpNavAction (see struts-config). But 99% of all other ActionForms should be request scope.
By definition, every ActionForm must be a subclass of org.apache.struts.action.ActionForm.
A form's job is data input. It should not be used for data output unless some of that data is used as input too (this does not mean dropdowns, etc). Output data should be stuffed into the request by using request.setAttribute in the Action. You can then access the data in the jsp using the c taglib. Any data that is required for more than one screen, e.g. dropdown data that doesn't change, etc, can be stored in the session (how do you store data in the session?).
