[Struts Wiki] Trivial Update of "StrutsManualActionClasses" by MichaelJouravlev

[Apache Wiki <wi...@apache.org>]

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 either implement a stateless ''service'' like "Search", or to manage a stateful ''business object'' like "Customer".
  
- An Action class handles a request and returns an !ActionForward object, which represents a logical outcome of processing a request. An action mapping in {{{struts-config.xml}}} file associates !ActionForward object with either another Action (see [:ActionChaining:action chaining]), or with a presentation page, or with any arbitrary URL.  By not defining a specific target location in Java code, it is possible to separate logical outcome of an action from its visual representation.
+ An Action class handles a request and returns an !ActionForward object, which represents a logical outcome of processing a request. An action mapping in {{{struts-config.xml}}} file associates !ActionForward object with either another Action (see [:ActionChaining:action chaining]) or with a presentation page.  By not defining a specific target location in Java code, it is possible to separate logical outcome of an action from its visual representation.
  
  Struts is agnostic to presentation technology, so response can be generated using JSP file, Tile definition, Velocity template, XSLT stylesheet or other rendering engine.
  
@@ -24, +24 @@

  
  == Using Action To Display A Web Page ==
  
- JSP is default view technology used when developing with Struts. JSP file creates dynamic web content by reading information from various Java objects stored in page, request, session or application scope. In a Model 1 application these objects are stored in a scope by the code that resides in JSP page itself.
+ JSP is default presentation technology used when developing with Struts. JSP file creates dynamic web content by reading information from various Java objects stored in page, request, session or application scope. 
  
  A standard practice to display a dynamic page in a Struts application is to use Action class "in front" of a JSP page (see [http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html Model 2 web application architecture]). Action class creates needed beans, puts them in an appropriate context, and forwards control to a JSP page that reads information from these beans and displays it. Action class has access to all standard J2EE contexts except JSP-specific page context.
  
- As a concequence of Model 2 architecture, JSP pages are not directly navigated with browser when programming with Struts. Applications developed with Struts or with other similar web frameworks like !WebWork or Stripes are often called ''action-based''. This is different from so called ''page-based'' frameworks like ASP.NET, where web page is accessed directly from browser. In ASP.NET a web page usually delegates events processing and page lifecycle-related tasks to a code-behind class.
+ As a concequence of Model 2 architecture, JSP pages are not directly accessible from browser when programming with Struts. Applications developed with Struts or with other similar web frameworks like !WebWork or Stripes are often called ''action-based''. This is different from so called ''page-based'' frameworks like ASP.NET, where web page is accessed directly from browser. In ASP.NET a web page usually delegates events processing and page lifecycle-related tasks to a ''code-behind'' class. In Microsoft parlance, Struts Action class can be called ''code-in-front''.
  
  The following picture illustrates a "render page" use case implemented with Struts and ASP.NET.
  
@@ -38, +38 @@

  
  The most common use case in an interactive web application is submitting of HTML form. A user expects that if input data is not valid then the form is redisplayed keeping information entered by the user, and displaying relevant error messages. 
  
- This input/output process is traditionally implemented in Struts with setup/submit pattern:
+ The input/output process is traditionally implemented in Struts with setup/submit pattern:
   * ''setup action'' (''pre-action'', ''output action'', ''render action'') prepares output data for display. It loads data from database, queues it into one or more arbitrary objects located in the request or session scope, then forwards to a view, usually a JSP page.
   * ''submit action'' (''post-action'', ''input action'', ''accept action'', ''event action'') processes input data from web form and redisplays the web form if errors has been found. If input does not contain errors, submit action updates application state and forwards to a success page. 
  
@@ -57, +57 @@

   * Update the server-side objects that will be used to create the next page of the user interface. These objects would typically be request scope or session scope beans, depending on how long you need to keep these items. 
   * Return an appropriate !ActionForward object that identifies the next web resource.
  
+ To ensure that the above pattern works correctly, a setup action should disable automatic form reset and population for forwarded requests (new feature of Struts 1.4).
+ 
  See tips on using setup/submit pattern and code sample (TODO link)
  
  The flip side of Struts flexibility is greater complexity of a most common use case of a web application.
@@ -65, +67 @@

  
  Event dispatcher handles a group of related ''messages'' (''events'', ''commands''). The difference between events and commands is subtle. Basically, event can be sent just "out there" and whoever is interested in that event handles it. Command is usually sent to a specific object that has to process the command. Messages often correspond to one business object, for example messages like Create, Retrieve, Update and Delete identify basic operations on persistent objects in a database-driven application. 
  
- An event dispatcher defines methods that correspond to incoming messages. Therefore an Action that manages a persistent object will have methods {{{create}}}, {{{retrieve}}}, {{{update}}} and {{{delete}}}. Each method is triggered with a specific parameter sent in a request. Grouping related message handlers in one Action class reduces number of classes and often reduces number of mappings in {{{struts-config.xml}}} file. 
+ An event dispatcher defines methods that correspond to incoming messages; an Action that manages a persistent object will have methods {{{create}}}, {{{retrieve}}}, {{{update}}} and {{{delete}}}. Each method is triggered with a specific parameter sent in a request. Grouping related message handlers in one Action class reduces number of classes and often reduces number of mappings in {{{struts-config.xml}}} file. 
  
  Struts defines several subclasses of Action class that perform event-dispatching, like !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 subclass. 
- 
- Event dispatchers usually handle one input/output phase. Event dispatchers can be used in setup/submit pattern, substituting several submit actions with just one.
  
  Note: to ensure that event handlers are always called, automatic validation should be turned off in {{{struts-config.xml}}} file.
  
@@ -81, +81 @@

  
  It is possible to represent one logical entity with one event-dispatching Action. You can differentiate input and render phases either by request type (GET vs. POST) or by presence or absence of an event parameter in the request.
  
- Using one Action class to handle both input/render phases of a web resource brings the complexity of Struts web form management down to the level of ASP.NET while retaining the flexibility.
+ Using one Action class to handle both input/render phases of a web resource brings the complexity of Struts web form management down to the level of ASP.NET while retaining the flexibility of a Model 2 framework.
  
  inline:web_resource_asp_simple.gif