You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Moynihan, Michael A" <Mi...@Fmr.com> on 2008/01/22 20:46:59 UTC

Recommended Tiles Solution?

Hi All,

>From my research into tiles it looks like the recommended way to use
tiles with a Struts app is to create an action as follows 

<action path="/start" type="com.sample.action.SuccessAction">
	<forward name="success" path="login.layout" />
</action>

This specifies the forward path to "login.layout" which will then be
looked up in the tiles-def.xml In this file the definition can extend
from a more generic definition and insert what properties it needs to
set e.g. title, body.

<definition name="nomenu.layout" path="/WEB-INF/jsp/noMenuLayout.jsp">
	<put name="header" value="/WEB-INF/jsp/header.jsp" />
	<put name="footer" value="/WEB-INF/jsp/footer.jsp" />
</definition>

<definition name="login.layout" extends="nomenu.layout">
	<put name="title" value="Login" />
	<put name="body" value="/WEB-INF/jsp/login.jsp" />
</definition>


This approach requires an additional tiles definition for each mapping
in struts-config.xml, even though the only difference between the
definitions will be the new body parameter As a result, in my experience
the tiles-def.xml file can become quite large.


I've come across an approach which would reduce the size of the
tiles-def.xml and which I would like to get feedback from the open
source community on.  It is based around the possibility of creating a
generic tiles definition where the body parameter would be inserted
dynamically at run time and therefore remove the need to specify a new
definition for each mapping. 

This involves creating an action mapping as follows

<action path="/start" type="com.sample.action.SuccessAction">
	<forward name="success" path="nomenu.layout"
className="com.sample.action.TilesActionForward">
		<set-property property="tilesParameter"
value="body=/WEB-INF/jsp/login.jsp" />
	</forward>
</action>

The mapping specifies the path as the tiles definition to look up in the
tiles-def. However it also specifies an ActionForward class of
TilesActionForward. TilesActionForward extends
org.apache.struts.action.ForwardingActionForward and provides a setter
for the tilesParameter property. This forward is placed on the request
and is later used when the tiles definition is being implemented. In the
tiles-def.xml file, the following definition is defined 

<definition
controllerClass="com.sample.struts.tiles.CustomTilesController"
	    name="nomenu.layout" path="/WEB-INF/jsp/noMenuLayout.jsp">
	    <put name="header" value="/WEB-INF/jsp/header.jsp" />
	    <put name="footer" value="/WEB-INF/jsp/footer.jsp" />
	    <put name="body" value="" />
</definition>

Where a custom controller CustomTilesController which extends
org.apache.struts.tiles.ControllerSupport. is used. This controller
retrieves the forward from the request and dynamically inserts the
tilesParameter into the definition. This leads to a extremely clean
tiles-def.xml with only a few definitions defined.


Overall this looks like a viable alternative. The action mappings and
associated forward specifies the layout and the jsp pages to use for the
tiles implementation. In the tiles-def.xml files, only a few mappings
need to be specified with the CustomTilesController doing most of the
work to dynamically inserted the required JSP page.


I would like to get your opinion on both approaches. Is option 1 the
recommended solution for implementing tiles in a struts based app? Is
option 2 a viable solution for implementing tiles in a struts based app?
Do the benefits of a cleaner tiles definition file override some extra
configuration in struts-config? Can you see any flaws with this
approach? Is there some way of implementing option two with the
components already in Struts 1.2 or 1.3?

Any feedback appreciated.

Thanks,
Michael

Re: Recommended Tiles Solution?

Posted by Antonio Petrelli <an...@gmail.com>.
Michael, in Tiles 2 there is the TilesDecorationFilter:
http://tiles.apache.org/framework/apidocs/index.html

Ciao
Antonio

2008/1/22, Moynihan, Michael A <Mi...@fmr.com>:
> Hi All,
>
> From my research into tiles it looks like the recommended way to use
> tiles with a Struts app is to create an action as follows
>
> <action path="/start" type="com.sample.action.SuccessAction">
>         <forward name="success" path="login.layout" />
> </action>
>
> This specifies the forward path to "login.layout" which will then be
> looked up in the tiles-def.xml In this file the definition can extend
> from a more generic definition and insert what properties it needs to
> set e.g. title, body.
>
> <definition name="nomenu.layout" path="/WEB-INF/jsp/noMenuLayout.jsp">
>         <put name="header" value="/WEB-INF/jsp/header.jsp" />
>         <put name="footer" value="/WEB-INF/jsp/footer.jsp" />
> </definition>
>
> <definition name="login.layout" extends="nomenu.layout">
>         <put name="title" value="Login" />
>         <put name="body" value="/WEB-INF/jsp/login.jsp" />
> </definition>
>
>
> This approach requires an additional tiles definition for each mapping
> in struts-config.xml, even though the only difference between the
> definitions will be the new body parameter As a result, in my experience
> the tiles-def.xml file can become quite large.
>
>
> I've come across an approach which would reduce the size of the
> tiles-def.xml and which I would like to get feedback from the open
> source community on.  It is based around the possibility of creating a
> generic tiles definition where the body parameter would be inserted
> dynamically at run time and therefore remove the need to specify a new
> definition for each mapping.
>
> This involves creating an action mapping as follows
>
> <action path="/start" type="com.sample.action.SuccessAction">
>         <forward name="success" path="nomenu.layout"
> className="com.sample.action.TilesActionForward">
>                 <set-property property="tilesParameter"
> value="body=/WEB-INF/jsp/login.jsp" />
>         </forward>
> </action>
>
> The mapping specifies the path as the tiles definition to look up in the
> tiles-def. However it also specifies an ActionForward class of
> TilesActionForward. TilesActionForward extends
> org.apache.struts.action.ForwardingActionForward and provides a setter
> for the tilesParameter property. This forward is placed on the request
> and is later used when the tiles definition is being implemented. In the
> tiles-def.xml file, the following definition is defined
>
> <definition
> controllerClass="com.sample.struts.tiles.CustomTilesController"
>             name="nomenu.layout" path="/WEB-INF/jsp/noMenuLayout.jsp">
>             <put name="header" value="/WEB-INF/jsp/header.jsp" />
>             <put name="footer" value="/WEB-INF/jsp/footer.jsp" />
>             <put name="body" value="" />
> </definition>
>
> Where a custom controller CustomTilesController which extends
> org.apache.struts.tiles.ControllerSupport. is used. This controller
> retrieves the forward from the request and dynamically inserts the
> tilesParameter into the definition. This leads to a extremely clean
> tiles-def.xml with only a few definitions defined.
>
>
> Overall this looks like a viable alternative. The action mappings and
> associated forward specifies the layout and the jsp pages to use for the
> tiles implementation. In the tiles-def.xml files, only a few mappings
> need to be specified with the CustomTilesController doing most of the
> work to dynamically inserted the required JSP page.
>
>
> I would like to get your opinion on both approaches. Is option 1 the
> recommended solution for implementing tiles in a struts based app? Is
> option 2 a viable solution for implementing tiles in a struts based app?
> Do the benefits of a cleaner tiles definition file override some extra
> configuration in struts-config? Can you see any flaws with this
> approach? Is there some way of implementing option two with the
> components already in Struts 1.2 or 1.3?
>
> Any feedback appreciated.
>
> Thanks,
> Michael
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org