Struts An Open Source Mvc Implementation

developerWorks : Java : Struts, an open-source MVC implementation

IBM Home Products Consulting Industries News About IBM Search

IBM : developerWorks : Java™ overview : Library - papers

Download it now!
PDF (154 KB)
Struts, an open-source MVC implementation Free Acrobat™ Reader
Manage complexity in large Web sites with this servlets and JSP framework
Malcolm Davis
Consultant
February 2001
This article introduces Struts, a Model-View-Controller implementation that uses Contents:
servlets and JavaServer Pages (JSP) technology. Struts can help you control change in Introduction
your Web project and promote specialization. Even if you never implement a system JSP is a servlet
with Struts, you may get some ideas for your future servlets and JSP page
No more Java in my
implementations.
HTML
Introduction
MVC
Kids in grade school put HTML pages on the Internet. However, there is a monumental
MVC Model 2
difference between a grade school page and a professionally developed Web site. The page
designer (or HTML developer) must understand colors, the customer, product flow, page Struts
layout, browser compatibility, image creation, JavaScript, and more. Putting a great looking
Struts details
site together takes a lot of work, and most Java developers are more interested in creating a
Mailing list sample
great looking object interface than a user interface. JavaServer Pages (JSP) technology
provides the glue between the page designer and the Java developer. Before and after
Future of Struts
If you have worked on a large-scale Web application, you understand the term change.
Model-View-Controller (MVC) is a design pattern put together to help control change. MVC Resources
decouples interface from business logic and data. Struts is an MVC implementation that uses About the author
Servlets 2.2 and JSP 1.1 tags, from the J2EE specifications, as part of the implementation.
You may never implement a system with Struts, but looking at Struts may give you some
ideas on your future Servlets and JSP implementations.
In this article, I will begin with a JSP file that uses elements you may be familiar with and discuss the pros and cons of
such a page. I will then cover Struts and how it can control change in your Web project and promote specialization.
Finally, I will re-develop the simple JSP file with the page designer and change in mind.
A JSP file is a Java servlet
A JavaServer Page (JSP) file is nothing more than another way to view a servlet. The concept of a JSP file is to allow
us to see a Java servlet as an HTML page. This view eliminates all of the ugly print() statements that normally
show up in Java code. The JSP file is pre-processed into a .java file, then compiled into a .class. If you are using
Tomcat, you can view your pre-processed .java files in the work directory. Other containers may store the .java
and .class files elsewhere; the location is container specific. Figure 1 demonstrates the JSP file-to-servlet flow.
Figure 1. JSP file-to-servlet flow

(This is significantly different from a Microsoft Active Server Page (ASP). An ASP is compiled into memory, not into
a separate file.)
The simple self-contained JSP file

http://www-106.ibm.com/developerworks/java/library/j-struts/ (1 of 15) [4/20/2001 4:00:38 PM]


In a small JSP application, it is common to see the data, business logic, and the user interface combined into one
module of code. In addition, the application generally contains the logic that controls the flow of the application.
Listing 1 and Figure 2 demonstrate a simple JSP file that allows a user to join a mailing list.
Listing 1. join.jsp -- a simple request and response JSP file

<%@ page language=quot;javaquot; %>
<%@ page import=quot;business.util.Validationquot; %>
<%@ page import=quot;business.db.MailingListquot; %>
<%
String error = quot;quot;;
String email = request.getParameter(quot;emailquot;);

// do we have an email address
if( email!=null ) {

// validate input...
if( business.util.Validation.isValidEmail(email) ) {

// store input...
try {
business.db.MailingList.AddEmail(email);
} catch (Exception e) {
error = quot;Error adding email address to system. quot; + e;
}

if( error.length()==0 ) {
%>
// redirect to welcome page...
<jsp:forward page=quot;welcome.htmlquot;/>
<%
}
} else {
// set error message and redisplay page
error = email + quot; is not a valid email address, please try again.quot;;
}

} else {
email = quot;quot;;
}
%>
<html>
<head>
<title>Join Mailing List</title>
</head>
<body>
<font color=red><%=error%></font><br>

<h3>Enter your email to join the group</h3>
<form action=quot;join.jspquot; name=quot;joinFormquot;>
<input name=quot;emailquot; id=quot;emailquot; value=<%=email%>></input>
<input type=submit value=quot;submitquot;>
</form>



