ActionForms are for user input. That's why they are called action "forms".
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 for the purposes of user friendly validations, the web client should be String-based so that the user's bad data can be displayed for correction. For instance, if an ActionForm designates that this field MUST be a date and then the user types in "foo" the data can't be bound to the ActionForm and the incorrect value that the user typed in can't be displayed back to them. Worst yet, we wouldn't be able to accept "01/10/08" as a valid date. Only MM/DD/YYYY would be acceptable in input fields designated as Date fields.
If the business object is to be used for display purposes only, it should be accessed via a request or session attribute and not via an ActionForm variable. See the section on Actions for a description of how a request attribute can be set. See the section on JSPs for a description of how to access the request attribute.
A good rule of thumb is that if you have a JSP page that has a form on it (html form), there should be an ActionForm behind it and the ActionForm should have a similar structure as the html form.
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. If a request scoped ActionForm is accessed by multiple pages it can be placed into the request as an attribute by the Action:
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.
