Components Needed to Build Struts2 Applications

<--Previous                                                                                      Next-->

1.       User Forms (view):

1. Here the user form means jsps in our case as we use the jsps for to represent the data to the user.  We will write the presentation login in the jsps.  In the struts 2 framework jsps act as the view part of the MVC design pattern.
2. These jsps contains the action to where this request should go. And by default every request will go the FilterDispatcher.

2.       Filter Dispatcher (Controller)

a.  The controller’s job is to map requests to actions. In a web application, the incoming HTTP requests can be thought of as commands that the user issues to the application.

b.  One of the fundamental tasks of a web application is routing these requests to the appropriate set of actions that should be taken within the application itself. This controller’s job is like that of a traffic cop or air traffic controller.

c.    The role of the controller is played by the Struts 2 FilterDispatcher. This important object is a servlet filter that inspects each incoming request to determine which Struts 2 action should handle the request.

d.  The framework handles all of the controller work for us. We just need to inform the framework which request URLs map to which of your actions. We can do this with XML-based configuration files or Java annotations. 

      3.       Action (Model):

a.  Action is the main component of the struts2 framework.  This will act as the Model component in the Struts2 framework.

b.  Each URL is mapped to some specific action, and that action is responsible to provide the processing logic for that particular request.

c.   It is the mediator between the view part and the database.

d.   The only requirement for actions in Struts2 is that there must be one no-argument method that returns either a String or Result object and must be a POJO. If the no-argument method is not specified, the default behavior is to use the execute() method.

e.   Optionally you can extend the ActionSupport class which implements six interfaces including Action interface.

Implementation of the Action interface defined as follows

public interface Action {
   public static final String SUCCESS = "success";
   public static final String NONE = "none";
   public static final String ERROR = "error";
   public static final String INPUT = "input";
   public static final String LOGIN = "login";
   public String execute() throws Exception;
}

These are the main components of the struts2 framework.  But to make them work we need some more configurations.  Those are, configuring the FilterDispatcher as controller and configuration for mapping the requests to the Actions.
4.       Web.xml (Deployment descriptor):

As FilterDispatcher act as a controller and it is responsible to pick up every request from the view part.  So we need to configure this in the web.xml to use this as a front controller.  We can configure FilterDispatcher in the following ways.

If any request comes with the .do extension it will go to the FilterDispatcher.

< filter >
< filter-name >struts2 < /filter-name>
< filter-class > org.apache.struts2.dispatcher.FilterDispatcher
< /filter-class >
< /filter >

 In struts based web applications, we should send all the requests to the web application through the FilterDispatcher along with their path values. To achieve above requirement it is suggestible to use extension match method for defining url pattern for FilterDispatcher.

<filter-mapping>

<filter-name>struts2</filter-name>

<url-pattern>/*.do</url-pattern>

</filter-mapping>

If any request comes with the .do extension it will go to the FilterDispatcher.

5.       Struts.xml (Struts configuration file):

The struts.xml file contains the configuration information that you will be modifying as actions are developed. This file can be used to override default settings for an application, for example struts.devMode = false and other settings which are defined in property file. This file can be created under the folder WEB-INF/classes.

< ?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE struts PUBLIC

   "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"

   "http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>

   <constant name="struts.devMode" value="true" />

   <package name="helloworld" extends="struts-default">

    

      <action name="hello"

            class="com.javaguide.struts2.HelloWorldAction"

            method="execute">

            <result name="success">/HelloWorld.jsp</result>

      </action>

      <-- more actions can be listed here -->

   </package>

   <-- more packages can be listed here -->

</struts>

The first thing to note is the DOCTYPE. All struts configuration file need to have the correct doctype as shown in our little example. is the root tag element, under which we declare different packages using tags. Here allows separation and modularization of the configuration. This is very useful when you have a large project and project is divided into different modules.

Say, if your project has three domains - business_applicaiton, customer_application and staff_application, you could create three packages and store associated actions in the appropriate package. The package tag has the following attributes:

Attribute	Description
name (required)	The unique identifier for the package
Extends	Which package does this package extend from? By default, we use struts-default as the base package.
Abstract	If marked true, the package is not available for end user consumption.
Namespace	Unique namespace for the actions

The constant tag along with name and value attributes will be used to override any of the following properties defined in default.properties, like we just set struts.devMode property. Setting struts.devMode property allows us to see more debug messages in the log file.

We define action tags corresponds to every URL we want to access and we define a class with execute() method which will be accessed whenever we will access corresponding URL.

Results determine what gets returned to the browser after an action is executed. The string returned from the action should be the name of a result. Results are configured per-action as above, or as a "global" result, available to every action in a package. Results have optional name and type attributes. The default name value is "success".

Struts.xml file can grow big over time and so breaking it by packages is one way of modularizing it, but struts offers another way to modularize the struts.xml file. You could split the file into multiple xml files and import them in the following fashion.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE struts PUBLIC

    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"

    "http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>

     <include file="my-struts1.xml"/>

     <include file="my-struts2.xml"/>

</struts>