</body>
</html>

Figure 2. In a simple request and response, the JSP file sets the data, controls the flow to the next page, and
creates the HTML

The mailing list JSP file is a self-contained, do-it-all module. The only things not contained in the JSP file are the
actual code for validation that is contained in isValidEmail() and the code that puts the e-mail address in the
database. (Separating the isValidEmail() method into reusable code might seem like an obvious thing to do, but
I have seen the code for isValidEmail() embedded directly into the page.) The advantage of the single-page
approach is that it is easy to understand and initially easy to build. In addition, with all the graphical development
tools, it is easy to get started.
Activities of join.jsp
1. Display opening input page.
2. Read the email value from the form parameter.
3. Validate the email address.
4. If email address is valid:
r Add the address to the database.

r Redirect to the next page.

5. If email address is invalid:
r Set an error message.

r Redisplay join.jsp with the error message.

Consequences of the single-page approach
q Heavy HTML and Java coupling
The coder of the JSP file must be both a page designer and a Java developer. The result is often either terrible
Java code or an ugly page, or sometimes both.

Java and JavaScript blur
q
As the pages become larger, there can be a tendency to implement some JavaScript. When the JavaScript
appears in a page, the script can get confused with the Java code. An example of a possible point of confusion is
using client-side JavaScript to validate the email field.

Embedded flow logic
q
To understand the entire flow of the application, you have to navigate all of the pages. Imagine the spaghetti
logic on a 100-page Web site.

Debugging difficulties
q
In addition to being ugly to look at, HTML tags, Java code, and JavaScript code all in one page makes it
difficult to debug problems.

Tight coupling
q
Changes to business logic or data means possibly touching every page involved.

Aesthetics
q


Visually, in large pages, this type of coding looks messy. When I was doing Microsoft ASP development, I
would commonly see 1000-line pages. Even with syntax coloring, it was still difficult to read and understand.
No more Java code in my HTML, please
In Listing 1, instead of having a lot of HTML in Java code, I have a lot of Java code in an HTML file. From this
standpoint, I really have not accomplished much, other than permit page designers to write Java code. However, all is
not lost; with JSP 1.1, we got a new feature called tags.
A JSP tag is simply a way of abstracting out code from a JSP file. Some people think of JSP tags as macros for JSP
files, where the code for the tag is contained in the servlet. (The macro perspective is almost true.) For the same
reason I do not want to see HTML tags in Java code, I do not want to see Java code in a JSP file. The entire point of
JSP technology is to allow the page designer to create servlets without being distracted with Java code. Tags allow
Java programmers to extend JSP files by making Java code look like HTML. Figure 3 displays the general concept of
pulling the code from the JSP page and putting into a JSP tag.
Figure 3. JSP tag

An example of Struts tag capability is in Listing 2. In Listing 2, the normal HTML <form> tag is replaced with the
Struts <form:form> tag. Listing 3 shows the resulting HTML that the browser receives. The browser gets the
HTML <form> tag, but with additional code, such as the JavaScript. The additional JavaScript sets the focus on the
email address field. The server side <form:form> tag code created the appropriate HTML and abstracts the
JavaScript away from the page designer.
Listing 2. Struts form tag

<form:form action=quot;join.doquot; focus=quot;emailquot; >
<form:text property=quot;emailquot; size=quot;30quot; maxlength=quot;30quot;/>
<form:submit property=quot;submitquot; value=quot;Submitquot;/>
</form:form>

Listing 3. Resulting HTML sent to the browser

<form name=quot;joinFormquot; method=quot;POSTquot; action=quot;join.do;jsessionid=ndj71hjo01quot;>
<input type=quot;textquot; name=quot;emailquot; maxlength=quot;30quot; size=quot;30quot; value=quot;quot;>
<input type=quot;submitquot; name=quot;submitquot; value=quot;Submitquot;>
</form>
<script language=quot;JavaScriptquot;>

</script>

Notes about JSP tags:
q JSP tags require a container that runs JSP 1.1 or later.

JSP tags run on the server and are not interpreted by the client like HTML tags are.
q

JSP tags provide proper code re-use.
q


