Converting the Mini HR Application to Use Modules


Using Tiles with Modules

Like Validator, in order to use Tiles with modules, you have to add the Tiles plugin to each module's Struts configuration file that you want to use Tiles with. For example, if your application has two modules, moduleA and moduleB, you have to add a Tiles plugin definition to moduleA's Struts configuration file and a definition to moduleB's Struts configuration file. This is necessary so that each module's Tiles configuration file can be specified. In versions of Struts prior to 1.3, this was also necessary because Struts uses a separate request processor for each module, and the Tiles plugin added its own custom request processor that extended the base Struts request processor (per module). If you didn't add the Tiles plugin to each module's Struts configuration file, not all modules would have the Tiles request processor that was necessary for processing forwards to Tiles definitions.

Following is the standard Tiles plugin definition that you would have in your Struts configuration file for a non-modularized Struts application:

<!-- Tiles Configuration --> <plug-in className="org.apache.struts.tiles.TilesPlugin">   <set-property property="definitions-config"                    value="/WEB-INF/tiles-defs.xml"/> </plug-in>

You would use this exact same definition in each Module's Struts configuration file for a modularized application. Of course, the name of the Tiles configuration file specified with the definitions-config property would change with each module, unless they all shared the same configuration file.

If you want each of your modules to have its own Tiles configuration file and don't want each module's Tiles definitions to be shared across modules, you can indicate this intent with the Tiles plugin moduleAware parameter. Following is a sample Tiles plugin definition for the Struts configuration file that illustrates this:

<!-- Tiles Configuration --> <plug-in className="org.apache.struts.tiles.TilesPlugin">   <set-property property="definitions-config"                    value="/WEB-INF/tiles-defs.xml"/>   <set-property property="moduleAware" value="true"/> </plug-in>

By default, Tiles stores each module's configuration file settings in the same internal configuration structure. Thus, moduleA can see all of the Tiles definitions from moduleB's Tiles configuration file and vice versa. Tiles does this by default to save memory in case each module uses the same configuration file. However, in most cases each module has its own module-specific definitions that other modules shouldn't be able to access. For this scenario, you set the moduleAware property to true. This informs Tiles to create a separate configuration structure for each module's Tiles definitions.

As explained earlier, module prefixes apply only to actions. Thus, any URLs to JSPs specified in your Tiles configuration files are not relative to a module prefix but rather are relative to the root of the application, just as they are in non-modularized Struts applications.



Struts. The Complete Reference
Struts: The Complete Reference, 2nd Edition
ISBN: 0072263865
EAN: 2147483647
Year: 2004
Pages: 165
Authors: James Holmes

Similar book on Amazon
Struts 2 in Action
Struts 2 in Action
Murach's Java Servlets and JSP, 2nd Edition
Murach's Java Servlets and JSP, 2nd Edition
Jakarta Struts For Dummies
Jakarta Struts For Dummies
Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam
Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam

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