[From the Kickstart FAQ]
"Java Servlets are designed to handle requests made by Web browsers. Server pages are designed to create dynamic Web pages that can turn billboard sites into interactive applications. Struts uses a special Servlet as a switchboard to route requests from Web browsers to the appropriate server page. This makes Web applications much easier to design, create, and maintain."
That's a good high-level description, but let's describe the mechanisms and dependencies of the framework in more detail.
(WEB-INF/web.xml)which you must write. This file describes the configuration of your web application, including welcome pages (the file that is shown in a directory when none is specified by the request), mappings to servlets (path or extension name), and parameters to those servlets.
web.xml file, you configure the framework
as the servlet that will handle all requests for a
given mapping (usually
.do is used).
The ActionServlet is the "switchboard" mentioned in the
Also in the
web.xml, you configure the
one or more configuration files for Struts itself.
For now, let's say we are installing the web
application on the server using
/myapp as a location,
and we are using the simplest possible configuration
If you need more details on deployment descriptors, read the relevant Servlet Specification available from Sun Microsystem's Java site.
Actionclasses (i.e. "login" ==> LoginAction class). This tells the
ActionServletthat for the incoming request
http://myhost/myapp/login.doit should invoke your controller component,
Note the extension
in this URL. The extension causes
your container (i.e. Tomcat) to call the
which sees the word "login" as the thing you want to
configuration is referenced, and your
Action,you also configure the framework with the names of the resulting page(s) that can be shown as a result of that action. There can be more than one view as the result of an action (often, there are at least two: one for "success", and one for "failure").
(the controller component you write) is based on
result mapping names. It reports back to the
using words like "success", "failure",
"ready", "ok", "UserError", et cetera. The framework
configuration that you wrote) knows how to forward to
page. This has the added advantage of reconfiguration
the view layer by simply editing the XML configuration
At this point, the framework knows how to delegate to your controller components, and what to show as a result of your controller processing. The "model" part of the application is completely up to you, and is called from within your controller components.
These Beans are automatically made visible to your
and any view page that is associated with
These Beans can also be validated with the help of the framework to help insure that the user is putting good data in the form. They can be carried along with a session, allowing forms to span multiple pages of the view, and Actions in the controller.
Note: You must be using some sort of server-side technology (JSP, Velocity, XSLT) for the view layer (going to the client) to see this data (plain HTML won't work). The framework works on the server side, so the client's view has to be composed there.
The client feeds the data back through normal form submission (POST/GET) methods, and the framework updates that data in the Bean before calling your controller components.
Even plain HTML files can be used within your application, although they will not take full advantage of all of the dynamic features.
Following the example of the Struts JSP taglibs, several other packages are available to make the framework easy to use with your favorite presentation technology. For Velocity templates, there are the Velocity ViewTools for Struts. If you want to use XSLT in you application, you can choose between stxx and StrutsCX.
These packages make the standard Struts framework elements look and feel like a seamless part of the original presentation technology. Struts also makes it easy to mix and match. If need be, you can use JSP, Velocity templates, and XSLT all in the same application!
Since Struts relies on standard Servlet technologies, you should be able to use any Java presentation technology with Struts.
The custom JSP tags account for a good deal of the Struts code base. It is educational to note that as of version 1.1b3 the Java code for the core of Struts was about 28,000 lines, and the Java code for the tag libraries (including tiles) was about 41,000 lines.
These tags help you glue your view layer to the controller layer without having to embed a lot of Java in the JSP. This gives the page an XML look, and can be easier for web designers to deal with than a plain JSP. It also helps minimize dependencies between the controller and view.
The custom tags are used to create forms (and invisibly interact with the Bean mentioned previously), logically forward to other pages, and invoke other actions of the web application.
There are also tags that help you with internationalization, error messages, etc.
All of these abilities depend in some way on the configuration files you supplied to Struts.
It is important for you to remember that the mechanism
described here is only in effect when the
is handling the request.
Since this only happens when a request is submitted that
container (i.e. Tomcat, WebSphere, whatever) to call
you must be sure that any page that relies on Struts is
done through a request that will map to the
(i.e. it has a