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] Trivial Update of "StrutsManualActionClasses" by MichaelJouravlev
Date Tue, 27 Feb 2007 22:09:02 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

------------------------------------------------------------------------------
  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
  

Mime
View raw message