You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by sh...@ubs.com on 2003/05/14 12:52:27 UTC
tiles defination nesting question..
Hi All,
Can we compose a tiles defination using two other tiles definations in a tiles-def.xml file?
I have a generic defination(Classic layout..header,footer,menu and content area),called classicLayout.def.
***********************
<snippet-from-tiles-defs.xml>
<definition name="classicLayout.def" path="/WEB-INF/jsp/tiles/layouts/base_template.jsp">
<put name="header" value="/WEB-INF/jsp/tiles/header.jsp" />
<put name="navigation" value="/WEB-INF/jsp/tiles/sidebar.jsp" />
<put name="content" value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
<put name="footer" value="/WEB-INF/jsp/tiles/footer.jsp" />
</definition>
</snippet-from-tiles-defs.xml>
***********************
And then for all the pages I have same elements at top of content area..(Title for functionality and then heml:erros tag..)So what i have done is defined another defination only for the content area.It can take the header and content to be included.(lets call it basecontent.def)
***********************
<snippet-from-tiles-defs.xml>
<!-- Defines a template for contet portion of page which contains header and error tag.Most common use as content portion of equate.tile.basedefination-->
<definition name="myapp.tile.basebody" path="/WEB-INF/jsp/tiles/layouts/base_body_template.jsp">
<put name="content" value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
</definition>
</snippet-from-tiles-defs.xml>
***********************
The jsp base_body_template.jsp looks like this...
******************************
<%@ taglib uri="/WEB-INF/equate.tld" prefix="equate" %>
<%@ taglib uri="struts-tiles" prefix="tiles" %>
<--! make available all attributes of defination in page scope-->
<tiles:importAttribute name="title_key" ignore="true"/>
<%String key=title_key; %>
<% if(key != null){
%>
<div class="titleBox"><myapptag:message key="<%=key%>"/></div>
<%
}
%>
<equate:errors/>
<tiles:insert attribute="content" />
********************************
Now I want to create a third defination which says that take the classic layout definaton(classicLayout.def).And in that defination, insert the basecontent.def for content area.But when using xml file to define this, i dont see any element which can give me the equivalent of tiles:insert...
<definition name="myapp.tile.base_page_body">
Insert classicLayout.def with the content area overridden with defination myapp.tile.basebody.And supply content and title key to myapp.tile.basebody
</definition>
Is this possible in tiles or I am just being overabbitious?
regards,
Shirish
-----Original Message-----
From: Tim Shadel [mailto:tim@zserve.com]
Sent: Tuesday, May 13, 2003 5:18 PM
To: struts-user@jakarta.apache.org
Subject: Re: Cleaner way of tiling?
I'm not so sure this is needed. It seems that this is all about
reducing your total XML by 2 lines per page, right? (4 lines for a
definition, vs. 2 lines in your proposed forward) All with the claim
that with 50,000 pages this saves on config file sizes (100,000 lines).
As an initial size cut in your example code you could use both the
extends and path properties on the second definition, since it uses the
same header, etc.
<definition name="portal.default"
path="/layouts/defaultLayout.jsp">
<put name="header" value="/view/header1.jsp"/>
<put name="sidebar" value="/view/defaultSideBar.jsp"/>
<put name="content" value="/view/defaultContent.jsp"/>
<put name="footer" value="/view/defaultFooter.jsp"/>
</definition>
<definition name="portal.sometimes"
path="/layouts/someTimesLayout.jsp"
extends="portal.default"/>
Secondly, I think you'll find fairly quickly that you'll need more
flexibility than your "forward" design gives. We have a large site
that's partially converted to Tiles, and that portion is a significant
number of pages. We use nested templates that allow us to customize
portions of each page, and also reuse many Tiles definitions among
different families of pages, in addition to having all the families rely
on base templates (header, nav, footer, content). The simple
configuration you suggest may allow you to modify simple tiles that rely
only on a base definition, but in an "enterprise" situation like you
suggest you need I think you'll find a need for a bit more complexity
and flexibility.
The nested tiles approach is a bit more complex, but allows us to reuse
many definitions. While we still need to have some definitions for each
page, splitting the config files up into modules and using James Holmes'
Struts Console makes this manageable. I can't really imagine developing
an enterprise-size site without multiple config files and modules. We
split our struts-config, tiles-defs, and validation.xml files up -
sharing global versions of each among modules, and isolating the
specifics in their own file. The file sizes are manageable and
understandable, the configurations are flexible, and we're able to
accomplish everything we need with them.
IMHO, your proposal seems to solve one problem, but also seems to have
limited application and flexibility. I may be missing some of the the
reasoning behind it, so you're welcome to disagree. I just don't see a
need for it at this time. FWIW, that's my take.
Tim
Bailey, Shane wrote:
>
> The way I showed I doing it (other than my proposed way) doesn't need
> multiple JSPs just multiple definitions. I am trying to get rid multiple
> Definitions which should be reused.
>
> I want to do this because this is supposed to be Enterprise software. Can
> you imagine having a portal with 50000 web pages and having to describe them
> all in a tiles-def.xml file? It is bad enough that struts-config.xml HAS TO
> (I understand why, of course) have all those mappings. I am just trying to
> cut down on config file sizes. The tiles config would be tiny with my
> proposal and the struts-config only a little larger.
>
> Maybe you have something in mentioning that I could extend the tiles
> processing, though.
>
>
>
> -----Original Message-----
> From: Mike Jasnowski [mailto:mjasnows@bea.com]
> Sent: Monday, May 12, 2003 3:55 PM
> To: Struts Users Mailing List
> Subject: RE: Cleaner way of tiling?
>
> Have you looked at the "controller" feature of Tiles? It enables you to
> specify a class, or URL that can be invoked before a Tile is inserted. This
> controller can specify the data for each view. The controller can be
> specified on a tile defintion or individual tile. Then you can have a set
> of core JSP's for your single layout definition instead of having multiple
> JSP's for each view.
>
> -----Original Message-----
> From: Bailey, Shane [mailto:SHANE.C.BAILEY@saic.com]
> Sent: Monday, May 12, 2003 3:29 PM
> To: struts-user@jakarta.apache.org
> Subject: Cleaner way of tiling?
>
>
>
>
> Unless I am missing something it seems like the best way to use tiles is to
> have a tiles definition for every single view page.
>
>
>
> I was hoping that I would have do is have a definition for each type of
> page. Then dynamically you could set up a view page.
>
>
>
> This is something I would be willing to write if it is possible without
> major disruption to the current architecture:
>
>
>
> <tiles-definitions>
>
> <definition name="portal.default"
> path="/layouts/defaultLayout.jsp">
>
> <put name="header" value="/view/header1.jsp" />
>
> <put name="sidebar" value="/view/defaultSideBar.jsp"
> />
>
> <put name="content" value="/view/defaultContent.jsp"
> />
>
> <put name="footer" value="/view/defaultFooter.jsp"
> />
>
> </definition>
>
> <definition name="portal.sometimes"
> path="/layouts/someTimesLayout.jsp">
>
> <put name="header" value="/view/header1.jsp" />
>
> <put name="content" value="/view/defaultContent.jsp"
> />
>
> <put name="footer" value="/view/defaultFooter.jsp"
> />
>
> </definition>
>
> </tiles-definitions>
>
>
>
> Then you could do this:
>
>
>
> <action path="/insertEmployee"
> type="com.test.InsertEmployeeAction"
> name="employeeForm"
> scope="request"
> validate="false"
> >
> <forward name="success" path="portal.default" >
> <set-property property="content"
> value="empInsertContent.jsp" />
> <set-property property="sidebar"
> value="empActionsSideBar.jsp" />
> <!-The header and footer would use the ones specified in the
> original definition!! -->
> </forward>
> </action>
>
>
> Instead of doing this:
>
>
> <definition name="portal.insertEmployee"
> extends="portal.default" >
>
> <put name="sidebar"
> value="/view/empActionsSideBar.jsp" />
>
> <put name="content"
> value="/view/empInsertContent.jsp" />
>
> </definition>
>
>
> and again for the next page and again for the next page...
>
>
> Does this make sense?
> Too hard to do?
>
> I would like to work on this but I would need a little help.
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: tiles defination nesting question..
Posted by Tim Shadel <ti...@zserve.com>.
I think I follow you. See if this setup works for you. (Sorry it's all
XML, and not much prose). I've done stuff similar to this, but the
example here is just typed off the top of my head. So the XML probably
isn't perfect, but the idea should be correct.
--Tim
<!-- FIRST: Define some generic templates -->
<!-- define a base layout for all pages -->
<definition name="classicLayout.def"
path="/WEB-INF/jsp/tiles/layouts/base_template.jsp">
<put name="header"
value="/WEB-INF/jsp/tiles/header.jsp" />
<put name="navigation"
value="/WEB-INF/jsp/tiles/sidebar.jsp" />
<put name="content"
value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
<put name="footer"
value="/WEB-INF/jsp/tiles/footer.jsp" />
</definition>
<!-- define a base layout for all content areas
to be used within the layout above -->
<definition name="myapp.tile.basebody"
path="/WEB-INF/jsp/tiles/layouts/base_body_template.jsp">
<put name="content"
value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
<put name="title_key"
value="blank_title"/>
</definition>
<!-- NOW: Assemble your generic pieces to define a specific page -->
<!-- Page 1 should look like all pages, and use the base layout,
but it's content uses another template, so go get that
custom definition and place it in the content area. -->
<definition name="myapp.page1"
extends="classicLayout.def">
<put name="content"
value="myapp.page1.content"
type="definition"/>
</definition>
<!-- For page 1's content, use the content layout, and then
add the specific parameters for page 1. -->
<definition name="myapp.page1.content"
extends="myapp.tile.basebody">
<put name="content"
value="/path/to/my/custom/jsp">
<put name="title_key"
value="My Application - Page 1">
</definition>
shirishchandra.sakhare@ubs.com wrote:
> Hi All,
> Can we compose a tiles defination using two other tiles definations in a tiles-def.xml file?
>
> I have a generic defination(Classic layout..header,footer,menu and content area),called classicLayout.def.
> ***********************
> <snippet-from-tiles-defs.xml>
>
> <definition name=lassicLayout.def" path="/WEB-INF/jsp/tiles/layouts/base_template.jsp">
> <put name=eader" value="/WEB-INF/jsp/tiles/header.jsp" />
> <put name=avigation" value="/WEB-INF/jsp/tiles/sidebar.jsp" />
> <put name=ontent" value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
> <put name=ooter" value="/WEB-INF/jsp/tiles/footer.jsp" />
> </definition>
>
> </snippet-from-tiles-defs.xml>
> ***********************
>
> And then for all the pages I have same elements at top of content area..(Title for functionality and then heml:erros tag..)So what i have done is defined another defination only for the content area.It can take the header and content to be included.(lets call it basecontent.def)
>
> ***********************
> <snippet-from-tiles-defs.xml>
> <!-- Defines a template for contet portion of page which contains header and error tag.Most common use as content portion of equate.tile.basedefination-->
> <definition name=yapp.tile.basebody" path="/WEB-INF/jsp/tiles/layouts/base_body_template.jsp">
> <put name=ontent" value="/WEB-INF/jsp/tiles/empty_body.jsp"/>
> </definition>
> </snippet-from-tiles-defs.xml>
> ***********************
>
>
> The jsp base_body_template.jsp looks like this...
> ******************************
> <%@ taglib uri=WEB-INF/equate.tld" prefix="equate" %>
> <%@ taglib uri=truts-tiles" prefix="tiles" %>
>
> <--! make available all attributes of defination in page scope-->
> <tiles:importAttribute name=itle_key" ignore="true"/>
> <%String key=tle_key; %>
>
> <% if(key !=ull){
> %>
> <div class=itleBox"><myapptag:message key="<%=key%>"/></div>
> <%
> }
> %>
>
> <equate:errors/>
>
> <tiles:insert attribute=ontent" />
> ********************************
>
>
> Now I want to create a third defination which says that take the classic layout definaton(classicLayout.def).And in that defination, insert the basecontent.def for content area.But when using xml file to define this, i dont see any element which can give me the equivalent of tiles:insert...
>
>
> <definition name=yapp.tile.base_page_body">
> Insert classicLayout.def with the content area overridden with defination myapp.tile.basebody.And supply content and title key to myapp.tile.basebody
> </definition>
>
>
> Is this possible in tiles or I am just being overabbitious?
>
> regards,
> Shirish
>
>
> -----Original Message-----
> From: Tim Shadel [mailto:tim@zserve.com]
> Sent: Tuesday, May 13, 2003 5:18 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Cleaner way of tiling?
>
>
> I'm not so sure this is needed. It seems that this is all about
> reducing your total XML by 2 lines per page, right? (4 lines for a
> definition, vs. 2 lines in your proposed forward) All with the claim
> that with 50,000 pages this saves on config file sizes (100,000 lines).
>
> As an initial size cut in your example code you could use both the
> extends and path properties on the second definition, since it uses the
> same header, etc.
>
> <definition name=ortal.default"
> path=layouts/defaultLayout.jsp">
> <put name=eader" value="/view/header1.jsp"/>
> <put name=idebar" value="/view/defaultSideBar.jsp"/>
> <put name=ontent" value="/view/defaultContent.jsp"/>
> <put name=ooter" value="/view/defaultFooter.jsp"/>
> </definition>
> <definition name=ortal.sometimes"
> path=layouts/someTimesLayout.jsp"
> extends=ortal.default"/>
>
> Secondly, I think you'll find fairly quickly that you'll need more
> flexibility than your "forward" design gives. We have a large site
> that's partially converted to Tiles, and that portion is a significant
> number of pages. We use nested templates that allow us to customize
> portions of each page, and also reuse many Tiles definitions among
> different families of pages, in addition to having all the families rely
> on base templates (header, nav, footer, content). The simple
> configuration you suggest may allow you to modify simple tiles that rely
> only on a base definition, but in an "enterprise" situation like you
> suggest you need I think you'll find a need for a bit more complexity
> and flexibility.
>
> The nested tiles approach is a bit more complex, but allows us to reuse
> many definitions. While we still need to have some definitions for each
> page, splitting the config files up into modules and using James Holmes'
> Struts Console makes this manageable. I can't really imagine developing
> an enterprise-size site without multiple config files and modules. We
> split our struts-config, tiles-defs, and validation.xml files up -
> sharing global versions of each among modules, and isolating the
> specifics in their own file. The file sizes are manageable and
> understandable, the configurations are flexible, and we're able to
> accomplish everything we need with them.
>
> IMHO, your proposal seems to solve one problem, but also seems to have
> limited application and flexibility. I may be missing some of the the
> reasoning behind it, so you're welcome to disagree. I just don't see a
> need for it at this time. FWIW, that's my take.
>
> Tim
>
>
> Bailey, Shane wrote:
>
>>The way I showed I doing it (other than my proposed way) doesn't need
>>multiple JSPs just multiple definitions. I am trying to get rid multiple
>>Definitions which should be reused.
>>
>>I want to do this because this is supposed to be Enterprise software. Can
>>you imagine having a portal with 50000 web pages and having to describe them
>>all in a tiles-def.xml file? It is bad enough that struts-config.xml HAS TO
>>(I understand why, of course) have all those mappings. I am just trying to
>>cut down on config file sizes. The tiles config would be tiny with my
>>proposal and the struts-config only a little larger.
>>
>>Maybe you have something in mentioning that I could extend the tiles
>>processing, though.
>>
>>
>>
>>-----Original Message-----
>>From: Mike Jasnowski [mailto:mjasnows@bea.com]
>>Sent: Monday, May 12, 2003 3:55 PM
>>To: Struts Users Mailing List
>>Subject: RE: Cleaner way of tiling?
>>
>>Have you looked at the "controller" feature of Tiles? It enables you to
>>specify a class, or URL that can be invoked before a Tile is inserted. This
>>controller can specify the data for each view. The controller can be
>>specified on a tile defintion or individual tile. Then you can have a set
>>of core JSP's for your single layout definition instead of having multiple
>>JSP's for each view.
>>
>>-----Original Message-----
>>From: Bailey, Shane [mailto:SHANE.C.BAILEY@saic.com]
>>Sent: Monday, May 12, 2003 3:29 PM
>>To: struts-user@jakarta.apache.org
>>Subject: Cleaner way of tiling?
>>
>>
>>
>>
>>Unless I am missing something it seems like the best way to use tiles is to
>>have a tiles definition for every single view page.
>>
>>
>>
>>I was hoping that I would have do is have a definition for each type of
>>page. Then dynamically you could set up a view page.
>>
>>
>>
>>This is something I would be willing to write if it is possible without
>>major disruption to the current architecture:
>>
>>
>>
>><tiles-definitions>
>>
>> <definition name=ortal.default"
>>path=layouts/defaultLayout.jsp">
>>
>> <put name=eader" value="/view/header1.jsp" />
>>
>> <put name=idebar" value="/view/defaultSideBar.jsp"
>>/>
>>
>> <put name=ontent" value="/view/defaultContent.jsp"
>>/>
>>
>> <put name=ooter" value="/view/defaultFooter.jsp"
>>/>
>>
>> </definition>
>>
>> <definition name=ortal.sometimes"
>>path=layouts/someTimesLayout.jsp">
>>
>> <put name=eader" value="/view/header1.jsp" />
>>
>> <put name=ontent" value="/view/defaultContent.jsp"
>>/>
>>
>> <put name=ooter" value="/view/defaultFooter.jsp"
>>/>
>>
>> </definition>
>>
>></tiles-definitions>
>>
>>
>>
>>Then you could do this:
>>
>>
>>
>><action path=insertEmployee"
>> type=om.test.InsertEmployeeAction"
>> name=mployeeForm"
>> scope=equest"
>> validate=alse"
>> >
>> <forward name=uccess" path="portal.default" >
>> <set-property property=ontent"
>>value=mpInsertContent.jsp" />
>> <set-property property=idebar"
>>value=mpActionsSideBar.jsp" />
>> <!-The header and footer would use the ones specified in the
>>original definition!! -->
>> </forward>
>> </action>
>>
>>
>>Instead of doing this:
>>
>>
>> <definition name=ortal.insertEmployee"
>>extends=ortal.default" >
>>
>> <put name=idebar"
>>value=view/empActionsSideBar.jsp" />
>>
>> <put name=ontent"
>>value=view/empInsertContent.jsp" />
>>
>> </definition>
>>
>>
>> and again for the next page and again for the next page...
>>
>>
>>Does this make sense?
>>Too hard to do?
>>
>>I would like to work on this but I would need a little help.
>>
>>
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org