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, via its execute method, and return an ActionForward object that identifies where control should be forwarded (e.g. a JSP, Tile definition, Velocity template, or another Action) to provide the appropriate response. + The goal of an Action class is to process a request and return an ActionForward object that identifies where control should be transferred (e.g. a JSP page, Tile definition, Velocity template, or another Action) to provide the appropriate response. == Action As A Servlet == - In most Struts-based applications an Action class handles requests of one particular type. Because Action class is stateless, it can be considered a fancy servlet or a web service. Action class defines two methods that could be executed in "servlet mode". Choosing one or another depends on your servlet environment: + When used in "servlet mode", an Action class handles all incoming requests in one callback method, execute(). Two 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, - ActionForm form, + ActionForm form, - ServletRequest request, - ServletResponse response) - throws Exception; - - public ActionForward execute(ActionMapping mapping, - ActionForm form, - HttpServletRequest request, + HttpServletRequest request, - HttpServletResponse response) + 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 class is stateless, it looks very much like a a fancy servlet or a web service. But in some ways Action class is more limited than a regular servlet. - In the MVC/Model 2 design pattern, a typical Action class will often implement logic like the following in its execute method: + A servlet can handle GET and POST requests in different manner by providing two separate methods, doGet() and doPost(). HTTP specification recommends to use POST request for non-idempotent requests, namely to modify application state. GET reqeust should not affect model state and should be used for requests that can be safely repeated more than one time. + + Action class provides only one method to deal with all incoming requests, therefore actions rarely distinguish a ''render request'' from a ''submit request''. This often leads to convoluted and unmaintable code that can break from an occasional page refresh or from clicking on a Back button. + + Despite its shortcomins, the "servlet mode" is one of more popular uses of Action class.A typical Action class will often implement logic like the following in its execute method: * Validate the current state of the user's session (for example, checking that the user has successfully logged on). If the Action class finds that no logon exists, the request can be forwarded to the presentation page that displays the username and password prompts for logging on. This could occur because a user tried to enter an application "in the middle" (say, from a bookmark), or because the session has timed out, and the servlet container created a new one. * If validation is not complete, 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 back to the input form so that the errors can be corrected. @@ -37, +37 @@ == Action As A Behavior Object == - Behavior object handles a group of related messages (events, commands). These message are often correspond to one business object, like classic Create, Retrieve, Update and Delete messages that identify basic operations on persistent objects in a database-driven application. Behavior object usually changes application state based on incoming message. Application state can be stored in database, flat file or in a scoped object like HttpSession or HttpServletRequest. + Behavior object handles a group of related messages (events, commands). These messages often correspond to one business object, like classic Create, Retrieve, Update and Delete messages that identify basic operations on persistent objects in a database-driven application. Behavior object usually changes application state based on incoming message. Application state can be stored in database, flat file or in a scoped object like !HttpSession or !HttpServletRequest. - A behavior object implemented according to principles of Object-Oriented Programming should have methods that correspond to every kind of incoming message. Therefore an Action that manages a persistent object will likely have create(), retrieve(), update() and delete() methods. Each method will be triggered with a specific message sent in a request. + A behavior object has methods that correspond to incoming messages. Therefore an Action that manages a persistent object will likely have create(), retrieve(), update() and delete() methods. Each method is triggered with a specific parameter sent in a request. - Struts Extras package allows to define behavior objects using one of subclasses of Action class: DispatchAction, LookupDispatchAction, MappingDispatchAction, EventDispatchAction. These subclasses decode an event from incoming request and dispatch it to a corresponding event handler. The exact way of defining events and handlers for an Action depends on specific Action subclass. + Struts Extras package allows to define behavior objects with one of subclasses of Action class: DispatchAction, LookupDispatchAction, MappingDispatchAction, EventDispatchAction. These subclasses decode an event from incoming request and dispatch it to a corresponding event handler. The exact way of defining events depends on specific Action subclass. Starting from Struts 1.3.6 dispatching functionality is implemented into base Action class. Now there is a standard way of defining events for a behavioral Action by using <event> elements in an action mapping: @@ -55, +55 @@ <forward name = "render" path = "/loginRender.do" /> </action>}}} - Behavior Actions do not render a view themselves. Instead, they transfer control to a rendering Action. The task of handling input and rendering output is split into separate Actions. This case of ''action chaining'' can simplify code reuse. + Behavior Actions usually handle submit requests only. To display a view they transfer control to a rendering Action. Thus the task of handling input and output is split into separate Actions. == Action As A Code-Behind Class == - In Microsoft parlance, a code-behind class implements the program logic of one web resource. Since ASP.Net uses Page Controller paradigm, a web resource is usually a page. Struts web resources are not constrained by one page, one resource can have several corresponding views defined in one or in several JSP files. + In Microsoft parlance, a code-behind class implements the logic of one web resource. Since ASP.Net uses Page Controller paradigm, a web resource is usually a page. Struts web resources are not constrained by one page, one resource can have several corresponding views defined in one or in several JSP files. A code-behind Struts Action: * handles different commands and events corresponding to a web resource (submit phase), and * selects an appropriate view based on current state of web resource (render phase). inline:action_code_behind.gif - - It is possible to combine processing of both submit and render phases in one Action class, or to split this functionality into two Action classes. Instead of relying on one execute() method a code-behind class uses event handlers for different incoming events. {{{<action path = "/login" type = "samples.login.LoginAction"
