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 And Web Forms == - 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, the form would be redisplayed, keeping information entered by the user, and displaying relevant error messages. + 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. + To explain how this use case is handled in Struts let us turn to HTTP specification. HTTP defines eight request methods, two of which are directly related to web forms. Below are relevant quotes from RFC 2616, abridged and slightly edited for readability: - This use case is so common and so important that it gave name to a certain web framework developed by a company from Redmond. This company spent significant amount of time making sure that developing for Web is as easy as designing a desktop application. How does Struts fare? - - First, a brief recap of HTTP specification. HTTP defines eight request methods, two of these directly relate to handling of web forms. Below are relevant quotes from RFC 2616, abridged and slightly edited for readability: '''GET:''' The GET method means retrieve whatever information is identified by the Request-URI. GET method SHOULD NOT have the significance of taking an action other than retrieval [and] ought to be considered "safe". '''POST:''' The POST method is used to request the server to accept the entity enclosed in the request. POST is designed to allow a uniform method to ... post a message to a bulletin board, newsgroup, mailing list ... [or] to provide a block of data, such as the result of submitting a form, to a data-handling process. - The HTTP specification defines a fundamental concept of web interaction in two distinct phases: + The above definitions explain fundamental concepts of web interaction. They define input/output as a process consisting of two phases. It is important that both phases are initiated by browser. + * On ''render phase'' (''output phase'', ''render response phase'') the browser retrieves information identified by request URI. This can be a static page, an output of some process or a visual representation of a resource that corresponds to URI. * On ''input phase'' (''submit phase'', ''event phase'', ''apply request values phase'') the browser sends input data to an URI, usually by submitting an HTML form. == Action And Setup/Submit Pattern == - Two-phase request/response concept is traditionally implemented in Struts with setup/submit pattern: + Two-phase 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. - One of the reasons of splitting this functionality into two actions is that Action class uses just one {{{execute()}}} method to handle all kinds of requests. (Servlet has separate {{{doGet()}}} and {{{doPost()}}} methods.) - inline:setup_submit_improved.gif - - inline:icon_alert.gif The above diagram shows the improved Setup/Submit Pattern. To see the original Setup/Submit Pattern click here (TODO). A typical Setup Action will often implement the following logic in its {{{execute}}} method: @@ -88, +83 @@ * 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. + 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. == Action As Event Dispatcher == - Event Dispatcher 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. Event Dispatcher usually changes application state based on incoming message. Application state can be stored in a database, a flat file or in a scoped object like !HttpSession or !HttpServletRequest. + 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 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. + 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. - Struts defines several dispatch classes 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 Action subclass. + 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. - In an interactive application dispatch actions usually handle one I/O phase, either input events or render requests. Thus the task of handling input and output is conveniently split into separate Actions. + Event dispatchers usually handle one input/output phase. Event dispatchers can be used in setup/submit pattern, substituting several submit actions with just one. - Automatic validation should be turned off in {{{struts-config.xml}}} file to ensure that a handler is always called for an incoming event. + Note: to ensure that event handlers are always called, automatic validation should be turned off in {{{struts-config.xml}}} file. + + See tips on using event-dispatching action and code sample (TODO link) == Action As Web Resource Manager == - Many Struts users think in terms of simple actions and pages. It may be beneficial to think it terms of more generic web resources. A ''web resource'' is a representation of a business object that an interactive application works with. For example, a Customer resource can be displayed in "View" and "Edit" modes, and can accept "New", "Edit", "Delete" and "Save" messages. Would not it be simpler to represent this entity with only one Action? + Many Struts users think in terms of simple actions and pages. It may be beneficial to think it terms of more generic web resources. A ''web resource'' is a representation of a business object that an interactive application works with. For example, a Customer resource can be displayed in "View" and "Edit" modes, and can accept "New", "Edit", "Delete" and "Save" messages. - This is possible with a dispatching Action. You can differentiate input and render phases either by request type (GET vs. POST) or by presence of an event parameter in the request. + 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. - A Web Resource Manager does the following: - * 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). - - Implementing both input and output phases as well as event handlers in one Action class brings the complexity of Struts web form management down to the level of ASP.NET. inline:web_resource_asp.gif + See tips on using web resource manager and code sample (TODO link) + == Action As Web Component Manager == - 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. + A web component is a web resource that 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_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. - See [:StrutsManualActionWebComponent:Developing Web Components With Struts] section for further discussion. + See [:StrutsManualActionWebComponent:Developing Web Components With Struts] on using web component manager and code samples.
