Differences between revisions 5 and 6
Revision 5 as of 2006-07-21 03:05:51
Size: 4920
Comment: Typos, style
Revision 6 as of 2009-09-20 23:12:13
Size: 4928
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
inline:basic_action_asp.gif {{attachment:basic_action_asp.gif}}

Web Resources, Actions And Views

A typical web application is a collection of resources linked with each other. In Struts web resources are represented with one or more action classes. When a user requests a web resource to render itself, a corresponding action class selects an appropriate view and sends it to the browser. Contrary to page-oriented framewors like ASP.NET where a web resource equals to a web page, in Struts one web resource can have several corresponding web pages.


Struts provides a clean separation between logical state of a web resource and its visual representation. Struts is agnostic to presentation technology; the output can be rendered using JSP file, Tile definition, Velocity template, XSLT stylesheet, PDF generator or other techniques.


Consider the Action that performs a search. The author of this code should not bother neither about how exactly the search criteria is obtained, nor about how the search results are presented. His only job is to say "what happened" after the search took place.

There are three possible outcomes:

  • No results were found => outcome "none".

  • Exactly one result was found => outcome "single".

  • More than one result was found => outcome "multiple".

It is up to the application architect to decide how to visually represent the search result. He can choose to render one resulting page for all outcomes, or to render a different page for every outcome. The code of the search action is not affected by this decision.

Round Trip And Postback

When a user interacts with a web resource and server-side processing is involved, a typical interaction consists of the following steps:

  1. The user requests a web resource from the web server.
  2. Struts selects an action class that handles requests to that web resource.
  3. The action class responds back with the page containing an HTML form.
  4. The user enters the data into HTML form and submits it to the web server.
  5. The action class processes the request, and sends the result back to the user.

The above interaction can be handled either with two different action classes or with one action class.

If two different action classes are involved, then the action class that renders a page is called a render action, while the class that processes submitted data is called a submit action.

If only one action class handles both render and submit phases, then step 4 can also be referred to as a postback, because input data is posted back to the same action that has displayed the page.

Steps 4 and 5 are collectively referred to as a round trip.

In a Struts application a user cannot navigate to a specific view, because viewsa are selected by actions. Instead, a user can navigate to a specific action. Control can be transferred from action to action programmatically as well.

An action may render a page that contains a link pointing to other actions. This way a user can manually navigate to another actions.

An action may render a page that contains an HTML form. When the form is submitted, the action analyzes input data and either forwards or redirects to another action. This way a user can be transferred to another web resource programmatically.

Struts allows submitting an HTML form to an arbitrary action, but it is recommended to process all submits in original web resource's action to keep things under control. The control should be transferred from the source action to destination action instead of directly submitting HTML form to destination action.

In-Server Forwarding

Forwarding transfers the execution from the current action to the specified action on the same server. If original action has created a response stream, it is reused by the new action. After forwarding occurs and view is returned to the browser, the browser still shows the address of original action. This happens because the forwarding occurs on the server side and the browser remains unaware of it.

Redirecting Via Browser

With redirection, server creates a response whose header contains a 302 (Object Moved) status code and the target URL. When the browser receives this response from the server, it uses the header information to generate another request to the new URL. When using redirection, the transfer of control happens at the client side and involves two round trips to the server.

You should use redirection in the following cases:

  • You want to connect to a resource on some other web server.
  • You want to connect to a non-Struts resource (such as an HTML file).
  • You want to pass the query string as part of the URL.
  • You want to have URL clean of parameters, passing them through session object.

StrutsNavigationBasics (last edited 2009-09-20 23:12:13 by localhost)