Page History

Forms should be request based unless they are carried across more than one page, e.g. as in a wizard. Most of the time, you should be able to stuff biz objects directly into a form (and not flatten them out; i.e. create fields in the form for each field in the biz object). Struts should be able to deal with populating and returning nested objects.

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

There are two kinds of controller classes, Actions, found in the action directory, and ActionForms found in the data directory.

Struts Actions provide a glue between the View and Model layers and are responsible for processing specific requests.  Struts Actions should always extend org.apache.struts.action.Action�.
Struts ActionForms should always extend org.apache.struts.action.ActionForm�.

org.apache.struts.action is the core of the struts framework, providing the "Controller" aspect of a MVC model. See the section on MVCFor apps that use SAP, all your actions should be subclasses of SAPBaseAction. This provides automatic RFC error message handling (i.e. it takes all rfc messages and stores them into the struts actionmessages automatically). It will stop any time an rfc returns an error message. In the rare case you need to do something else (like continue other processing) when an rfc error message occurs, you can wrap a try catch on MessageRuntimeException around your service execute calls.

TBD - talk about how to go to different actions from the jsp using the hidden thingy