Configuring multiple application modules


So far we have covered several important built-in Actions with examples. There is one more feature that is very important and useful addition in 1.1 ‚ Multiple Application module support. In Struts1.0 (and earlier), a single config file was supported. This file, normally called struts-config.xml , was specified in web.xml as an initialization parameter for the ActionServlet as follows :

 <servlet>    <servlet-name>mybank</servlet-name>    <servlet-class>org.apache.struts.action.ActionServlet    </servlet-class>    <init-param>      <param-name>config</param-name>      <param-value>/WEB-INF/struts-config.xml</param-value>    </init-param> </servlet> 

The single configuration file is bottleneck in large projects as all developers had to contend to modify this resource. In addition managing a monolithic file is painful and error prone. With Struts1.1 this problem has been resolved by the addition of multiple sub application support better known as application modules. You can now have multiple configuration files, one for each module or logical group of forms. The configuration files are specified in web.xml file using multiple < init-param > - initialization parameters as shown in Listing 4.4.

Listing 4.4: web.xml setting for Multiple Application module Support
 <servlet>    <servlet-name>mybank</servlet-name>    <servlet-class>org.apache.struts.action.ActionServlet    </servlet-class>    <init-param>      <param-name>config</param-name>      <param-value>/WEB-INF/struts-config.xml</param-value>    </init-param>   <  init-param  >   <  param-name  >  config/module1  <  /param-name  >   <  param-value  >  /WEB-INF/struts-module1-config.xml    <  /param-value  >   <  /init-param  > </servlet> 
 

The newly added application module is shown in bold. The default application module based on struts-config.xml can still continue to exist. The new module is defined by adding an initialization parameter config/module1 . In fact any init-param prefixed with ‚“ config/ ‚½ is interpreted as configuration for a separate module. Its corresponding value ‚ /WEB-INF/struts-module1-config.xml is the struts configuration file containing Form bean definitions and ActionMappings for the module module1. If the URLs in the default struts-config.xml were accessed as http://localhost:8080/App1/start.do, and the corresponding ActionMapping were moved to struts-module1-config.xml then the URL would be accessed as http://localhost:8080/App1/module1/start.do where App1 is the web application context. Notice that the application URL contains the module name after the web application context as if it is a sub directory name.

Even though each application module has a separate struts configuration file and a sub-directory like url pattern while accessing through the browser, the physical organization need not necessarily be the same although that is generally the route taken since the application module was after all created for logical division (driven by functional requirements) and there are less headaches if the physical organization matches the logical division as much as possible.

The benefits of application modules are immediately obvious. You can now split your monolithic struts application into logical modules thus making maintenance easier. It will cause less contention during development time as developers working on different modules get to work on their own struts configuration files. Each Struts Configuration file and hence each application module can choose its own RequestProcessor , MessageResources and PlugIn . You can now choose to implement one or more modules with Tiles. If you find this convenient and useful then you can migrate your application to Tiles or JSF or plug in any other Struts extensions for one module at a time.

Here is a tip: Generally web applications are organized so that navigation occurs from generic to specific. For instance, you start from the initial welcome page for the web application and then navigate to a specific module. You can organize you struts modules so that the initial welcome page and other top-level pages are defined in the default application module ( struts-config.xml ). The pages correspond to individual use cases are defined in different application modules ( struts-config-xxx.xml ). You can then navigate from the default application module to the use case specific module.

That brings up the question: How do you move between application modules? It is quite simple actually. Struts 1.1 provides a specialized Action called SwitchAction . We will illustrate its usage with an example.

Consider a Struts banking application with a default module (with top level pages) and another module named loanModule . The JSPs of the loan module are present in a directory called loanModule and its action mappings are defined in struts-config-loan.xml .

  • The top-level page defined in the default application module provides hyperlink to navigate to the loan module as shown below. This hyperlink indicates points to a global-forward named goto-loanModule in the default struts-config.xml .

     <html:link forward="goto-loanModule">                Go to Loan Module           </html:link> 
  • Add the action mapping for SwitchAction to the default struts-config.xml as follows:

     <action path="/switch"             type="org.apache.struts.actions.SwitchAction"/> 
  • Now, add a global-forward named goto-loanModule to the default struts-config.xml as follows:

     <forward name="goto-loanModule"      path="/switch.do?page=/listloans.do&amp;prefix=/loanModule" /> 

    This global-forward turn points to an action mapping called switch.do and also adds two request parameters. The switch.do is the ActionMapping for the SwitchAction . The two request parameters ‚ prefix and page stand for the module and the action mapping within that module. In this case, the module is loanModule (identified by the struts-config-loan.xml ) and the listloans.do stands for an action mapping within the struts-config-loan.xml ‚ the Struts Config file for Loan module.

  • In the struts-config-loan.xml , add the action mapping for listloans.do as follows:

     <action     path="/listloans"                      type="mybank.app1.ListLoanAction">          </action> 

The ListLoanAction is a normal Struts Action that decides the next resource to forwards in its execute() method. If you don ‚ t have additional processing to do, you can use a ForwardAction too.

If you want to go from the Loan module to the default module, repeat the same process, by setting the prefix attribute to a zero length string.




Struts Survival Guide. Basics to Best Practices
Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)
ISBN: 0974848808
EAN: 2147483647
Year: 2004
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net