struts-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
Date Fri, 23 Jun 2006 16:50:16 GMT
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

------------------------------------------------------------------------------
- '''Attention: this page describes functionality that is not yet available in GA Struts release'''
+ '''Attention: this page describes functionality that is not yet available in GA Struts release!
Work in progress!'''
  
  == 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.
  
  == Action As A Servlet ==
- In most Struts-based applications an Action class handles requests of one particular type.
Considering that Action class is stateless, it can be thought of as a web service or just
a fancy servlet. Action class defines two methods that could be executed in "servlet mode".
Choosing one or another depends on your servlet environment:
+ 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:
  
  {{{public ActionForward execute(ActionMapping mapping,
                      ActionForm form,
@@ -35, +35 @@

  
  The perform method may still be used in Apache Struts 1.1 but is deprecated. The Apache
Struts 1.1 method simply calls the new execute method and wraps any Exception thrown as a
ServletException. The deprecated perform method was removed in Apache Struts 1.2.
  
+ == 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.
+ 
+ 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.
+ 
+ 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. 
+ 
+ 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:
+ 
+ {{{<action path = "/loginSubmit"
+         type = "samples.login.LoginAction"
+         name = "loginform"
+         scope = "session"
+         validate  = "false">
+    <event name="loginEvent" handler="login"/>
+    <event name="logoutEvent" handler="logout"/>
+    <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.
+ 
  == 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.
@@ -42, +64 @@

  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).
- 
- 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. Struts Extras
package defines several subclasses of Action class that implement event dispatching: DispatchAction,
LookupDispatchAction, MappingDispatchAction, EventDispatchAction. Events and corresponding
handlers are usually defined in an action mapping, but the exact way of doing that depended
on specific Action subclass that you used. 
- 
- Starting from Struts 1.3.6 dispatching functionality is pushed into base Action class, and
now there is a standard way of defining events for a code-behind Action by using <event>
elements in an action mapping:
  
  {{{<action path = "/login"
          type = "samples.login.LoginAction"
@@ -58, +76 @@

     <forward name = "loggedin" path = "/logout.jsp" />
  </action>}}}
  
+ 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 As A Web Component ==
  
  A web component differs from a web resource in that a component is visually a part of a
larger ''composite page''. As such a web component does not need to navigate to a next location.
Instead, a web component must either update itself on a composite page in place or reload
the whole page after the component updated its state. In-place updating is facilitated using
Javascript/XMLHttpRequest (Ajax mode), while full page reload is used if Javascript is turned
off on a browser.

Mime
View raw message