HTML and JavaScript can be added to pages using a JSP mechanism called include. However, developers
q
have a tendency to create huge JavaScript library files, and these libraries are included into the JSP file. The
result is a much larger than necessary HTML page returned to the client. The proper use of include is for
HTML snippets for such things as page headers and footers.

By abstracting out the Java code, JSP tags have promoted specialization of development roles.
q

Model-View-Controller (MVC)
JSP tags solved only part of our problem. We still have issues with validation, flow control, and updating the state of
the application. This is where MVC comes to the rescue. MVC helps resolve some of the issues with the single
module approach by dividing the problem into three categories:
q Model
The model contains the core of the application's functionality. The model encapsulates the state of the
application. Sometimes the only functionality it contains is state. It knows nothing about the view or controller.

View
q
The view provides the presentation of the model. It is the look of the application. The view can access the
model getters, but it has no knowledge of the setters. In addition, it knows nothing about the controller. The
view should be notified when changes to the model occur.

Controller
q
The controller reacts to the user input. It creates and sets the model.
MVC Model 2
The Web brought some unique challenges to software developers, most notably the stateless connection between the
client and the server. This stateless behavior made it difficult for the model to notify the view of changes. On the Web,
the browser has to re-query the server to discover modification to the state of the application.
Another noticeable change is that the view uses different technology for implementation than the model or controller.
Of course, we could use Java (or PERL, C/C++ or what ever) code to generate HTML. There are several
disadvantages to that approach:
q Java programmers should develop services, not HTML.

q Changes to layout would require changes to code.

q Customers of the service should be able to create pages to meet their specific needs.

q The page designer isn’t able to have direct involvement in page development.

q HTML embedded into code is ugly.

For the Web, the classical form of MVC needed to change. Figure 4 displays the Web adaptation of MVC, also
commonly known as MVC Model 2 or MVC 2.
Figure 4. MVC Model 2



Struts, an MVC 2 implementation
Struts is a set of cooperating classes, servlets, and JSP tags that make up a reusable MVC 2 design. This definition
implies that Struts is a framework, rather than a library, but Struts also contains an extensive tag library and utility
classes that work independently of the framework. Figure 5 displays an overview of Struts.
Figure 5. Struts overview

Struts overview
q Client browser
An HTTP request from the client browser creates an event. The Web container will respond with an HTTP
response.

Controller
q
The Controller receives the request from the browser, and makes the decision where to send the request. With
Struts, the Controller is a command design pattern implemented as a servlet. The struts-config.xml file
configures the Controller.

Business logic
q
The business logic updates the state of the model and helps control the flow of the application. With Struts this
is done with an Action class as a thin wrapper to the actual business logic.

Model state
q
The model represents the state of the application. The business objects update the application state. ActionForm
bean represents the Model state at a session or request level, and not at a persistent level. The JSP file reads
information from the ActionForm bean using JSP tags.

View
q
The view is simply a JSP file. There is no flow logic, no business logic, and no model information -- just tags.
Tags are one of the things that make Struts unique compared to other frameworks like Velocity.
Struts details
Displayed in Figure 6 is a stripped-down UML diagram of the org.apache.struts.action package. Figure 6
shows the minimal relationships among ActionServlet (Controller), ActionForm (Form State), and Action
(Model Wrapper).
Figure 6. UML diagram of the relationship of the Command (ActionServlet) to the Model (Action &
ActionForm)



The ActionServlet class
Do you remember the days of function mappings? You would map some input event to a pointer to a function. If you
where slick, you would place the configuration information into a file and load the file at run time. Function pointer
arrays were the good old days of structured programming in C.
Life is better now that we have Java technology, XML, J2EE, and all that. The Struts Controller is a servlet that maps
events (an event generally being an HTTP post) to classes. And guess what -- the Controller uses a configuration file
so you don’t have to hard-code the values. Life changes, but stays the same.
ActionServlet is the Command part of the MVC implementation and is the core of the Framework.
ActionServlet (Command) creates and uses Action, an ActionForm, and ActionForward. As mentioned
earlier, the struts-config.xml file configures the Command. During the creation of the Web project, Action
and ActionForm are extended to solve the specific problem space. The file struts-config.xml instructs
ActionServlet on how to use the extended classes. There are several advantages to this approach:
q The entire logical flow of the application is in a hierarchical text file. This makes it easier to view and
understand, especially with large applications.

