svn commit: r416591 - /struts/action2/trunk/archetype/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/decorators/css/
Author: tmjee Date: Fri Jun 23 00:24:52 2006 New Revision: 416591 URL: http://svn.apache.org/viewvc?rev=416591&view=rev Log: WW-1359 - remove this as it is a duplicate of /WEB-INF/styles Removed: struts/action2/trunk/archetype/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/decorators/css/
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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
New page:
'''Attention: this page describes functionality that is not yet available in GA
Struts release'''
== 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:
{{{public ActionForward execute(ActionMapping mapping,
ActionForm form,
ServletRequest request,
ServletResponse response)
throws Exception;
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
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.
In the MVC/Model 2 design pattern, 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.
* Perform the processing required to deal with this request (such as saving
a row into a database). This can be done by logic code embedded within the
Action class itself, but should generally be performed by calling an
appropriate method of a business logic bean.
* Update the server-side objects that will be used to create the next page
of the user interface (typically request scope or session scope beans,
depending on how long you need to keep these items available).
* Return an appropriate ActionForward object that identifies the
presentation page to be used to generate this response, based on the newly
updated beans. Typically, you will acquire a reference to such an object by
calling findForward on either the ActionMapping object you received (if you are
using a logical name local to this mapping), or on the controller servlet
itself (if you are using a logical name global to the application).
In Apache Struts 1.0, Actions called a perform method instead of the
now-preferred execute method. These methods use the same parameters and differ
only in which exceptions they throw. The elder perform method throws
SerlvetException and IOException. The new execute method simply throws
Exception. The change was to facilitate the Declarative Exception handling
feature introduced in Apache Struts 1.1.
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 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.
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 even
[Struts Wiki] Update of "StrutsActionRelease135" by WendySmoak
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 WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease135 The comment on the change is: Restored the 1.3.5 assembly snapshots & fixed link. -- To help everyone get started with Struts Action 1.3.5 (when it is available), here are the simplest installation instructions that can possibly work: - * Download the Struts 1.3.5 distribution from http://svn.apache.org/dist/struts/action/v1.3.5/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) + * Download the Struts 1.3.5 distribution from http://svn.apache.org/dist/struts/action/v1.3.5/ (when it is available.) (Until then, try a [http://people.apache.org/builds/struts/action1/1.3.x/assembly/ snapshot].) * Extract the distribution to a likely location (/opt/struts-action-1.3.5) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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 elements in an action mapping:
+
+ {{{
+
+
+
+ }}}
+
+ 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 st
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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
--
* 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.
+
{{{
}}}
- 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.
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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 -- 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. + inline:action_component.gif + Struts 1.3.6 allows to create web components in Struts using Struts Action class for event processing, JSP for presentation and an optional Javascript helper for in-place update in Ajax mode. See StrutsComponents section.
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- + ## page was renamed from StrutsComponents #format wiki #language en
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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
--
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 elements in an action mapping:
+ Starting from Struts 1.4 dispatching functionality is implemented into base
Action class. Now there is a standard way of defining events for a behavioral
Action by using elements in an action mapping:
{{{
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- Consider the following use case: a website has a home page that should have different content for regular visitors one one hand, and for logged in users for another hand. The page contains login/logout form, a user must be presented with login form if he is not logged in yet. Those users who logged in must be able to see information about themselves and must be able to log out. While implementing this use case the login/logout widget must reload the whole page if login attempt fails. Also, login/logout widget must have explicit knowledge about the target location, in our case it has to know the address of the home page. Therefore, it is nearly impossible to develop an independent login/logout widget that can be inserted into different pages and just work. Well, it is possible now. - - inline:login-component.gif == Component Configuration ==
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- == Use Case: Home Page With Login Component == Consider the following use case: a website has a home page that should have different content for regular visitors one one hand, and for logged in users for another hand. The page contains login/logout form, a user must be presented with login form if he is not logged in yet. Those users who logged in must be able to see information about themselves and must be able to log out. + + inline:login-component.gif While implementing this use case the login/logout widget must reload the whole page if login attempt fails. Also, login/logout widget must have explicit knowledge about the target location, in our case it has to know the address of the home page. Therefore, it is nearly impossible to develop an independent login/logout widget that can be inserted into different pages and just work. Well, it is possible now.
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- #format wiki #language en - Struts 1.3.x (TBD) allows building portlet-like web components using JSP as view technology. The components work properly with or without Javascript enabled. + Struts 1.4 allows building portlet-like web components using JSP as view technology. The components work properly with or without Javascript enabled. Struts Components have the following features: @@ -15, +15 @@ * Ensures that every component renders itself independently. * Updates page incrementally without full page refresh if browser has Javascript turned on and XMLHTTPRequest is available. * Seamlessly integrates with Struts, enhancing a well-known action framework with component technology. + + == Struts Component Lifecycle == + + ''Struts web component'' is an independent stateful server-side object that accepts user input via Action class, and renders itself via JSP file. + + The component lifecycle is managed in a five-step process: + +1. The cycle begins with the initial load of a composite page, starting the render phase. +2. When the JSP processor encounters a action in a composite page, it generates an HTTP request to obtain the content of the included component. +3. The Action class forwards to a view relevant to component state. After all components on the composite page have rendered themselves, the render phase finishes and a composite page is presented to a user. +4. The user initiates the input phase by submitting an HTML form or by activating a command link. The browser sends input data to an Action that manages component events and state. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. +5. After input data has been processed, the Action automatically redirects to location of the composite page, effectively switching from input phase back to render phase. Steps 1 through 3 are repeated, and an updated page is presented to the user. + + If the browser has JavaScript turned on and the XMLHTTPRequest object is available, the component switches to Ajax mode by making an asynchronous request to update the component without full page refresh, so steps 5, 1, and 2 are skipped, and step 4 jumps right to step 3. The incremental update is more effective in regards to network traffic and avoids the complexities of identifying the reload address. + + A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers. == Use Case: Home Page With Login Component ==
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- 4. The user initiates the input phase by submitting an HTML form or by activating a command link. The browser sends input data to an Action that manages component events and state. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. 5. After input data has been processed, the Action automatically redirects to location of the composite page, effectively switching from input phase back to render phase. Steps 1 through 3 are repeated, and an updated page is presented to the user. + inline:action_component.gif + - If the browser has JavaScript turned on and the XMLHTTPRequest object is available, the component switches to Ajax mode by making an asynchronous request to update the component without full page refresh, so steps 5, 1, and 2 are skipped, and step 4 jumps right to step 3. The incremental update is more effective in regards to network traffic and avoids the complexities of identifying the reload address. + If the browser has !JavaScript turned on and the XMLHTTPRequest object is available, the component switches to Ajax mode by making an asynchronous request to update the component without full page refresh, so steps 5, 1, and 2 are skipped, and step 4 jumps right to step 3. The incremental update is more effective in regards to network traffic and avoids the complexities of identifying the reload address. - A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers. + A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where !JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers. == Use Case: Home Page With Login Component ==
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- #format wiki #language en - Struts 1.4 allows building portlet-like web components using JSP as view technology. The components work properly with or without Javascript enabled. + Struts 1.4 allows building portlet-like web components using JSP as view technology. ''Struts web component'' is an independent server-side object that accepts user input via Action class, and renders itself via JSP file. In a sense, Struts web component is a simple portlet. - Struts Components have the following features: + Struts approach to web components has the following features: * Allows composing a page out of one or more independent components. * Renders a view that is always synchronized with application state. @@ -16, +16 @@ * Updates page incrementally without full page refresh if browser has Javascript turned on and XMLHTTPRequest is available. * Seamlessly integrates with Struts, enhancing a well-known action framework with component technology. - == Struts Component Lifecycle == + == Struts Component Lifecycle In Synchronous Mode == - ''Struts web component'' is an independent stateful server-side object that accepts user input via Action class, and renders itself via JSP file. - - The component lifecycle is managed in a five-step process: + In synchronous mode the component lifecycle is managed in a five-step process: 1. The cycle begins with the initial load of a composite page, starting the render phase. 2. When the JSP processor encounters a action in a composite page, it generates an HTTP request to obtain the content of the included component. @@ -28, +26 @@ 4. The user initiates the input phase by submitting an HTML form or by activating a command link. The browser sends input data to an Action that manages component events and state. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. 5. After input data has been processed, the Action automatically redirects to location of the composite page, effectively switching from input phase back to render phase. Steps 1 through 3 are repeated, and an updated page is presented to the user. - inline:action_component.gif + inline:action_component_title.gif - If the browser has !JavaScript turned on and the XMLHTTPRequest object is available, the component switches to Ajax mode by making an asynchronous request to update the component without full page refresh, so steps 5, 1, and 2 are skipped, and step 4 jumps right to step 3. The incremental update is more effective in regards to network traffic and avoids the complexities of identifying the reload address. + == Struts Component Lifecycle In Asynchronous Mode == + If the browser has !JavaScript turned on and the XMLHTTPRequest object is available, a web component is updated asynchronously; steps 1, 2 and 3 do not differ from synchronous mode: + +1. The cycle begins with the initial load of a composite page, starting the render phase. +2. When the JSP processor encounters a action in a composite page, it generates an HTTP request to obtain the content of the included component. +3. The Action class forwards to a view relevant to component state. After all components on the composite page have rendered themselves, the render phase finishes and a composite page is presented to a user. +4. The user initiates the input phase by submitting an HTML form or by activating a command link. '''Javascript engine sends input data to the Action asynchronously using XMLHTTPRequest object.''' The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. +5. '''After input data has been processed, the Action forwards to a view relevant to component state. This view is returned to the browser in response to asynchronous request. The Javascript engine finds the spot in the composite page where the component resides, and updates page fragment in place.''' The user sees an updated page. + + inline:action_component_ajax_title.gif + - A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where !JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers. + A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent
--
#format wiki
#language en
- Struts 1.4 allows building portlet-like web components using JSP as view
technology. ''Struts web component'' is an independent server-side object that
accepts user input via Action class, and renders itself via JSP file. In a
sense, Struts web component is a simple portlet.
+ Struts 1.4 allows building portlet-like web components using JSP as view
technology. ''Struts web component'' is an independent server-side object that
accepts user input via Action class, and renders itself via JSP file. In a
sense, Struts web component is a portlet.
+
+ A Struts Web Component is a combination of:
+ * one Action class that handles input events and updates component state;
+ * an optional form bean that holds input/output data;
+ * one or more views that can be represented with one or more JSP files.
Struts approach to web components has the following features:
@@ -48, +53 @@
Consider the following use case: a website has a home page that should have
different content for regular visitors one one hand, and for logged in users
for another hand. The page contains login/logout form. A non-logged-in user
must be presented with login, while a logged-in user should be able to log out.
+ The picture below illustrates this use case. Of course, since it is just an
example, the login component is almost as large as the composite page itself,
but the idea is the same: to design a component that does not have to know the
location of a composite page it is included into.
+
+ inline:login-component-sm.gif
+
+ = Building A Synchronous Component with Struts 1.4 =
+
+ The first exercise is building a synchronous, non-Ajax component. It is
simpler than Ajax component because we do not need to fiddle with Javascript.
On the other hand, it is more complex because instead of simply replacing one
piece of page with another we need to figure out the location of original
composite page and then to redirect to that location in order to reload the
whole page.
+
== Component Configuration ==
- The Struts Web Component is represented with one Action class and with one
(or more) JSP pages. Let us define the Login Component in struts-config.xml
file:
+ First let us define the Login Component in {{{struts-config.xml}}} file:
{{{
@@ -69, +82 @@
}}}
- Notice new action mapping attributes and properties:
+ Notice action mapping attributes and properties that are new for Struts 1.4:
* "component" attribute identifies an action as a component manager, such
actions are processed differently by Action class. This name is also used in
generated HTML for in-place update in Ajax mode.
* "view" attribute identifies a default view for a component. Must be a
JSP page. Often consists from several subviews, in our case the Login Component
has two subviews "Not Logged In" and "Logged In", they will be defined in JSP
file.
* "form" is just another name for "name" property
-* "event" property allows to define request parameters as events, and
corresponding method handlers. That is right, dispatching functions are now
supported in the core Struts, by Action class.
+* "event" property allows to define request parameters as events, and
corresponding method handlers. This is made possible by supporting dispatching
functionality directly in Action class.
== Component Action ==
@@ -261, +274 @@
This is pretty much it. Now run the application and navigate to composite
page. The included component will evaluate user's state and will display a
login form. Try to log in. The submitted credentials are sent directly to a
component, if they are not correct, the composite page is redisplayed. How?
Behind the scenes the improved Action class as well as JSP tags work together
to distinguish the address of a composite page during first render. This
address is saved automatically. Then after component finishes, it reloads the
composite page using saved address. Now you can develop independent Struts
components!
+
+ = Building An Asynchronous Component with Struts 1.4 =
+
Next installment: making components that update themselves in place without
full page reload (Ajax mode).
== Download ==
svn commit: r416854 - /struts/maven/trunk/pom/pom.xml
Author: mikus Date: Fri Jun 23 19:50:09 2006 New Revision: 416854 URL: http://svn.apache.org/viewvc?rev=416854&view=rev Log: MichaelJ: added myself to the list Modified: struts/maven/trunk/pom/pom.xml Modified: struts/maven/trunk/pom/pom.xml URL: http://svn.apache.org/viewvc/struts/maven/trunk/pom/pom.xml?rev=416854&r1=416853&r2=416854&view=diff == --- struts/maven/trunk/pom/pom.xml (original) +++ struts/maven/trunk/pom/pom.xml Fri Jun 23 19:50:09 2006 @@ -302,6 +302,14 @@ Committer + + Michael Jouravlev + mikus + mikus at apache.org + +Committer + +
[Struts Wiki] Update of "StrutsManualActionClasses" by MichaelJouravlev
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 -- 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. - inline:action_component.gif + inline:action_component_generic.gif Struts 1.4 allows to create web components using Struts Action class for event processing, JSP for presentation and an optional Javascript helper for in-place update in Ajax mode.
[Struts Wiki] Update of "StrutsManualActionWebComponentSync" by MichaelJouravlev
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/StrutsManualActionWebComponentSync
New page:
== Struts Component Lifecycle In Synchronous Mode ==
In synchronous mode the component lifecycle is managed in a five-step process:
1. The cycle begins with the initial load of a composite page, starting the
render phase.
2. When the JSP processor encounters a action in a composite
page, it generates an HTTP request to obtain the content of the included
component.
3. The Action class forwards to a view relevant to component state. After
all components on the composite page have rendered themselves, the render phase
finishes and a composite page is presented to a user.
4. The user initiates the input phase by submitting an HTML form or by
activating a command link. The browser sends input data to an Action that
manages component events and state. The Action processes data and updates
component state if needed. Component state can be stored in a session-scoped
form bean, in a database or in other location.
5. After input data has been processed, the Action automatically redirects
to location of the composite page, effectively switching from input phase back
to render phase. Steps 1 through 3 are repeated, and an updated page is
presented to the user.
nline:action_component_title.gif
== Component Configuration ==
First let us define the Login Component in {{{struts-config.xml}}} file:
{{{
}}}
Notice action mapping attributes and properties that are new for Struts 1.4:
* "component" attribute identifies an action as a component manager, such
actions are processed differently by Action class. This name is also used in
generated HTML for in-place update in Ajax mode.
* "view" attribute identifies a default view for a component. Must be a JSP
page. Often consists from several subviews, in our case the Login Component has
two subviews "Not Logged In" and "Logged In", they will be defined in JSP file.
* "form" is just another name for "name" property
* "event" property allows to define request parameters as events, and
corresponding method handlers. This is made possible by supporting dispatching
functionality directly in Action class.
== Component Action ==
The action class is deceptively simple. It handles only two events, the
corresponding handlers are called automatically by Action class. The location
of component's view is defined in the action mapping, so render method is not
needed. On the other hand, most non-trivial components need to process data
before rendering themselves or to exchange data with other components. For
these cases you can use render" method. Its default implementation does nothing.
{{{
public class LoginAction extends Action {
public ActionForward login (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
HttpSession session = request.getSession();
LoginForm inputForm = (LoginForm) form;
// Log out current user first
request.getSession().removeAttribute("USER");
// Validation is turned off in struts-config.xml,
// so explicitly validate user input;
ActionMessages errors = inputForm.validate(mapping, request);
if (errors != null) {
saveErrors(session, errors);
} else {
// Use this session attribute to hold user's name
session.setAttribute("USER", inputForm.getUsername());
}
// Always return null.
return null;
}
public ActionForward logout (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception
{
LoginForm inputForm = (LoginForm) form;
// Clean name and password in the input/output form bean
inputForm.setUsername(null);
inputForm.setPassword(null);
// Remove dialog name from session, effectively logging out
request.getSession().removeAttribute("USER");
// Always return null.
return null;
}
}
}}}
== Component Form Bean ==
Nothing exciting here, just a session-scoped form to hold user name and to
validate credentials:
{{{
public class LoginForm extends ActionForm {
private String username;
public String getUsername() {return username;}
public void setUsername(String username) {this.username = username;}
private String password;
public String getPassword() {return password;}
public void setPassword(String password) {this.password = password;}
[Struts Wiki] Update of "StrutsManualActionWebComponentSync" by MichaelJouravlev
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/StrutsManualActionWebComponentSync -- 4. The user initiates the input phase by submitting an HTML form or by activating a command link. The browser sends input data to an Action that manages component events and state. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. 5. After input data has been processed, the Action automatically redirects to location of the composite page, effectively switching from input phase back to render phase. Steps 1 through 3 are repeated, and an updated page is presented to the user. - nline:action_component_title.gif + inline:action_component_title.gif == Component Configuration ==
[Struts Wiki] Update of "StrutsManualActionWebComponentAsync" by MichaelJouravlev
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/StrutsManualActionWebComponentAsync
New page:
== Struts Component Lifecycle In Asynchronous Mode ==
If the browser has !JavaScript turned on and the XMLHTTPRequest object is
available, a web component is updated asynchronously; steps 1, 2 and 3 do not
differ from synchronous mode:
1. The cycle begins with the initial load of a composite page, starting the
render phase.
2. When the JSP processor encounters a action in a composite
page, it generates an HTTP request to obtain the content of the included
component.
3. The Action class forwards to a view relevant to component state. After
all components on the composite page have rendered themselves, the render phase
finishes and a composite page is presented to a user.
4. The user initiates the input phase by submitting an HTML form or by
activating a command link. Javascript engine sends input data to the Action
asynchronously using XMLHTTPRequest object. The Action processes data and
updates component state if needed. Component state can be stored in a
session-scoped form bean, in a database or in other location.
5. After input data has been processed, the Action forwards to a view
relevant to component state. This view is returned to the browser in response
to asynchronous request. The Javascript engine finds the spot in the composite
page where the component resides, and updates page fragment in place. The user
sees an updated page.
nline:action_component_ajax_title.gif
A Struts component incorporated into a page looks and behaves uniformly whether
it runs in Ajax mode or not. The dual-mode functionality of Struts web
components is invaluable for environments where !JavaScript is not allowed or
in browsers that do not support the XMLHTTPRequest object, like some mobile
browsers.
It is worth noting that both Ajax and non-Ajax modes utilize the same code and
markup.
== Component Configuration ==
First let us define the Login Component in {{{struts-config.xml}}} file:
{{{
}}}
Notice action mapping attributes and properties that are new for Struts 1.4:
* "component" attribute identifies an action as a component manager, such
actions are processed differently by Action class. This name is also used in
generated HTML for in-place update in Ajax mode.
* "view" attribute identifies a default view for a component. Must be a JSP
page. Often consists from several subviews, in our case the Login Component has
two subviews "Not Logged In" and "Logged In", they will be defined in JSP file.
* "form" is just another name for "name" property
* "event" property allows to define request parameters as events, and
corresponding method handlers. This is made possible by supporting dispatching
functionality directly in Action class.
== Component Action ==
The action class is deceptively simple. It handles only two events, the
corresponding handlers are called automatically by Action class. The location
of component's view is defined in the action mapping, so render method is not
needed. On the other hand, most non-trivial components need to process data
before rendering themselves or to exchange data with other components. For
these cases you can use render" method. Its default implementation does nothing.
{{{
public class LoginAction extends Action {
public ActionForward login (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
HttpSession session = request.getSession();
LoginForm inputForm = (LoginForm) form;
// Log out current user first
request.getSession().removeAttribute("USER");
// Validation is turned off in struts-config.xml,
// so explicitly validate user input;
ActionMessages errors = inputForm.validate(mapping, request);
if (errors != null) {
saveErrors(session, errors);
} else {
// Use this session attribute to hold user's name
session.setAttribute("USER", inputForm.getUsername());
}
// Always return null.
return null;
}
public ActionForward logout (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception
{
LoginForm inputForm = (LoginForm) form;
// Clean name and password in the input/output form bean
inputForm.setUsername(null);
inputForm.setPassword(null);
// Remove dialog name from session, effectively lo
[Struts Wiki] Update of "StrutsManualActionWebComponentAsync" by MichaelJouravlev
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/StrutsManualActionWebComponentAsync -- 4. The user initiates the input phase by submitting an HTML form or by activating a command link. Javascript engine sends input data to the Action asynchronously using XMLHTTPRequest object. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. 5. After input data has been processed, the Action forwards to a view relevant to component state. This view is returned to the browser in response to asynchronous request. The Javascript engine finds the spot in the composite page where the component resides, and updates page fragment in place. The user sees an updated page. - nline:action_component_ajax_title.gif + inline:action_component_ajax_title.gif A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where !JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers.
[Struts Wiki] Update of "StrutsManualActionWebComponent" by MichaelJouravlev
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/StrutsManualActionWebComponent -- ## page was renamed from StrutsComponents #format wiki #language en + + '''Attention: this page describes functionality that is not yet available! Work in progress!''' Struts 1.4 allows building portlet-like web components using JSP as view technology. ''Struts web component'' is an independent server-side object that accepts user input via Action class, and renders itself via JSP file. In a sense, Struts web component is a portlet. @@ -21, +23 @@ * Updates page incrementally without full page refresh if browser has Javascript turned on and XMLHTTPRequest is available. * Seamlessly integrates with Struts, enhancing a well-known action framework with component technology. - == Struts Component Lifecycle In Synchronous Mode == - - In synchronous mode the component lifecycle is managed in a five-step process: - -1. The cycle begins with the initial load of a composite page, starting the render phase. -2. When the JSP processor encounters a action in a composite page, it generates an HTTP request to obtain the content of the included component. -3. The Action class forwards to a view relevant to component state. After all components on the composite page have rendered themselves, the render phase finishes and a composite page is presented to a user. -4. The user initiates the input phase by submitting an HTML form or by activating a command link. The browser sends input data to an Action that manages component events and state. The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. -5. After input data has been processed, the Action automatically redirects to location of the composite page, effectively switching from input phase back to render phase. Steps 1 through 3 are repeated, and an updated page is presented to the user. - - inline:action_component_title.gif - - == Struts Component Lifecycle In Asynchronous Mode == - - If the browser has !JavaScript turned on and the XMLHTTPRequest object is available, a web component is updated asynchronously; steps 1, 2 and 3 do not differ from synchronous mode: - -1. The cycle begins with the initial load of a composite page, starting the render phase. -2. When the JSP processor encounters a action in a composite page, it generates an HTTP request to obtain the content of the included component. -3. The Action class forwards to a view relevant to component state. After all components on the composite page have rendered themselves, the render phase finishes and a composite page is presented to a user. -4. The user initiates the input phase by submitting an HTML form or by activating a command link. '''Javascript engine sends input data to the Action asynchronously using XMLHTTPRequest object.''' The Action processes data and updates component state if needed. Component state can be stored in a session-scoped form bean, in a database or in other location. -5. '''After input data has been processed, the Action forwards to a view relevant to component state. This view is returned to the browser in response to asynchronous request. The Javascript engine finds the spot in the composite page where the component resides, and updates page fragment in place.''' The user sees an updated page. - - inline:action_component_ajax_title.gif - - A Struts component incorporated into a page looks and behaves uniformly whether it runs in Ajax mode or not. The dual-mode functionality of Struts web components is invaluable for environments where !JavaScript is not allowed or in browsers that do not support the XMLHTTPRequest object, like some mobile browsers. - - It is worth noting that both Ajax and non-Ajax modes utilize the same code and markup. - == Use Case: Home Page With Login Component == Consider the following use case: a website has a home page that should have different content for regular visitors one one hand, and for logged in users for another hand. The page contains login/logout form. A non-logged-in user must be presented with login, while a logged-in user should be able to log out. @@ -57, +31 @@ inline:login-component-sm.gif - = Building A Synchronous Component with Struts 1.4 = + == Building Struts Web Components == - The first exercise is building a synchronous, non-Ajax component. It is simpler than Ajax component because we do not need to fiddle with Javascript. On the other hand, it is more complex because instead of simply replacing one piece of page with another we need to figure out the location of original com
[Struts Wiki] Update of "StrutsManualActionWebComponentSync" by MichaelJouravlev
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/StrutsManualActionWebComponentSync
--
== Component Configuration ==
- First let us define the Login Component in {{{struts-config.xml}}} file:
+ Defining configuration before creating a component seems backwards, but
different configuration options affect component itself, so for the sake of
this example let us first define the parameters composite page and the login
component in {{{struts-config.xml}}} file. Do not forget to turn automatic
validation off, otherwise an event handler will not be called if associated
form bean failed validation. In Struts 1.4 event definitions are first-class
elements of an action mapping:
- {{{
-
+ {{{
@@ -46, +45 @@
}}}
- Notice action mapping attributes and properties that are new for Struts 1.4:
+ Observe attributes and properties that are new for Struts 1.4:
-* "component" attribute identifies an action as a component manager, such
actions are processed differently by Action class. This name is also used in
generated HTML for in-place update in Ajax mode.
+* "component" attribute contains the name of a component. It identifies an
action as a component manager, it is processed differently than a regular
action or behavioral action.
* "view" attribute identifies a default view for a component. Must be a
JSP page. Often consists from several subviews, in our case the Login Component
has two subviews "Not Logged In" and "Logged In", they will be defined in JSP
file.
* "form" is just another name for "name" property
-* "event" property allows to define request parameters as events, and
corresponding method handlers. This is made possible by supporting dispatching
functionality directly in Action class.
+* "event" property allows to define request parameters as events, and
corresponding method handlers.
+
+ In Struts 1.2.9 - 1.3.x Action class does not implement dispatching
functionality, and action mapping does not allow to define events. It is
recommended to use EventDispatchAction to handle incoming events, its events
are configured through {{{parameter}}} attribute:
+
+ '''Struts 1.2.9, 1.3.x:'''
+ {{{
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ }}}
+
+ Of course, Struts 1.2.9, 1.3.x do not support new "component", "view", "form"
and "event" properties. Use regular {{{forward}}} element to define a component
view. Use {{{name}}} attribute to define associated form bean.
== Component Action ==
- The action class is deceptively simple. It handles only two events, the
corresponding handlers are called automatically by Action class. The location
of component's view is defined in the action mapping, so render method is not
needed. On the other hand, most non-trivial components need to process data
before rendering themselves or to exchange data with other components. For
these cases you can use render" method. Its default implementation does nothing.
+ With Struts 1.4 the action class is deceptively simple. It handles only two
events, the corresponding handlers are called automatically by Action class.
The location of component's view is defined in the action mapping, so render
method is not needed. On the other hand, most non-trivial components need to
process data before rendering themselves or to exchange data with other
components. For these cases you can use render" method. Its default
implementation does nothing.
{{{
public class LoginAction extends Action {
@@ -102, +133 @@
// Always return null.
return null;
+ }
+ }
+ }}}
+
+ In Struts 1.2.9 - 1.3.x Action class does not implement dispatching
functionality, you need to extend a dispatching action. Use EventDispatchAction
as the simplest and the most flexible. Another difference is that you need to
specify an {{{ActionForward}}} object that points to a component view. You must
do it in {{{unspecified}}} method or whatever method you selected as default in
event definition.
+
+ Using EventDispatchAction to dispatch events gets you only halfway, because
there code that automatically distinguishes the address of a composite page and
then redirects to it is not present in older Struts versions. You need an
add-on library that contains this code. Then you need to call it from
{{{execute}}} method of your action. '''TODO'''
+
+ '''Struts 1.2.9, 1.3.x:'''
+ {{{
+ public class LoginAction extends EventDispatchAction {
+
+ public ActionForward execute (...) throws Exception {
+ ComponentUtils.componentReload(...); // TODO
+ }
+
+ public ActionForward login (...) throws Exception {
+ ...
+ }
+
+ publi
[Struts Wiki] Update of "StrutsManualActionWebComponentAsync" by MichaelJouravlev
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/StrutsManualActionWebComponentAsync -- + '''Attention: this page describes functionality that is not yet available! Work in progress!''' + == Struts Component Lifecycle In Asynchronous Mode == If the browser has !JavaScript turned on and the XMLHTTPRequest object is available, a web component is updated asynchronously; steps 1, 2 and 3 do not differ from synchronous mode: @@ -52, +54 @@ Notice action mapping attributes and properties that are new for Struts 1.4: +* "component" attribute contains the name of a component. This name is used by tag that generates DIV element around component markup. The ID of this DIV is assigned to the component name. When application returns updated markup, Javascript helper matches ID of returned markup with ID of enclosing element in composite page. Another role of component name is to identify an action as a component manager, it is processed differently than a regular action or behavioral action. * "component" attribute identifies an action as a component manager, such actions are processed differently by Action class. This name is also used in generated HTML for in-place update in Ajax mode. * "view" attribute identifies a default view for a component. Must be a JSP page. Often consists from several subviews, in our case the Login Component has two subviews "Not Logged In" and "Logged In", they will be defined in JSP file. * "form" is just another name for "name" property
