What is Struts?

Struts is a framework that promotes the use of the Model-View-

Controller architecture for designing large scale applications. The
framework includes a set of custom tag libaries and their associated
Java classes, along with various utility classes. The most powerful
aspect of the Struts framework is its support for creating and
processing web-based forms

Struts is an MVC implementation that uses Servlets 2.2 and JSP 1.1

tags, from the J2EE specifications, as part of the implementation.

Struts Tags

Common Attributes

Almost all tags provided by the Struts framework use the following

attributes:

Attribute Used for

id the name of a bean for temporary use by the tag

name the name of a pre-existing bean for use with the tag

property the property of the bean named in the name attribute for use
 with the tag

scope the scope to search for the bean named in the name attribute

1.1 Forward into the Past! (or a brief history of Struts)

When Java servlets were first invented, many programmers quickly

realized that they were a Good Thing. They were faster and more
powerful that standard CGI, portable, and infinitely extensible.

But writing HTML to send to the browser in endless println()

statements was tiresome and problematic. The answer to that was
JavaServer Pages, which turned Servlet writing inside-out. Now
developers could easily mix HTML with Java code, and have all the
advantages of servlets. The sky was the limit!

Java web applications quickly became "JSP-centric". This in-and-of

itself was not a Bad Thing, but it did little to resolve flow control issues
and other problems endemic to web applications.

Clearly, another paradigm was needed ...

Many clever developers realized that JavaServer Pages AND servlets

could be used together to deploy web applications. The servlets could
help with the control-flow, and the JSPs could focus on the nasty
business of writing HTML. In due course, using JSPs and servlets
together became known as Model 2 (meaning, presumably, that using
JSPs alone was Model 1).

Of course, there is nothing new under the Sun ... and many have been
quick to point out that JSP's Model 2 follows the classic Model-View-
Controller design pattern abstracted from the venerable Smalltalk MVC
framework. Java Web developers now tend to use the terms Model 2
and MVC interchangeably. In this guide, we use the MVC paradigm to
describe the framework architecture, which might be best termed a
Model 2/MVC design.

The Apache Struts Project was launched in May 2000 by Craig R.

McClanahan to provide a standard MVC framework to the Java
community. In July 2001, version 1.0 was released, and IOHO, Java
Model 2 development has never been quite the same.
1.2 The Model-View-Controller ('MVC') Design Pattern

The term "MVC" originated with the SmallTalk Model-View-Controller

framework. Under MVC, an application is seen as having three distinct
parts. The problem domain is represented by the Model. The output to
the user is represented by the View. And, the input from the user is
represented by Controller.

1.2.1 The Model: System State and Business Logic JavaBeans

The Model portion of an MVC-based system can be often be divided

into two major subsystems -- the internal state of the system and
the actions that can be taken to change that state.

In grammatical terms, we might think about state information as

nouns (things) and actions as verbs (changes to the state of those
things).

Many applications represent the internal state of the system as a set of

one or more JavaBeans. The bean properties represent the details of
the system' state. Depending on your application's complexity, these
beans may be self contained (and know how to persist their own
state), or they may be facades that know how to retrieve the system's
state from another component. This component may be a database, a
search engine, an Entity Enterprise JavaBean, a LDAP server, or
something else entirely.

Large-scale applications will often represent the set of possible

business operations as methods that can be called on the bean or
beans maintaining the state information. For example, you might have
a shopping cart bean, stored in session scope for each current user,
with properties that represent the current set of items that the user
has decided to purchase. This bean might also have a checkOut()
method that authorizes the user's credit card and sends the order to
the warehouse to be picked and shipped. Other systems will represent
the available operations separately, perhaps as Session Enterprise
JavaBeans (Session EJBs).

In a smaller scale application, on the other hand, the available

operations might be embedded within the Action classes that are part
of the framework control layer. This can be useful when the logic is
very simple or where reuse of the business logic in other environments
is not contemplated.

The framework architecture is flexible enough to support most any

approach to accessing the Model, but we strongly recommend that
you separate the business logic ("how it's done") from the role that
Action classes play ("what to do"). 'nuff said.

For more about adapting your application's Model to the framework,

see the Building Model Components chapter.

1.2.2 The View: JSP Pages and Presentation Components

The View portion of a Struts-based application is most often

constructed using JavaServer Pages (JSP) technology. JSP pages can
contain static HTML (or XML) text called "template text", plus the
ability to insert dynamic content based on the interpretation (at page
request time) of special action tags. The JSP environment includes a
set of standard action tags, such as <jsp:useBean> whose purpose is
described in the JavaServer Pages Specification. In addition to the
built-in actions, there is a standard facility to define your own tags,
which are organized into "custom tag libraries."

The framework includes a set of custom tag libraries that facilitate

creating user interfaces that are fully internationalized and interact
gracefully with ActionForm beans. ActionForms capture and validate
whatever input is required by the application.

For more about the Struts taglibs and using presentation pages with
the framework, see the Building View Components section. Additional
documentation regarding the taglibs is also available in the Taglibs
subproject.

1.2.3 The Controller: ActionServlet and ActionMapping

Struts provides the Controller portion of the application. The Controller

