On Thu, 27 Jan 2005 13:54:26 +0100, Diego Manilla Suárez
<[EMAIL PROTECTED]> wrote:
> Hi! I need to process a tiles definition that is located in a different
> module. I have this ActionForward declared on the module I want to invoke:
>
> <forward name="myPage" path=".myTilesDefinition" redirect="false"/>
>
> And on the main module, I have this code (in an action) to get that
> forward definition.
>
> ActionForward forward = null;
> ServletContext context = getServlet().getServletContext();
> ModuleConfig config =
> ModuleUtils.getInstance().getModuleConfig("othermodule", context);
> if (config != null &&
> "org.apache.struts.action.ActionForward".equals(config.getActionForwardClass()))
> {
> forward = (ActionForward)config.findForwardConfig("myPage");
> }
> return forward;
>
> This doesn't work because Tiles is not processing the definition
> ".myTilesDefinition" (I have two separate Tiles definition
> configurations, one for each module). How can I get the definition on
> the other module processed by Tiles?
>
> I know I can import the definitions of the second module using
> <set-property property="definitions-config" ...> in struts-config.xml,
> but I'm wondering if it's possible to do what I want without this
> "trick". With TilesUtilStrutsModulesImpl class I get the
> DefinitionsFactory object for the second module, but I can't get past there.
>
Doesn't seem to be possible with the default TilesProcessor because
the DefinitionsFactory is tied to an instance of TilesProcessor and
once such processor exists for each module and the TilesProcessor only
looks up for the definitions in the DefinitionsFactory that it has in
it's instance. So, if your TilesProcessor is processing a request in
one module and if you want to forward to another module's tile
definition, the current module's TilesProcessor wouldn't be able to
find your tile definition.
* By subclassing TilesProcessor and overriding
processTilesDefinitions() method to look for definitions for all the
modules would be one solution
* If it's only a simple set of forwards which are common across
modules, then listing them in all modules might not be a bad solution
> Thanks in advance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