The page designer does not have to wade through Java code to understand the flow of the application.
q

The Java developer does not need to recompile code when making flow changes.
q

Command functionality can be added by extending ActionServlet.
The ActionForm class
ActionForm maintains the session state for the Web application. ActionForm is an abstract class that is
sub-classed for each input form model. When I say input form model, I am saying ActionForm represents a general
concept of data that is set or updated by a HTML form. For instance, you may have a UserActionForm that is set
by an HTML Form. The Struts framework will:
q Check to see if a UserActionForm exists; if not, it will create an instance of the class.

Struts will set the state of the UserActionForm using corresponding fields from the HttpServletRequest. No
q
more dreadful request.getParameter() calls. For instance, the Struts framework will take fname from
request stream and call UserActionForm.setFname().

The Struts framework updates the state of the UserActionForm before passing it to the business wrapper
q
UserAction.



Before passing it to the Action class, Struts will also conduct form state validation by calling the
q
validation() method on UserActionForm. Note: This is not always wise to do. There might be ways
of using UserActionForm in other pages or business objects, where the validation might be different.
Validation of the state might be better in the UserAction class.

The UserActionForm can be maintained at a session level.
q

Notes:
q The struts-config.xml file controls which HTML form request maps to which ActionForm.

q Multiple requests can be mapped UserActionForm.

q UserActionForm can be mapped over multiple pages for things such as wizards.

