Struts Applications
 
   

Struts Dialogs: Mail Reader

PDF
PDF

Overview

This document is based on Ted Husted's documentation for original MailReader application. For the sake of readability the modifications of the original text are not shown. The non-relevant portions of original document like plugins, database, Commons Validator are removed, please refer to original MailReader documentation.

The premise of the MailReader is that it is the first iteration of a portal application. This version allows users to register themselves and to create and maintain a set of accounts with various mail servers. When completed, the application would let users read mail from their accounts. This sample application does not allow sending and receiving of real emails, it collects user information and mail addresses only.

The MailReader application demonstrates registering with an application, logging into an application, maintaining a master record, and maintaining child records. This document walks through the JSP pages, Struts Java classes, and Struts configuration elements needed to do these things.

The walkthrough starts with how the initial page is displayed, and then steps through logging in, adding and editing subscriptions, and creating a new registration.

Actions

The goal of Struts is to simplify development of web applications. It is facilitated by means of custom requests handlers called actions. You may think of action as of mini-servlet.

An action performs the following functions:

  • receives a request from browser;
  • interprets request parameters;
  • updates domain objects if needed;
  • generates dynamic output;

The actions are listed in a configuration file and identify web resources. Actions can generate different output depending on state of web resource and on request parameters.

An accepted practice in Struts is to never link directly to server pages, but only to the actions. In Struts, the role of server page is reduced to data-aware HTML, used exclusively as presentation technology.

"Link actions not pages."

By linking to actions, developers can "rewire" an application without editing the server pages.

The picture below shows the structure of MailReader application, developed with Struts Dialogs. It is slightly changed from original MailReader for simplicity and clarity. Notice, that different pages are not linked to each other, making up a "flow". Instead, pages are organized as a table, where rows correspond to web resources, and columns correspond to state of these web resources.

MailReader Matrix

MailReader has four distinct web resources: Home, Accounts, Login and Subscriptions. Each resource behaves differently depending on state. Theare are two application-wide states: "Not Logged In" and "Logged In" that indicate whether a user is logged in or not.

Home, Accounts and Login resources exist in both states, while Subscriptions resource has meaningful output only for "Logged In" state, because Subscriptions resorce displays email subscriptions for currently logged-in user.

Each web resource is defined with one Struts action class and one or more JSP pages. For example, Home resource defines only one JSP page, which is modified at runtime, while Login resource defines two distinct pages, each for one state.

Nice thing about stateful resources is that they produce valid output whenever they are navigated to. There is no need to establish a strict flow between resources or their pages.

Index Page

Struts allows developers to manage an application through "virtual pages" called actions. A web application, like any other web site, can specify a list of welcome pages. When you open a web application without specifying a particular page, a welcome page is used by default. Unfortunately, actions cannot be specified as a welcome page. So, in the case of a welcome page, how do we follow the Struts best practice of navigating through actions rather than pages?

One solution is to use a server page to "bootstrap" a Struts action. A Java web application recognizes the idea of "forwarding" from one action (or page) to another action (or page). We can register the usual index.jsp as the welcome page and have it forward redirect to a "Home" action. Here's the MailReader's index.jsp:

 <%@ taglib uri="/tags/struts-logic" prefix="logic" %>
 <%@ page session="false">
 <logic:redirect action="/Home"/>

At the top of the page, we import the "struts-logic" JSP tag library. (Again, see the Preface to the Struts User Guide for more about the technologies underlying Struts.) We also tell the server to wait creating a session. The page itself consists of a single tag that redirects to the "Welcome" action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?

The actions, along with other Struts components, are registered through one or more Struts configuration files. The configuration files are written as XML documents and processed when the application starts.

Mail Reader components

See detailed discussion of each component of Mail Reader in the following sections.