ActionForms should not contain business objects because it binds the presentation layer to the model in the business tier. If the model changes, the presentation layer will have to change. Also, the business object should represent the native data types, such as int or Date, and the web client is String-based and can only handle String or boolean data types without a conversion. Also, nesting a mutable business object does not work well if the business object rejects badly formatted data.
(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. This is configured in struts-config.xml. If they're in the session scope it's important to implement the form's reset method to initialize the form before each use (see mortar's reset method within ActionForm, SearchHelpParamsForm). ActionForms should be request scope 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). ActionForms associated with pages that have a search help icon need to be session scope. Otherwise, ActionForms should be request scope.
By definition, every ActionForm must be a subclass of org.apache.struts.action.ActionForm, which implements java.io.Serializable. In order to avoid an Eclipse warning, your ActionForm can declare a static final serialVersionUID field of type long (e.g., private static final long serialVersionUID = 1L) but this is not mandatory. Some developers dislike the fact that Eclipse warns us if we don't declare serialVersionUID. Others think it is best to always declare it.
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?).
