Multiple Sub-applications
One of the shortcomings in Struts 1.0 is manageability of the configuration
file (commonly known as struts-config.xml) when the development of the
application involves a sizable team. This problem arises because a Struts-based
application must run under one controller servlet,
the ActionServlet, and the ActionServlet
can use only one struts-config.xml. It is not an issue when the project is
relatively small and the team consists of a couple of developers; however, when
the project size becomes significant and the project involves a large number of
developers, maintaining all the mapping information in a single file becomes
increasingly problematic.
Struts 1.1 solves this problem nicely by introducing
multiple sub-applications. In Struts 1.1, each sub-application has its own
struts-config.xml file. A large Struts-based application can thus be easily
partitioned into largely independent modules, i.e. sub-applications, and each
sub-team can maintain their struts-config.xml independently.
The sub-application scheme is a natural extension of the servlet
context mapping scheme of the URI paths used by servlet
containers. According to the Servlet standard, when
the servlet container receives a request with a URL,
the servlet container will try to match the prefix of
the URI path to a deployed web-application in the container. What Struts 1.1
does is it maps the second prefix of the path to a sub-application. In effect,
this prefix mapping scheme creates another level of namespace for each
sub-application. For example, for the URI,
http://some-host.com/myApp/module2/editSubscription.do
/myApp is the context path for a web-application
called "myApp" and /module2 is the sub-app
prefix for a Struts sub-application called "module2".
DynaBean and BeanUtils
Another major complaint usually heard amongst Struts 1.0 users is the extensive
effort involved in writing the FormBean (a.k.a. ActionForm) classes.
Struts provides two-way automatic population between
HTML forms and Java objects, the FormBeans. To take
advantage of this however, you have to write one FormBean
per HTML form. (In some use cases, a FormBean can
actually be shared between multiple HTML forms. But those are specific cases.)
Struts' FormBean standard follows faithfully the
verbose JavaBean standard to define and access
properties. Besides, to encourage a maintainable architecture, Struts enforces
a pattern such that it is very difficult to 'reuse' a model-layer object (e.g.
a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to
spend a significant amount of time to write tedious getters/setters for all the
FormBean classes.
Struts 1.1 offers an alternative, Dynamic ActionForms,
which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of
the BeanUtils library. (Both the DynaBeans
and the BeanUtils library were found to be useful and
generic enough that they have been 'promoted' into Jakarta's Commons project.)
With Dynamic ActionForms, instead of coding the
tedious setters/getters, developers can declare the required properties in the
struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then
onwards, The Dynamic ActionForm instance is treated
as if it is an ordinary JavaBean by Struts and the BeanUtils library.
Validator
The Validator is not exactly a new
feature. The Validator has been in the contrib package in the distribution since Struts 1.0.1.
Since then, part of it has now been refactored and
moved into the Jakarta-Commons subproject and renamed the Commons-Validator and the Struts specific portion is now called the
Struts-Validator. However, since it is in the contrib package, people may overlook it and it is
worthwhile to mention it here.
The Validator provides an extensible framework to
define validation rules to validate user inputs in forms. What is appealing in
the Validator is that it generates both the
server-side validation code and the client-side validation code (i.e. Javascript) from the same set of validation rules defined
in an XML configuration file. The Validator performs
the validation based on regular-expression pattern matching. While a handful of
commonly used validators are shipped with the
framework (e.g. date validator, range validator), you can always define your own ones to suit
your need.
Default Sub-application
To maintain backward compatibility, Struts 1.1 allows one default
sub-application per application. The URI of the resources (i.e. JSPs, HTMLs,
etc) in the default sub-application will have an empty sub-app prefix. This
means when an existing 1.0 application is "dropped" into Struts 1.1,
theoretically, it will automatically become the default sub-application.
Direct Requests to JSPs
To take the full advantage of sub-application support, Struts 1.1 stipulates
the requirement that all requests must flow through the controller servlet, i.e. the ActionServlet.
Effectively, this means all JSPs must be fronted by Actions. Instead of
allowing direct requests to any of the JSPs, all requests must go through an
Action and let the Action forward to the appropriate JSP.
This is perhaps the biggest impact of migration to Struts 1.1 if you have not
followed this idiom in your applications. This restriction is required because
without going through the ActionServlet, Struts
navigation taglibs (e.g. <html:form> and <html:link>)
used in the JSPs will not have the correct sub-app context to work with.
ActionServlet
Configurations
With the introduction of sub-applications, a more flexible way is introduced to
configure each sub-application independently. Many of the configuration entries
(e.g. resource bundle location, maximum upload file size, etc) that used to be
defined in web.xml have now been moved to struts-config.xml. The original
entries in web.xml are deprecated but will still be effective.
Action.execute() and Action.getResources()
In Struts 1.0, request handling logic is coded in Action.perform();
however, Action.perform() throws only IOException and SevletException.
To facilitate the new declarative exception handling , the request handling
method needs to throw Exception, the superclass of
all the checked exceptions. Therefore, to both maintain backward compatibility
and facilitate declarative exception handling, Action.perform()
is now deprecated in favour of Action.execute().
You also have to be careful if you use DispatchAction
in your existing applications. At the time of writing, the DispatchAction
in Struts 1.1 beta has not yet been updated to use execute(). (A bug report has
been filed in Struts' bug database.) Therefore, without modifying the DispatchAction class yourself, declarative exception
handling will not work with DispatchAction
subclasses.
In addition, Action.getResources() is now deprecated.
Instead, you should call Action.getResources(HttpServletRequest) instead. This allows Struts to return
to you the sub-application specific message resources. Otherwise, the message
resources for the default sub-app will be used.
Library Dependency
Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects
(e.g. Commons-Logging, Commons-Collections, etc.). Some of these libraries may
cause classloading conflicts in some servlet containers. So far, people have reported in the
mailing list the classloading problem of
commons-digester/jaxp1.1, and commons-logging causing deployment difficulties
in Struts 1.1 applications running on Weblogic 6.0.
(The problems have been corrected in Weblogic 6.1 and
7.0.)
Resources under WEB-INF
According to the Servlet specification, resources
(e.g. JSP files) stored under WEB-INF are protected and cannot be accessed
directly by the browsers. One design idiom for Struts 1.0 is to put all the JSP
files under WEB-INF and front them by Actions so that clients cannot illegally
access the JSPs. With the introduction of sub-application prefixes in Struts
1.1, mapping resources under WEB-INF gets complicated. Extra configuration
steps utilizing the pagePattern and forwardPattern attributes of the element in
struts-config.xml is required to inform Struts to construct the paths
correctly. More specifically, you need to set these attributes to the pattern
"/WEB-INF/$A$P".
What is the Jakarta Struts
Framework?
Jakarta Struts is an open source implementation of MVC
(Model-View-Controller) pattern for the development of web based applications.
Jakarta Struts is a robust architecture and can be used for the development of
applications of any size.
The “Struts framework” makes it easier to design scalable, reliable Web
applications.
What is an ActionServlet?
The class org.apache.struts.action.ActionServlet is
called the ActionServlet.
In the Jakarta Struts Framework this class plays the role of controller.
All the requests to the server go through the “Controller”.
The “Controller” is responsible for handling all the requests.
How can one make any “Message Resources” definitions file available
to the “Struts Framework” environment?
Answer: “Message Resources” definitions file are simple .properties files and
these files contain the messages that can be used in the struts project.
“Message Resources” definition files can be added to the struts-config.xml file
through <message-resources /> tag. Example:
<message-resources parameter="MessageResources"
/>
What is an “Action Class”?
The “Action Class” is part of the “Model” and is a wrapper around
the business logic.
The purpose of the “Action Class” is to translate the HttpServletRequest
to the business logic.
To use the “Action”, we need to subclass and overwrite the execute() method.
All the database and business processing is done in the “Action” class.
It is advisable to perform all the database related work in the “Action” class.
The ActionServlet (command) passes the parameterized
class to ActionForm using the execute() method.
The return type of the execute method is ActionForward
which is used by the Struts Framework to forward the request to the file
according to the value of the returned ActionForward
object.
No comments:
Post a Comment