is focused on receiving requests from the client (typically a user
running a web browser), deciding what business logic function is to be
performed, and then delegating responsibility for producing the next
phase of the user interface to an appropriate View component. The
primary component of the Controller in the framework is a servlet of
class ActionServlet. This servlet is configured by defining a set of
ActionMappings. An ActionMapping defines a path that is matched
against the request URI of the incoming request and usually specifies
the fully qualified class name of an Action class. All Actions are
subclassed from [org.apache.struts.action.Action]. Actions encapsulate
calls to business logic classes, interpret the outcome, and ultimately
dispatch control to the appropriate View component to create the
response. While the framework dispatches to a View, actually
rendering the View is outside its scope.

Advantages Of Struts:-

Struts offers a number of significant advantages :Here is a summary:

 Centralized File-Based Configuration.

Rather than hard-coding information into Java programs, many

Struts values are represented in XML or property files. This loose

coupling means that many changes can be made without

modifying or recompiling Java code, and that wholesale changes

can be made by editing a single file. This approach also lets Java

and Web developers focus on their specific tasks (implementing

business logic, presenting certain values to clients, etc.) without

needing to know about the overall system layout.

 Bean Tags.

Apache Struts provides a set of custom JSP tags (bean:write, in

particular) that let you easily output the properties of JavaBeans

 components. Basically, these are concise and powerful variations

of the standard jsp:useBean and jsp:getProperty tags.

 HTML Tags.

Apache Struts provides a set of custom JSP tags to create HTML

forms that are associated with JavaBeans components. This

bean/form association serves two useful purposes:

o It lets you get initial form-field values from Java objects.

o It lets you redisplay forms with some or all previously

entered values intact.

 Form Field Validation.

Apache Struts has built in capabilities for checking that form

values are in the required format. If values are missing or in an

improper format, the form can be automatically redisplayed with

error messages and with the previously entered values

maintained.

This validation can be performed on the server (in Java), or

both on the server and on the client (in JavaScript).

 Consistent Approach.

Struts encourages consistent use of MVC throughout your

application.
Disadvantages of Struts

Although Struts has a number of significant advantages over the

standard servlet and JSP APIs alone, due to its complexity it has some

serious drawbacks as well.

 Bigger Learning Curve.

To use MVC with the standard RequestDispatcher, you need to be

comfortable with the standard JSP and servlet APIs. To use MVC

with Struts, you have to be comfortable with the standard JSP

and servlet APIs and a large and elaborate framework that is

almost equal in size to the core system. This drawback is

especially significant with smaller projects, near-term deadlines,

and less experienced developers; you could spend as much time

learning Struts as building your actual system.

 Worse Documentation.

Compared to the standard servlet and JSP APIs, Struts has fewer

online resources, and many first-time users find the online

Apache documentation confusing and poorly organized. There are

also fewer books on Apache Struts than on standard servlets and

JSP.
  Less Transparent.

With Struts applications, there is a lot more going on behind the

scenes than with normal Java-based Web applications. As a

result, Struts applications are:

o Harder to understand

o Harder to benchmark and optimize

 Rigid Approach.

The flip side of the benefit that Struts encourages a consistent

approach to MVC is that Struts makes it difficult (but by no

means impossible) to use other approaches.

Now, if these disadvantages sound significant, they were meant to.

Struts has some significant advantages, but the overhead and

complexity of Struts can be a burden as well. Before you decide if

Struts is right for your projects, you should try a simple Struts

application to get a feel for it. Then, carefully weigh the advantages

and disadvantages and decide if all of the Struts benefits outweigh the

negatives. Sometimes they will; other times they won't.

What Is the Struts Framework?

The Struts Framework is a standard for developing well-architected

Web applications. It has the following features:

  Open source

 Based on the Model-View-Controller (MVC) design paradigm,

distinctly separating all three levels:

o Model: application state

o View: presentation of data (JSP, HTML)

o Controller: routing of the application flow

 Implements the JSP Model 2 Architecture

 Stores application routing information and request mapping in a

single core file, struts-config.xml

The Struts Framework, itself, only fills in the View and Controller

layers. The Model layer is left to the developer.

Architecture Overview
All incoming requests are intercepted by the Struts servlet controller.

The Struts Configuration file struts-config.xml is used by the controller

to determine the routing of the flow. This flows consists of an

alternation between two transitions:

A user clicks on a link or submits a form on an HTML or JSP

From page. The controller receives the request, looks up the

View to mapping for this request, and forwards it to an action. The

Action action in turn calls a Model layer (Business layer) service or

function.

From After the call to an underlying function or service returns to

Action to the action class, the action forwards to a resource in the

View View layer and a page is displayed in a web browser.

The diagram below describes the flow in more detail:

1. User clicks on a link in an HTML page.

2. Servlet controller receives the request, looks up mapping

information in struts-config.xml, and routes to an action.

3. Action makes a call to a Model layer service.

4. Service makes a call to the Data layer (database) and the

requested data is returned.

5. Service returns to the action.

6. Action forwards to a View resource (JSP page)

7. Servlet looks up the mapping for the requested resource and

forwards to the appropriate JSP page.

8. JSP file is invoked and sent to the browser as HTML.

9. User is presented with a new HTML page in a web browser.