Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StrutsManualActionClasses ------------------------------------------------------------------------------ == Action Classes == + The goal of an Action class is to process a request and return an ActionForward object. Action class can either implement a ''stateless service'', or can manage a logical ''web resource''. !ActionForward object identifies where control should be transferred to provide the appropriate response, and usually designate either another Action (see [:ActionChaining:action chaining]) or a presentation page. Struts is agnostic to presentation technology, so response can be generated using JSP file, Tile definition, Velocity template, XSLT stylesheet or other source. - The goal of an Action class is to process a request and return an ActionForward object. !ActionForward object identifies where control should be transferred to provide the appropriate response. - - !ActionForward object usually designate another Action (see [:ActionChaining:action chaining]) or a presentation page. Struts is agnostic to presentation technology, so response can be generated from JSP file, Tile definition, Velocity template, XSLT stylesheet or other source. !ActionForward object represents a logical outcome of processing a request. By not defining a specific menu choice or a page URL it is possible to separate state of a resource from its visual representation. @@ -18, +16 @@ Consider the Action that performs a search. The author of this code should not care about how the search results are presented, his only job is to say "what happened" when the search took place. - Logically, there are three interesting outcomes we might want to describe: + Logically, there are three interesting outcomes: - * No results at all were found => outcome "none". + * No results were found => outcome "none". * Exactly one result was found => outcome "single". * More than one result was found => outcome "multiple". @@ -29, +27 @@ * If there's exactly one response, go to the details page to display the corresponding data. * If there's more than one response, go to the list page (as per the previous behavior). - Note that the code of the search action is not affected by this decision. In Struts the outcomes returned by an action are much more stable than the target locations. On contrary, in ASP.NET the outcome is the page that was requested. + Note that the code of the search action is not affected by this decision. In Struts the outcomes returned by an action are much more stable than the presentation locations. On contrary, in ASP.NET the outcome is simply the page that was requested. == Action As Service == - In its simplest form Action class handles all incoming requests with one callback method, {{{execute()}}}. Two overloaded versions of this method are available. Choosing one or another depends on your servlet environment. A non-HTTP execute() method has been provided for applications that are not specifically geared towards the HTTP protocol, but most projects will only use the HTTP version since the majority of teams using the framework are focused on building web applications: + In its simplest form Action class handles all incoming requests with one callback method, {{{execute()}}}. Two overloaded versions of this method are available. Choosing one or another depends on your servlet environment: {{{public ActionForward execute(ActionMapping mapping, + ActionForm form, + ServletRequest request, + ServletResponse response) + throws Exception; + + public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception;}}} + Since the majority of teams using the framework are focused on building web applications, most projects will only use the "!HttpServletRequest" version. A non-HTTP execute() method has been provided for applications that are not specifically geared towards the HTTP protocol. == Action And Setup/Submit Pattern == - A request/response sequence of an interactive web application has two phases. On render phase (or output phase) browser requests a web resource to render itself. On input phase (or submit phase) browser sends input data to a web resource, usually by submitting an HTML form. These two phases are closely related to GET and POST methods of HTTP request. + A request/response sequence of an interactive web application is typically composed out of two phases. - HTTP specification recommends to use POST for non-idempotent requests, and to use GET for requests that can be repeated several times with the same outcome. In simpler terms, POST requests should be generally used to modify application state, while GET requests should be used to render a view. + * On ''render phase'' (''output phase'', ''render response phase'') the browser requests a web resource to render itself. + * On ''input phase'' (''submit phase'', ''event phase'', ''apply request values phase'') the browser sends input data to a web resource, usually by submitting an HTML form. + These two phases correspond closely to GET and POST methods of HTTP request. HTTP specification recommends to use POST for non-idempotent requests, and to use GET for requests that can be repeated several times with the same outcome. In simpler terms, POST requests should be generally used to modify application state, while GET requests should be used to render a view. - In Struts the two-phase request/response approach is traditionally implemented with setup/submit pattern and two kinds of actions: - * setup action (pre-action, output action, render action) prepares output data before displaying a JSP page; - * submit action (post-action, input action, accept action) accepts user input. - This pattern became a de-facto standard because unlike servlet, that processes GET and POST requests with {{{doGet()}}} and {{{doPost()}}} methods respectively, Action class handles all incoming requests with only one {{{execute()}}} method. + In Struts a logical web resource is represented with Action or Action/!ActionForm combination, and two-phase request/response approach is traditionally implemented with setup/submit pattern: + * ''setup action'' (''pre-action'', ''output action'', ''render action'') prepares output data before displaying; + * ''submit action'' (''post-action'', ''input action'', ''accept action'', ''event action'') accepts and handles user input. + + This pattern became a de-facto standard with Struts. Action class having only one {{{execute()}}} method instead of Servlet's {{{doGet()}}} and {{{doPost()}}} was another factor that accelerated adoption of this pattern. inline:setup_submit.gif - A typical Setup Action will often implement logic like the following in its {{{execute}}} method: + A typical Setup Action will often implement the following logic in its {{{execute}}} method: * Make sure that a user is allowed to see the content of a web page that corresponds to the action. - * Load needed data from database, set up an form bean or arbitrary request- or session-scoped objects. + * Load needed data from database, set up a form bean or arbitrary request- or session-scoped objects. - * Return an appropriate ActionForward object that identifies the presentation page to be used to generate the response. + * Return an appropriate !ActionForward object that identifies an appropriate presentation page. - A typical Submit Action will often implement logic like the following in its {{{execute}}} method: + A typical Submit Action will often implement the following logic in its {{{execute}}} method: - * Validate the form bean properties as needed. If a problem is found, store the appropriate error message keys as a request attribute, and forward control to the input form so that the errors can be corrected. + * Validate the form bean properties as needed. If a problem is found, store the appropriate error message keys as a request (or session) attribute, and forward (or redirect) control to the input form so that the errors can be corrected. * Perform the processing required to deal with this request (such as saving a row into a database). This can be done by logic code embedded within the Action class itself, but should generally be performed by calling an appropriate method of a business logic bean. * Update the server-side objects that will be used to create the next page of the user interface (typically request scope or session scope beans, depending on how long you need to keep these items - * Return an appropriate ActionForward object that identifies the presentation page to be used to generate this response, based on the newly updated beans. Typically, you will acquire a reference to such an object by calling findForward on either the ActionMapping object you received (if you are using a logical name local to this mapping), or on the controller servlet itself (if you are using a logical name global to the application). + * Return an appropriate !ActionForward object that identifies the presentation page to be used to generate this response, based on the newly updated beans. Typically, you will acquire a reference to such an object by calling findForward on either the ActionMapping object you received (if you are using a logical name local to this mapping), or on the controller servlet itself (if you are using a logical name global to the application). It is common to have several actions of either kind for one logical business object. For example, if you deal with {{{Customer}}} object, you are likely to define two setup actions: {{{viewCustomer.do}}} and {{{editCustomer.do}}} and three submit actions: {{{addCustomer.do}}}, {{{updateCustomer.do}}} and {{{deleteCustomer.do}}}.
