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 ------------------------------------------------------------------------------ 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 (illustrated below). 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 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. - - inline:basic_action.gif !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. + + The following picture illustrates the difference between Struts and ASP.NET using a simple "render page" use case. In ASP.NET the request means "Display a page", in Struts request means "Display a view that corresponds to current status of an Action". + + inline:basic_action_asp.gif '''Example''' @@ -27, +29 @@ * 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. The outcomes returned by an action are much more stable than the target locations. + 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. - == Action As Simple Service == + == 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: {{{public ActionForward execute(ActionMapping mapping, @@ -37, +40 @@ HttpServletRequest request, HttpServletResponse response) throws Exception;}}} - + + + == 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. + 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. - - An interactive web application implements the above HTTP requirements using a two-phase input/output protocol. On ''render phase'' (or output phase) the browser requests a view from the server. On ''input phase'' (or submit phase) the browser sends input data to an application, usually by submitting an HTML form. 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 is 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. + 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. inline:setup_submit.gif @@ -67, +73 @@ Setup action loads data from database and queues it into one or more arbitrary objects located in the request or session scope. Submit action processes input data and redisplays the same data entry form if errors has been found in the input. If input does not contain errors, submit action forwards to a success page. - This standard setup/submit pattern is not perfect: + This setup/submit pattern looks far more complex that simple ASP.NET request/response cycle: + + inline:asp_render_submit.gif + + Besides the complexity of implementation, Struts setup/submit pattern has other design and usability implications: * The focus is a page, not a web resource in general. * One Action deals with only one message, like {{{updateCustomer.do}}} deals with "Update Customer" event, {{{deleteCustomer.do}}} deals with "Delete Customer" event. * One logical web resource is defined with several action mappings in the {{{struts-config.xml}}} file as well as with several Java classes. @@ -78, +88 @@ * An attempt to refresh a page after it has been redisplayed causes double submit. * Success page often corresponds to a logically different resource, this leads to a spaghetti code both in Java code as well as in {{{struts-config.xml}}} file. + == Improving Setup/Submit Pattern == + + TODO == Action As Event Dispatcher ==
