Hello,

  One goals of Tiles is to enable reuse and to avoid copy/paste. So, having to
copy same layouts in all sub-applications is not what we expect.
  Consequently, the actual behavior that you describe sound like a bug  ;-). I
have to dig a little bit to see what can be done. If you have more info, let me
know.

   Cedric

Ian Tomey wrote:

> Hi again,
>
> Been tracing through the code to see what the issue is (and if I can
> fix it quickly) and spotted the problem. I'm not sure if this is going
> to be problem anywhere else.
> quick recap of what is going on:
>
> call action in the /refdata sub app
> that returns a tiles-def reference, which points to a page
> /standardLayout.jsp
> the layout has reference to /refdata/showAllSchemes.do
> the tiles insert tag (supposedly) gets the value and inserts it into
> the layout page (by using pageContext.include in the tag )
> - boom - invalid action mapping.
>
> The reason this is failing is that struts is not picking up the sub
> application during the include. we are doing include on
> "/refdata/showAllSchemes.do". We hit the ActionServlet, which goes
> through to RequestUtils.selectApplication to determine the app. *this is
> where it goes horribly wrong*
>
>         // Acquire the path used to compute the sub-application
>         String matchPath = request.getServletPath();
>
> This gets however not  "/refdata/showAllSchemes.do" but
> "/standardLayout.jsp", so the selected application for mapping actions
> is the root application! (it then looks for the action named
> "/refdata/showAllSchemes" inside the default application config)
>
> Is this the expected behaviour when doing an include?. Later on in the
> RequestProcessor the correct uri is got from
>
>         path = (String) request.getAttribute(INCLUDE_SERVLET_PATH);
>         if (path == null) {
>             path = request.getServletPath();
>         }
>
> The first call gets the correct path (/refdata/showAllSchemes.do) in
> this case. Should this be done in RequestUtils.selectApplication as
> well?
>
> finally,
> an obvious way to get around these problems in tiles is to refer to a
> layout page in the sub application. unfortunately this means copying the
> layout page into every sub application. Then as well we loose access to
> the root application and have to copy the pages/action mappings into
> every sub app as well... GRRR!
>
> Ian
>
> �------------------------------
> Hi all,
>
> Got a problem trying to move our app over to using tiles and its
> probably specifically related to sub applications.
>
> In this simple case, we have the default app and a sub app called
> refdata. In the refdata config we have something along these lines:
>
> <action path="/showAScheme" type=".....">
>   <forward name="success" redirect="false" path="refdata.refdata" />
> </action>
>
> <action path="/showAllSchemes" type=".....">
>   <forward name="success" redirect="false" path="/tree.jsp" />
> </action>
>
> and the tile def:
>
> <definition name="refdata.refdata" extends="site.mainLayout">
>   <put name="body"   value="/refdata/showScheme.jsp" />
>   <put name="left"   value="/refdata/showAllSchemes.do" />
> </definition>
>
> Now, when we do http://localhost/testapp/refdata/showAScheme.do the
> showScheme.jsp displays, but the /refdata/showAllSchemes.do fails with
> an invalid request. However, if I place
>
>   <put name="left"   value="/applicationList.do" />
>
> in the tiledef then the application list action in the default app
> works fine.
>
> Obviously tiles is working in default app space. Anybody got a patch
> or
> workaround for this problem?
> Ian
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to