The Action class
The Action class is a wrapper around the business logic. The purpose of Action class is to translate the
HttpServletRequest to the business logic. To use Action, subclass and overwrite the process() method.
The ActionServlet (Command) passes the parameterized classes to ActionForm using the perform()
method. Again, no more dreadful request.getParameter() calls. By the time the event gets here, the input
form data (or HTML form data) has already been translated out of the request stream and into an ActionForm class.
Note: quot;Think thinquot; when extending the Action class. The Action class should control the flow and not the logic of
the application. By placing the business logic in a separate package or EJB, we allow flexibility and reuse.
Another way of thinking about Action class is as the Adapter design pattern. The purpose of the Action is to
quot;Convert the interface of a class into another interface the clients expect. Adapter lets classes work together that
couldn’t otherwise because of incompatibility interfacequot; (from Design Patterns - Elements of Reusable OO Software
by Gof). The client in this instance is the ActionServlet that knows nothing about our specific business class
interface. Therefore, Struts provides a business interface it does understand, Action. By extending the Action, we
make our business interface compatible with Struts business interface. (An interesting observation is that Action is a
class and not an interface. Action started as an interface and changed into a class over time. Nothing's perfect.)
The Error classes
The UML diagram (Figure 6) also included ActionError and ActionErrors. ActionError encapsulates an
individual error message. ActionErrors is a container of ActionError classes that the View can access using
tags. ActionErrors is Struts way of keeping up with a list of errors.
Figure 7. UML diagram of the relationship of the Command (ActionServlet) to the Model (Action)

The ActionMapping class



An incoming event is normally in the form of an HTTP request, which the servlet Container turns into an
HttpServletRequest. The Controller looks at the incoming event and dispatches the request to an Action
class. The struts-config.xml determines what Action class the Controller calls. The
struts-config.xml configuration information is translated into a set of ActionMapping, which are put into
container of ActionMappings. (If you have not noticed it, classes that end with s are containers)
The ActionMapping contains the knowledge of how a specific event maps to specific Actions. The
ActionServlet (Command) passes the ActionMapping to the Action class via the perform() method.
This allows Action to access the information to control flow.
ActionMappings
ActionMappings is a collection of ActionMapping objects.
Mailing list sample revisited
Let’s see how Struts can solve the problems plaguing join.jsp. Two projects make up the rewrite. The first project
contains the business logic portion of the application that is independent of the Web application. The independent
layer could be a common service layer implemented with EJB technology. For demonstration purposes, I have created
a package called business using an Ant build process. There are several reasons for the independent business layer:
q Separate responsibilities
A separate package allows the manager to delegate responsibilities within the development group. This also
helps promote developer responsibility.

Off-the-shelf
q
Think of the developer as treating the package as a piece of commercial software. By putting it into a different
package, it gives it more of the feel of being off-the-shelf. The package might be off-the-shelf or might be
developed by a different group within your organization.

Avoiding unnecessary build and unit testing
q
A separate build process helps avoid unnecessary build and unit testing.

Developed using interfaces
q
It helps to think from an interface perspective when doing development and avoids possible coupling. This is an
extremely important fact. When doing your own business package, the business classes should not care if a Web
application or a stand-alone Java application is making the calls. Therefore, avoid any reference to servlet API
or Struts API calls in the business layer.

Stability
q
Not every organization conducts daily, weekly, or even monthly releases. Hence, when doing development,
stable interface points are nice. Just because the business package is in a state of flux, does not mean the Web
project should be in a state of flux.
Business build note
I use Ant to build the projects, and JUnit to run the unit test. The business.zip contains everything to build the business
project, except for Ant and JUnit. The package script will build the classes, run the unit test, create the Java docs and
jar file, and compress all of it into a zip file to deliver to a customer. You can deploy to other platforms by modifying
the build.xml. Business.jar is in the Web download portion, therefore, you do not have to download and
build the business package.
Web project
The second project is a Web application developed with Struts. You will need a JSP 1.1 and Servlet 2.2-compliant
container. The quickest way to get started is to download and install Tomcat 3.2 (see Resources). Until there is a 1.0
release of Struts, I recommend getting the latest build from the Jakarta project (see Resources). This has been a huge
issue for me, and I cannot insure that my sample Web project will build with your Struts download. Struts is in a
constant state of change, and I have had to constantly update my project. I used jakarta-struts-20010105.zip for this



project. Figure 8 displays the Web project layout. If you have Ant installed, running the build will create a war file
called joinStruts.war that is ready for deployment.
Figure 8. Web project layout

Listing 4 displays the converted JSP file called joinMVC.jsp. The file has gone from 50 lines to 19 lines, and now
contains no Java code. This is a huge improvement from a page designer perspective.
Listing 4. joinMVC.jsp -- simple JSP revisited

<%@ page language=quot;javaquot; %>
<%@ taglib uri=quot;/WEB-INF/struts.tldquot; prefix=quot;strutsquot; %>
<%@ taglib uri=quot;/WEB-INF/struts-form.tldquot; prefix=quot;formquot; %>
<html>
<head>
<title><struts:message key=quot;join.titlequot;/></title>
</head>
<body bgcolor=quot;whitequot;>

<form:errors/>
<h3>Enter your email to join the group</h3>

<form:text property=quot;emailquot; size=quot;30quot; maxlength=quot;30quot;/>
<form:submit property=quot;submitquot; value=quot;Submitquot;/>
</form:form>

</body>
</html>

Page changes
The following are the list of changes that occurred using the Struts tag library:
q Imports

<%@ taglib uri=quot;/WEB-INF/struts.tldquot; prefix=quot;strutsquot; %>
The <%@page import…> for Java has been replaced by <%@ taglib uri…> for the Struts tag library.

Text
q

<struts:message key=quot;join.titlequot;/>
The resource property file contains the text for join.title. In this example, ApplicationResources property
file contains the name-value pair. This makes string review and changes for internationalization easier.



Errors
q

<form:errors/>
ActionServlet or ActionForm builds the error message to display. These error messages can also be
contained in the property file. ApplicationResources also provides a way of formatting the error by setting
error.header and error.footer.

HTML Form
q

JSP <form> tags and attributes replace HTML <form> tags and attributes. <form
r
action=quot;join.jspquot; name=quot;joinquot;> has changed to <form:form action=quot;join.doquot;
focus=quot;emailquot; >.
HTML <input> tag has been replaced by <form:text/>.
r

HTML <submit> tag has been replaced by <form:submit/>.
r

Model -- Session state
JoinForm subclasses ActionForm and contains the form data. The form data in this example is simply the e-mail
address. I have added a setter and getter for the e-mail address for the framework to access. For demonstration
purposes, I overwrote the validate() method and used the error tracking feature of Struts. Struts will create
JoinForm and set the state information.
Model -- Business logic
As we discussed earlier, Action is the interface between the Controller and the actual business object.
JoinAction wraps the calls to the business.jar that was originally in join.jsp. The perform() method
for JoinAction is displayed in Listing 5.
Listing 5. - JoinAction.perform()

public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Extract attributes and parameters we will need
JoinForm joinForm = (JoinForm) form;
String email = joinForm.getEmail();

ActionErrors errors = new ActionErrors();

// store input....
try {
business.db.MailingList.AddEmail(email);
} catch (Exception e) {
// log, print stack

// display error back to user
errors.add(quot;emailquot;,new ActionError(quot;error.mailing.db.addquot;));
}

// If any messages is required, save the specified error messages keys
// into the HTTP request for use by the <struts:errors> tag.
if (!errors.empty()) {



saveErrors(request, errors);

// return to the original form
return (new ActionForward(mapping.getInput()));
}

// Forward control to the specified 'success' URI that is in the Action.xml
return (mapping.findForward(quot;successquot;));
}

