Michael, in Tiles 2 there is the TilesDecorationFilter: http://tiles.apache.org/framework/apidocs/index.html
Ciao Antonio 2008/1/22, Moynihan, Michael A <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
