|< Day Day Up >|| |
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 because Struts uses a separate request processor for each module, and the Tiles plugin adds its own custom request processor that extends the base Struts request processor (per module). If you don't add the Tiles plugin to each module's Struts configuration file, not all modules will have the Tiles request processor that is 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 nonmodularized 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 nonmodularized Struts applications.
|< Day Day Up >|| |