Note: The perform() returns a class called ActionForward that tells the Controller where to go next. In this
example, I am using the mapping passed in from the Controller to determine where to go.
Controller
I have modified the JSP file and created two new classes: one to contain form data and one to call the business
package. Finally, I glue it all together with changes to the configuration file struts-config.xml. Listing 6
displays the action element I added to control the flow of joinMVC.jsp.
Listing 6. Action Configuration

<action path=quot;/joinquot;
name=quot;joinFormquot;
type=quot;web.mailinglist.JoinActionquot;
scope=quot;requestquot;
input=quot;/joinMVC.jspquot;
validate=quot;truequot;>
<forward name=quot;successquot; path=quot;/welcome.htmlquot;/>
</action>

The action element describes a mapping from a request path to the corresponding Action classes that should be used
to process the requests. Each request type should have a corresponding action element describing how to process the
request. On a join request:
1. joinForm is used to hold the form data.
2. Since validate is marked true, joinForm will try to validate itself.
3. web.mailinglist.JoinAction is the action class used to process requests for this mapping.
4. If everything works correctly, the request will forward to welcome.jsp.
5. If there is a business logic failure, the flow will return to joinMVC.jsp, which is the original page that made
the request. Why is this? In the action element in Listing 6 is an attribute called input with a value of
quot;/joinMVC.jspquot;. In my JoinAction.perform(), displayed in Listing 5, if the business logic fails,
perform() returns an ActionForward using mapping.getInput() as the parameter. The
getInput() in this instance is quot;/joinMVC.jspquot;. If the business logic fails, it will return to
joinMVC.jsp, which is the original page that made the request.
Before and after Struts
As we can see from Figure 9, a lot of complexity and layers have been added. No more direct calls from the JSP file to
the Service layer.
Figure 9. Before and after Struts



Struts pros
q Use of JSP tag mechanism
The tag feature promotes reusable code and abstracts Java code from the JSP file. This feature allows nice
integration into JSP-based development tools that allow authoring with tags.

Tag library
q
Why re-invent the wheel, or a tag library? If you cannot find something you need in the library, contribute. In
addition, Struts provides a starting point if you are learning JSP tag technology.

Open source
q
You have all the advantages of open source, such as being able to see the code and having everyone else using
the library reviewing the code. Many eyes make for great code review.

Sample MVC implementation
q
Struts offers some insight if you want to create your own MVC implementation.

Manage the problem space
q
Divide and conquer is a nice way of solving the problem and making the problem manageable. Of course, the
sword cuts both ways. The problem is more complex and needs more management.
Struts cons
q Youth
Struts development is still in preliminary form. They are working toward releasing a version 1.0, but as with
any 1.0 version, it does not provide all the bells and whistles.

Change
q
The framework is undergoing a rapid amount of change. A great deal of change has occurred between Struts 0.5
and 1.0. You may want to download the most current Struts nightly distributions, to avoid deprecated methods.
In the last 6 months, I have seen the Struts library grow from 90K to over 270K. I had to modify my examples
several times because of changes in Struts, and I am not going to guarantee my examples will work with the
version of Struts you download.

Correct level of abstraction
q
Does Struts provide the correct level of abstraction? What is the proper level of abstraction for the page
designer? That is the $64K question. Should we allow a page designer access to Java code in page
development? Some frameworks like Velocity say no, and provide yet another language to learn for Web
development. There is some validity to limiting Java code access in UI development. Most importantly, give a
page designer a little bit of Java, and he will use a lot of Java. I saw this happen all the time in Microsoft ASP
development. In ASP development, you were supposed to create COM objects and then write a little ASP script



to glue it all together. Instead, the ASP developers would go crazy with ASP script. I would hear quot;Why wait for
a COM developer to create it when I can program it directly with VBScript?quot; Struts helps limit the amount of
Java code required in a JSP file via tag libraries. One such library is the Logic Tag, which manages conditional
generation of output, but this does not prevent the UI developer from going nuts with Java code. Whatever type
of framework you decide to use, you should understand the environment in which you are deploying and
maintaining the framework. Of course, this task is easier said than done.

Limited scope
q
Struts is a Web-based MVC solution that is meant be implemented with HTML, JSP files, and servlets.

J2EE application support
q
Struts requires a servlet container that supports JSP 1.1 and Servlet 2.2 specifications. This alone will not solve
all your install issues, unless you are using Tomcat 3.2. I have had a great deal of problems installing the library
with Netscape iPlanet 6.0, which is supposedly the first J2EE-compliant application server. I recommend
visiting the Struts User Mailing List archive (see Resources) when you run into problems.

Complexity
q
Separating the problem into parts introduces complexity. There is no question that some education will have to
go on to understand Struts. With the constant changes occurring, this can be frustrating at times. Welcome to
the Web.

Where is...
q
I could point out other issues, for instance, where are the client side validations, adaptable workflow, and
dynamic strategy pattern for the controller? However, at this point, it is too easy to be a critic, and some of the
issues are insignificant, or are reasonable for a 1.0 release. The way the Struts team goes at it, Struts might have
these features by the time you read this article, or soon after.
Future of Struts
Things change rapidly in this new age of software development. In less than 5 years, I have seen things go from
cgi/perl, to ISAPI/NSAPI, to ASP with VB, and now Java and J2EE. Sun is working hard to adapt changes to the
JSP/servlet architecture, just as they have in the past with the Java language and API. You can obtain drafts of the new
JSP 1.2 and Servlet 2.3 specifications from the Sun Web site. Additionally, a standard tag library for JSP files is
appearing; see Resources for links to the specifications and the tag library.
Final notes
Struts solved some big problems using tags and MVC. This approach aided in code re-usability and flexibility. By
separating the problem into smaller components, you will be more likely to reuse when changes do occur in the
technology or problem space. Additionally, Struts enabled page designers and Java developers to focus on what they
do best. Yet, the tradeoff in increased robustness implies an increase in complexity. Struts is much more complex than
a simple single JSP page, but for larger systems Struts actually helps manage the complexity. Additionally, I do not
want to write my own MVC implementation, just learn one. Whether you use Struts or not, reviewing the Struts
framework (excuse me, library) can give you a better understanding of JSP files and servlets features, and how to
combine them for your next Web project. Just as struts are essential to the structure of a wing, Struts might become an
indispensable part of your next Web project.
Resources
q You can download the code used in this article: business.zip builds the business.jar and joinStruts.zip
builds the joinStruts.war file.

For Struts documentation, install notes, and downloads, see the Struts Home page.
q

You can download the most recent Struts implementation from the Jakarta project.
q



To get started, I recommend downloading the reference JSP servlet implementation Tomcat 3.2. If you are
q
using a container other than Tomcat, go to the Struts User Mailing List for help in installing Struts for your
particular environment.

See the Struts User Mailing List archive for additional information not covered in the documentation or
q
installation guide.

To learn more about combining the build and test process, see quot;Incremental development with Ant and JUnit.quot;
q

See the Proposed Final Draft for Java Servlet 2.3 and JavaServer Pages 1.2 Specifications.
q

See the Standard Tag Library for JavaServer Pages, JSR #000052.
q

About the author
Malcolm G. Davis is president of his own consulting company in Birmingham, Alabama. He considers himself a Java
Evangelist. When he is not preaching the virtues of Java, he spends time running and playing with his kids. You can
reach Malcolm at malcolm@nuearth.com.

What do you think of this article?
Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Comments?

Submit feedback

Privacy Legal Contact


Struts An Open Source Mvc Implementation

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Struts An Open Source Mvc Implementation