You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Chris Pratt <th...@gmail.com> on 2006/10/24 19:20:04 UTC
Too many moving parts in Tiles
I'm wondering if I'm doing something wrong, (or at least not using the "Best
Practices"). Because my Tiles site has a LOT of moving parts, way more than
if I didn't use this simplifying technology at all. First I have to create
an essentially empty file for each page that uses Tiles, something like:
<%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-el"%>
<tiles:insert definition="login.pane"/>
Since our site always has a header (with a title), footer, and body section,
I defined a main layout with those sections and defined it in tiles-def.xmlas:
<definition name="site.layout" path="/site-layout.jsp">
<put name="title" value="site.layout.title"/>
<put name="pagetitle" value="passion"/>
<put name="header" value="/tiles/header.jsp"/>
<put name="body" value="/tiles/empty.jsp"/>
<put name="footer" value="/tiles/footer.jsp"/>
<put name="init" type="string">
/**
* Page Level Initialization
*/
function init () {
} //init
</put>
<putList name="styles">
</putList>
<putList name="scripts">
<add type="string" value="javascript/util.js"/>
</putList>
</definition>
<definition name="main.index" extends="site.layout">
<put name="header" value="/tiles/index-header.jsp"/>
<put name="body" value="/tiles/index-body.jsp"/>
<put name="footer" value="/tiles/index-footer.jsp"/>
</definition>
Then since 90% of our files are separated into a blue section (with
breadcrumbs) at the top of the page and a white section at the bottom, I
extended the main layout definition to add those tiles. But to extend a
tile it apparently takes two definitions (which doesn't make any sense to
me):
<definition name="default.pane" extends="site.layout">
<put name="body" value="default.layout" type="definition"/>
</definition>
<definition name="default.layout" path="default-layout.jsp">
<put name="bluearea" value="/tiles/blank.jsp" type="page"/>
<put name="whitearea" value="/tiles/blank.jsp" type="page"/>
<putList name="breadcrumbs">
<add value="/|head.home" type="string"/>
</putList>
</definition>
And since our site is internationalized we have externalized text in
resources as well as internationalized tiles_defs_fr.xml files. It seems
like Tiles is making flow and maintainability harder not easier. Is there a
best practice document somewhere that defines how to use this technology to
make life easier rather than just making more work?
(*Chris*)
Re: Too many moving parts in Tiles
Posted by Antonio Petrelli <ap...@apache.org>.
Greg Reddin ha scritto:
> We've had some discussions on the dev list about restructuring the
> tags in Tiles 2. The problem is that the <tiles:insert> tag means
> multiple things. In some cases it means "insert this definition here"
> (like your example above).
Chris, see also this JIRA issue:
http://issues.apache.org/struts/browse/SB-55
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Too many moving parts in Tiles
Posted by Greg Reddin <gr...@apache.org>.
On Oct 25, 2006, at 6:01 PM, Chris Pratt wrote:
> Greg, to answer your question, "how do I think this should work?" One
> improvement I can think of would be to allow this type of
> construct. In the
> tiles-defs.xml, specify a definition like:
[snip]
> Then allow inserting, referencing and populating in one fell swoop,
> something similar to:
>
> <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> el"%>
> <tiles:insert definition="site.layout">
> <put name="header" value="/tiles/index-header.jsp"/>
> <put name="body" value="/tiles/index-body.jsp"/>
> <put name="footer" value="/tiles/index-footer.jsp"/>
> </tiles:insert>
>
> which right now ignores all the puts in the body of the insert and
> just
> inserts the definition. This would allow you to separate the reusable
> definitions from the single use pages.
Thanks, that helps a lot. I think there's a lot of people out there
who would like it to work this way. We've had some discussions on
the dev list about restructuring the tags in Tiles 2. The problem is
that the <tiles:insert> tag means multiple things. In some cases it
means "insert this definition here" (like your example above). In
other cases it assumes you are "inside" a definition template and it
means "insert the specified attribute here". I can see what you mean
about trying to insert a definition on the fly instead of defining it
in the XML file. Have you tried using the <tiles:definition> tag?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Too many moving parts in Tiles
Posted by Chris Pratt <th...@gmail.com>.
Greg, to answer your question, "how do I think this should work?" One
improvement I can think of would be to allow this type of construct. In the
tiles-defs.xml, specify a definition like:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles
Configuration 1.1//EN" "http://struts.apache.org/dtds/tiles-config_1_1.dtd">
<tiles-definitions>
<!-- Base Layout -->
<definition name="site.layout" path="/layout.jsp">
<put name="title" value="site.layout.title"/>
<put name="pagetitle" value="passion"/>
<put name="header" value="/tiles/header.jsp"/>
<put name="body" value="/tiles/empty.jsp"/>
<put name="footer" value="/tiles/footer.jsp"/>
<put name="init" type="string">
/**
* Page Level Initialization
*/
function init () {
} //init
</put>
<putList name="styles">
</putList>
<putList name="scripts">
<add value="javascript/util.js" type="string"/>
</putList>
</definition>
</tiles-definitions>
Then allow inserting, referencing and populating in one fell swoop,
something similar to:
<%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-el"%>
<tiles:insert definition="site.layout">
<put name="header" value="/tiles/index-header.jsp"/>
<put name="body" value="/tiles/index-body.jsp"/>
<put name="footer" value="/tiles/index-footer.jsp"/>
</tiles:insert>
which right now ignores all the puts in the body of the insert and just
inserts the definition. This would allow you to separate the reusable
definitions from the single use pages.
(*Chris*)
On 10/24/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
>
> > First I have to create
> > an essentially empty file for each page that uses Tiles, something
> > like:
> >
> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> > el"%>
> > <tiles:insert definition="login.pane"/>
>
> First off, I'm assuming you're using Tiles 2? That may affect the
> way we answer the rest of your questions.
>
> This is a drawback to using Tiles in standalone mode. Tiles is meant
> to be inserted into the view layer of an MVC application. It is
> meant to interface with the controller component of an MVC
> framework. So, if you're using Struts or JSF, you'd configure your
> controller layer to forward requests to Tiles. Instead of a 2-line
> JSP page along with a Tile definition and associated pages for every
> "page" you'd have 2 lines of configuration in your controller layer
> along with the Tiles components for every page. But in standalone
> mode you don't have a front controller so your intermediate JSP page
> becomes the front controller. In my current project I'm using
> Facelets. I'd like to see Tiles implement a feature of Facelets in
> which the "page" calls the template. Tiles works the other way
> around. In Tiles you have to define a definition that references
> both the template and the page content. In Facelets you invoke a
> page that, in turn, pulls in a template.
>
> But Tiles is currently missing this feature. Maybe you should
> consider including a controller in your app to avoid this problem.
> Currently, there is no Struts 1.x support for Tiles 2, but there is
> Struts 2 and JSF (by way of Shale) support. Note that I haven't used
> either in an application yet.
>
> > Then since 90% of our files are separated into a blue section (with
> > breadcrumbs) at the top of the page and a white section at the
> > bottom, I
> > extended the main layout definition to add those tiles. But to
> > extend a
> > tile it apparently takes two definitions (which doesn't make any
> > sense to
> > me):
> >
> > <definition name="default.pane" extends="site.layout">
> > <put name="body" value="default.layout" type="definition"/>
> > </definition>
> >
> > <definition name="default.layout" path="default-layout.jsp">
> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
> > <putList name="breadcrumbs">
> > <add value="/|head.home" type="string"/>
> > </putList>
> > </definition>
>
> The above defines the frame of your template, but you don't have to
> provide 2 defs for every page do you? For example, for a "foobar"
> page you only need the following (plus the intermediate JSP page),
> correct?
>
> <definition name="foobar" extends="default.layout">
> <put name="bluearea" value="mybluearea.jsp"/>
> <put name="whitearea" value="mywhitearea.jsp"/>
> </definition>
>
> Or have I missed something?
>
> I've heard talk of nested definitions whereby maybe you could combine
> default.pane and default.layout into one, but I'm not sure if it
> works or if it would be a best practice. It might depend on who you
> ask :-) The fact that you can extend definitions is a good thing,
> IMO, but you can only take the inheritance paradigm so far before it
> breaks down when dealing with XML-based definitions.
>
> > And since our site is internationalized we have externalized text in
> > resources as well as internationalized tiles_defs_fr.xml files. It
> > seems
> > like Tiles is making flow and maintainability harder not easier.
>
> To this point, in some cases, you're probably correct. It would be
> helpful if you would think for a minute about how you might "like" it
> to work. If you can post some example defs and pages that would
> represent your ideal environment we might be able to modify Tiles to
> suit. For example:
>
> * What would be your alternative to using the intermediate JSP?
> * What would be your alternative to using 2 extension defs to build
> 90% of your pages? (I know the answer is "one" def, but what would
> it look like?)
>
> With Tiles 2, we're still in development so, pretty much anything goes.
>
> > Is there a
> > best practice document somewhere that defines how to use this
> > technology to
> > make life easier rather than just making more work?
>
> Well, the doc is in progress. This is the best we can provide right
> now:
>
> http://struts.apache.org/struts-sandbox/tiles/index.html
>
> I think we have some best practices in mind, we just haven't had a
> chance to get them into the official docs yet.
>
> Thanks,
> Greg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Too many moving parts in Tiles
Posted by Laurie Harper <la...@holoweb.net>.
All I can tell you is I prefer not to have 2-line JSPs, that
Tiles+Struts supports putting the equivalent definitions into
tiles-defs.xml instead and pointing an action at the appropriate
definition, and that I've done it that way in every Struts app I've ever
built using Tiles.
Here's an example from a production app:
<action path="/pages/home"
type="org.apache.struts.actions.ForwardAction"
parameter="/tiles.home.index"/>
where '/tiles.home.index' is the name of a definition in tiles-defs.xml
<definition name="/tiles.home.index" extends="/tiles.home.layout">
<put name="content" value="/pages/home/index.jsp"/>
</definition>
<definition name="/tiles.home.layout" extends="/tiles.layout">
<put name="title" value="PAGE TITLE"/>
<put name="menu" value="/pages/home/menu.jsp"/>
</definition>
<definition name="/tiles.layout" path="/tiles/layout.jsp">
<put name="title" value="PAGE TITLE"/>
<put name="menu" value="MENU"/>
<put name="content" value="CONTENT"/>
</definition>
Greg's simplified action mapping formulation should work equally well,
at least in recent Struts versions:
<action path="/pages/home" forward="/tiles.home.index"/>
HTH,
L.
Chris Pratt wrote:
> In fact the Apache Tiles Web site example (
> http://struts.apache.org/1.x/struts-tiles/examples.html right above the
> header "Specify Attribute Types") seems to be promoting the two line
> file as
> the right way to do things? I'm very confused... Doesn't anyone use
> Tiles?
> (*Chris*)
>
> On 10/25/06, Chris Pratt <th...@gmail.com> wrote:
>>
>> Hmmm, I can't get that working can anyone point me at a working example?
>> All the examples I can find are extremely simple and don't use nested
>> tiles.
>> (*Chris*)
>>
>> On 10/25/06, Laurie Harper <la...@holoweb.net> wrote:
>> >
>> > Chris Pratt wrote:
>> > > Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles
>> > > integrated
>> > > into Struts 1.2.9. I've tried using the ForwardAction to forward
>> > something
>> > > like:
>> > >
>> > > <action path="/loginPage.jsp" parameter="login.layout" type="
>> > > org.apache.struts.actions.ForwardAction"/>
>> > >
>> > > But it doesn't work, it just returns 404's.
>> >
>> > You probably want something like
>> >
>> > <action path=".tile.name" ...
>> >
>> > where .tile.name is the name of a definition in your tiles-defs.xml.
>> You
>> > definitely don't need the 2-line JSP when using Tiles with Struts like
>> > this.
>> >
>> > L.
>> >
>> >
>> > > As far as 2 definitions per page, I've been told by others on the
>> list
>> > that
>> > > because you can only define variables at the first level (or
>> something
>> > like
>> > > that) that you have to separate the layout from the definition into
>> > two
>> > > definitions. It seems very kludgy to me, which is why I'm asking
>> > here. I
>> > > agree that the ability to nest and extend Tiles is an excellent idea,
>> > > but if
>> > > this is the "best practice" approach, it leaves a lot to be desired.
>> > >
>> > > I've tried implementing it the way I'd like it to work, and with help
>> > from
>> > > people on the list, this was the only way I could get it to work, so
>> > my
>> > > wishes are a bit moot at this point.
>> > >
>> > > I'm just trying to get a handle on this "simplifying" technology and
>> > make
>> > > sure I'm not making things harder than they should be. If anyone can
>> > point
>> > > to a simpler solution (using Tiles and Struts, please refrain from
>> > > suggesting "switch to a completely different package"), I'd be very
>> > > grateful.
>> > > (*Chris*)
>> > >
>> > > On 10/24/06, Greg Reddin <greddin@apache.org > wrote:
>> > >>
>> > >>
>> > >> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
>> > >>
>> > >> > First I have to create
>> > >> > an essentially empty file for each page that uses Tiles, something
>> > >> > like:
>> > >> >
>> > >> > <%@ taglib prefix="tiles"
>> uri="http://struts.apache.org/tags-tiles-
>> > >> > el"%>
>> > >> > <tiles:insert definition="login.pane"/>
>> > >>
>> > >> First off, I'm assuming you're using Tiles 2? That may affect the
>> > >> way we answer the rest of your questions.
>> > >>
>> > >> This is a drawback to using Tiles in standalone mode. Tiles is
>> meant
>> > >> to be inserted into the view layer of an MVC application. It is
>> > >> meant to interface with the controller component of an MVC
>> > >> framework. So, if you're using Struts or JSF, you'd configure your
>> > >> controller layer to forward requests to Tiles. Instead of a 2-line
>> > >> JSP page along with a Tile definition and associated pages for every
>> > >> "page" you'd have 2 lines of configuration in your controller layer
>> > >> along with the Tiles components for every page. But in standalone
>> > >> mode you don't have a front controller so your intermediate JSP page
>> > >> becomes the front controller. In my current project I'm using
>> > >> Facelets. I'd like to see Tiles implement a feature of Facelets in
>> > >> which the "page" calls the template. Tiles works the other way
>> > >> around. In Tiles you have to define a definition that references
>> > >> both the template and the page content. In Facelets you invoke a
>> > >> page that, in turn, pulls in a template.
>> > >>
>> > >> But Tiles is currently missing this feature. Maybe you should
>> > >> consider including a controller in your app to avoid this problem.
>> > >> Currently, there is no Struts 1.x support for Tiles 2, but there is
>> > >> Struts 2 and JSF (by way of Shale) support. Note that I haven't
>> used
>> > >> either in an application yet.
>> > >>
>> > >> > Then since 90% of our files are separated into a blue section
>> (with
>> >
>> > >> > breadcrumbs) at the top of the page and a white section at the
>> > >> > bottom, I
>> > >> > extended the main layout definition to add those tiles. But to
>> > >> > extend a
>> > >> > tile it apparently takes two definitions (which doesn't make any
>> > >> > sense to
>> > >> > me):
>> > >> >
>> > >> > <definition name="default.pane" extends="site.layout">
>> > >> > <put name="body" value=" default.layout" type="definition"/>
>> > >> > </definition>
>> > >> >
>> > >> > <definition name="default.layout" path="default-layout.jsp">
>> > >> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
>> > >> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
>> > >> > <putList name="breadcrumbs">
>> > >> > <add value="/|head.home" type="string"/>
>> > >> > </putList>
>> > >> > </definition>
>> > >>
>> > >> The above defines the frame of your template, but you don't have to
>> > >> provide 2 defs for every page do you? For example, for a "foobar"
>> > >> page you only need the following (plus the intermediate JSP page),
>> > >> correct?
>> > >>
>> > >> <definition name="foobar" extends="default.layout">
>> > >> <put name="bluearea" value=" mybluearea.jsp"/>
>> > >> <put name="whitearea" value="mywhitearea.jsp"/>
>> > >> </definition>
>> > >>
>> > >> Or have I missed something?
>> > >>
>> > >> I've heard talk of nested definitions whereby maybe you could
>> combine
>> >
>> > >> default.pane and default.layout into one, but I'm not sure if it
>> > >> works or if it would be a best practice. It might depend on who you
>> > >> ask :-) The fact that you can extend definitions is a good thing,
>> > >> IMO, but you can only take the inheritance paradigm so far before it
>> > >> breaks down when dealing with XML-based definitions.
>> > >>
>> > >> > And since our site is internationalized we have externalized text
>> > in
>> > >> > resources as well as internationalized tiles_defs_fr.xml
>> files. It
>> > >> > seems
>> > >> > like Tiles is making flow and maintainability harder not easier.
>> > >>
>> > >> To this point, in some cases, you're probably correct. It would be
>> > >> helpful if you would think for a minute about how you might
>> "like" it
>> > >> to work. If you can post some example defs and pages that would
>> > >> represent your ideal environment we might be able to modify Tiles to
>> > >> suit. For example:
>> > >>
>> > >> * What would be your alternative to using the intermediate JSP?
>> > >> * What would be your alternative to using 2 extension defs to build
>> > >> 90% of your pages? (I know the answer is "one" def, but what would
>> > >> it look like?)
>> > >>
>> > >> With Tiles 2, we're still in development so, pretty much anything
>> > goes.
>> > >>
>> > >> > Is there a
>> > >> > best practice document somewhere that defines how to use this
>> > >> > technology to
>> > >> > make life easier rather than just making more work?
>> > >>
>> > >> Well, the doc is in progress. This is the best we can provide right
>> > >> now:
>> > >>
>> > >> http://struts.apache.org/struts-sandbox/tiles/index.html
>> > >>
>> > >> I think we have some best practices in mind, we just haven't had a
>> > >> chance to get them into the official docs yet.
>> > >>
>> > >> Thanks,
>> > >> Greg
>> > >>
>> > >>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> >
>> > >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > >> For additional commands, e-mail: user-help@struts.apache.org
>> > >>
>> > >>
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Too many moving parts in Tiles
Posted by Chris Pratt <th...@gmail.com>.
In fact the Apache Tiles Web site example (
http://struts.apache.org/1.x/struts-tiles/examples.html right above the
header "Specify Attribute Types") seems to be promoting the two line file as
the right way to do things? I'm very confused... Doesn't anyone use Tiles?
(*Chris*)
On 10/25/06, Chris Pratt <th...@gmail.com> wrote:
>
> Hmmm, I can't get that working can anyone point me at a working example?
> All the examples I can find are extremely simple and don't use nested tiles.
> (*Chris*)
>
> On 10/25/06, Laurie Harper <la...@holoweb.net> wrote:
> >
> > Chris Pratt wrote:
> > > Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles
> > > integrated
> > > into Struts 1.2.9. I've tried using the ForwardAction to forward
> > something
> > > like:
> > >
> > > <action path="/loginPage.jsp" parameter="login.layout" type="
> > > org.apache.struts.actions.ForwardAction"/>
> > >
> > > But it doesn't work, it just returns 404's.
> >
> > You probably want something like
> >
> > <action path=".tile.name" ...
> >
> > where .tile.name is the name of a definition in your tiles-defs.xml. You
> > definitely don't need the 2-line JSP when using Tiles with Struts like
> > this.
> >
> > L.
> >
> >
> > > As far as 2 definitions per page, I've been told by others on the list
> > that
> > > because you can only define variables at the first level (or something
> > like
> > > that) that you have to separate the layout from the definition into
> > two
> > > definitions. It seems very kludgy to me, which is why I'm asking
> > here. I
> > > agree that the ability to nest and extend Tiles is an excellent idea,
> > > but if
> > > this is the "best practice" approach, it leaves a lot to be desired.
> > >
> > > I've tried implementing it the way I'd like it to work, and with help
> > from
> > > people on the list, this was the only way I could get it to work, so
> > my
> > > wishes are a bit moot at this point.
> > >
> > > I'm just trying to get a handle on this "simplifying" technology and
> > make
> > > sure I'm not making things harder than they should be. If anyone can
> > point
> > > to a simpler solution (using Tiles and Struts, please refrain from
> > > suggesting "switch to a completely different package"), I'd be very
> > > grateful.
> > > (*Chris*)
> > >
> > > On 10/24/06, Greg Reddin <greddin@apache.org > wrote:
> > >>
> > >>
> > >> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
> > >>
> > >> > First I have to create
> > >> > an essentially empty file for each page that uses Tiles, something
> > >> > like:
> > >> >
> > >> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> > >> > el"%>
> > >> > <tiles:insert definition="login.pane"/>
> > >>
> > >> First off, I'm assuming you're using Tiles 2? That may affect the
> > >> way we answer the rest of your questions.
> > >>
> > >> This is a drawback to using Tiles in standalone mode. Tiles is meant
> > >> to be inserted into the view layer of an MVC application. It is
> > >> meant to interface with the controller component of an MVC
> > >> framework. So, if you're using Struts or JSF, you'd configure your
> > >> controller layer to forward requests to Tiles. Instead of a 2-line
> > >> JSP page along with a Tile definition and associated pages for every
> > >> "page" you'd have 2 lines of configuration in your controller layer
> > >> along with the Tiles components for every page. But in standalone
> > >> mode you don't have a front controller so your intermediate JSP page
> > >> becomes the front controller. In my current project I'm using
> > >> Facelets. I'd like to see Tiles implement a feature of Facelets in
> > >> which the "page" calls the template. Tiles works the other way
> > >> around. In Tiles you have to define a definition that references
> > >> both the template and the page content. In Facelets you invoke a
> > >> page that, in turn, pulls in a template.
> > >>
> > >> But Tiles is currently missing this feature. Maybe you should
> > >> consider including a controller in your app to avoid this problem.
> > >> Currently, there is no Struts 1.x support for Tiles 2, but there is
> > >> Struts 2 and JSF (by way of Shale) support. Note that I haven't used
> > >> either in an application yet.
> > >>
> > >> > Then since 90% of our files are separated into a blue section (with
> >
> > >> > breadcrumbs) at the top of the page and a white section at the
> > >> > bottom, I
> > >> > extended the main layout definition to add those tiles. But to
> > >> > extend a
> > >> > tile it apparently takes two definitions (which doesn't make any
> > >> > sense to
> > >> > me):
> > >> >
> > >> > <definition name="default.pane" extends="site.layout">
> > >> > <put name="body" value=" default.layout" type="definition"/>
> > >> > </definition>
> > >> >
> > >> > <definition name="default.layout" path="default-layout.jsp">
> > >> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
> > >> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
> > >> > <putList name="breadcrumbs">
> > >> > <add value="/|head.home" type="string"/>
> > >> > </putList>
> > >> > </definition>
> > >>
> > >> The above defines the frame of your template, but you don't have to
> > >> provide 2 defs for every page do you? For example, for a "foobar"
> > >> page you only need the following (plus the intermediate JSP page),
> > >> correct?
> > >>
> > >> <definition name="foobar" extends="default.layout">
> > >> <put name="bluearea" value=" mybluearea.jsp"/>
> > >> <put name="whitearea" value="mywhitearea.jsp"/>
> > >> </definition>
> > >>
> > >> Or have I missed something?
> > >>
> > >> I've heard talk of nested definitions whereby maybe you could combine
> >
> > >> default.pane and default.layout into one, but I'm not sure if it
> > >> works or if it would be a best practice. It might depend on who you
> > >> ask :-) The fact that you can extend definitions is a good thing,
> > >> IMO, but you can only take the inheritance paradigm so far before it
> > >> breaks down when dealing with XML-based definitions.
> > >>
> > >> > And since our site is internationalized we have externalized text
> > in
> > >> > resources as well as internationalized tiles_defs_fr.xml files. It
> > >> > seems
> > >> > like Tiles is making flow and maintainability harder not easier.
> > >>
> > >> To this point, in some cases, you're probably correct. It would be
> > >> helpful if you would think for a minute about how you might "like" it
> > >> to work. If you can post some example defs and pages that would
> > >> represent your ideal environment we might be able to modify Tiles to
> > >> suit. For example:
> > >>
> > >> * What would be your alternative to using the intermediate JSP?
> > >> * What would be your alternative to using 2 extension defs to build
> > >> 90% of your pages? (I know the answer is "one" def, but what would
> > >> it look like?)
> > >>
> > >> With Tiles 2, we're still in development so, pretty much anything
> > goes.
> > >>
> > >> > Is there a
> > >> > best practice document somewhere that defines how to use this
> > >> > technology to
> > >> > make life easier rather than just making more work?
> > >>
> > >> Well, the doc is in progress. This is the best we can provide right
> > >> now:
> > >>
> > >> http://struts.apache.org/struts-sandbox/tiles/index.html
> > >>
> > >> I think we have some best practices in mind, we just haven't had a
> > >> chance to get them into the official docs yet.
> > >>
> > >> Thanks,
> > >> Greg
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> >
> > >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail: user-help@struts.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
Re: Too many moving parts in Tiles
Posted by Chris Pratt <th...@gmail.com>.
Hmmm, I can't get that working can anyone point me at a working example?
All the examples I can find are extremely simple and don't use nested tiles.
(*Chris*)
On 10/25/06, Laurie Harper <la...@holoweb.net> wrote:
>
> Chris Pratt wrote:
> > Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles
> > integrated
> > into Struts 1.2.9. I've tried using the ForwardAction to forward
> something
> > like:
> >
> > <action path="/loginPage.jsp" parameter="login.layout" type="
> > org.apache.struts.actions.ForwardAction"/>
> >
> > But it doesn't work, it just returns 404's.
>
> You probably want something like
>
> <action path=".tile.name" ...
>
> where .tile.name is the name of a definition in your tiles-defs.xml. You
> definitely don't need the 2-line JSP when using Tiles with Struts like
> this.
>
> L.
>
>
> > As far as 2 definitions per page, I've been told by others on the list
> that
> > because you can only define variables at the first level (or something
> like
> > that) that you have to separate the layout from the definition into two
> > definitions. It seems very kludgy to me, which is why I'm asking
> here. I
> > agree that the ability to nest and extend Tiles is an excellent idea,
> > but if
> > this is the "best practice" approach, it leaves a lot to be desired.
> >
> > I've tried implementing it the way I'd like it to work, and with help
> from
> > people on the list, this was the only way I could get it to work, so my
> > wishes are a bit moot at this point.
> >
> > I'm just trying to get a handle on this "simplifying" technology and
> make
> > sure I'm not making things harder than they should be. If anyone can
> point
> > to a simpler solution (using Tiles and Struts, please refrain from
> > suggesting "switch to a completely different package"), I'd be very
> > grateful.
> > (*Chris*)
> >
> > On 10/24/06, Greg Reddin <gr...@apache.org> wrote:
> >>
> >>
> >> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
> >>
> >> > First I have to create
> >> > an essentially empty file for each page that uses Tiles, something
> >> > like:
> >> >
> >> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> >> > el"%>
> >> > <tiles:insert definition="login.pane"/>
> >>
> >> First off, I'm assuming you're using Tiles 2? That may affect the
> >> way we answer the rest of your questions.
> >>
> >> This is a drawback to using Tiles in standalone mode. Tiles is meant
> >> to be inserted into the view layer of an MVC application. It is
> >> meant to interface with the controller component of an MVC
> >> framework. So, if you're using Struts or JSF, you'd configure your
> >> controller layer to forward requests to Tiles. Instead of a 2-line
> >> JSP page along with a Tile definition and associated pages for every
> >> "page" you'd have 2 lines of configuration in your controller layer
> >> along with the Tiles components for every page. But in standalone
> >> mode you don't have a front controller so your intermediate JSP page
> >> becomes the front controller. In my current project I'm using
> >> Facelets. I'd like to see Tiles implement a feature of Facelets in
> >> which the "page" calls the template. Tiles works the other way
> >> around. In Tiles you have to define a definition that references
> >> both the template and the page content. In Facelets you invoke a
> >> page that, in turn, pulls in a template.
> >>
> >> But Tiles is currently missing this feature. Maybe you should
> >> consider including a controller in your app to avoid this problem.
> >> Currently, there is no Struts 1.x support for Tiles 2, but there is
> >> Struts 2 and JSF (by way of Shale) support. Note that I haven't used
> >> either in an application yet.
> >>
> >> > Then since 90% of our files are separated into a blue section (with
> >> > breadcrumbs) at the top of the page and a white section at the
> >> > bottom, I
> >> > extended the main layout definition to add those tiles. But to
> >> > extend a
> >> > tile it apparently takes two definitions (which doesn't make any
> >> > sense to
> >> > me):
> >> >
> >> > <definition name="default.pane" extends="site.layout">
> >> > <put name="body" value="default.layout" type="definition"/>
> >> > </definition>
> >> >
> >> > <definition name="default.layout" path="default-layout.jsp">
> >> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
> >> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
> >> > <putList name="breadcrumbs">
> >> > <add value="/|head.home" type="string"/>
> >> > </putList>
> >> > </definition>
> >>
> >> The above defines the frame of your template, but you don't have to
> >> provide 2 defs for every page do you? For example, for a "foobar"
> >> page you only need the following (plus the intermediate JSP page),
> >> correct?
> >>
> >> <definition name="foobar" extends="default.layout">
> >> <put name="bluearea" value="mybluearea.jsp"/>
> >> <put name="whitearea" value="mywhitearea.jsp"/>
> >> </definition>
> >>
> >> Or have I missed something?
> >>
> >> I've heard talk of nested definitions whereby maybe you could combine
> >> default.pane and default.layout into one, but I'm not sure if it
> >> works or if it would be a best practice. It might depend on who you
> >> ask :-) The fact that you can extend definitions is a good thing,
> >> IMO, but you can only take the inheritance paradigm so far before it
> >> breaks down when dealing with XML-based definitions.
> >>
> >> > And since our site is internationalized we have externalized text in
> >> > resources as well as internationalized tiles_defs_fr.xml files. It
> >> > seems
> >> > like Tiles is making flow and maintainability harder not easier.
> >>
> >> To this point, in some cases, you're probably correct. It would be
> >> helpful if you would think for a minute about how you might "like" it
> >> to work. If you can post some example defs and pages that would
> >> represent your ideal environment we might be able to modify Tiles to
> >> suit. For example:
> >>
> >> * What would be your alternative to using the intermediate JSP?
> >> * What would be your alternative to using 2 extension defs to build
> >> 90% of your pages? (I know the answer is "one" def, but what would
> >> it look like?)
> >>
> >> With Tiles 2, we're still in development so, pretty much anything goes.
> >>
> >> > Is there a
> >> > best practice document somewhere that defines how to use this
> >> > technology to
> >> > make life easier rather than just making more work?
> >>
> >> Well, the doc is in progress. This is the best we can provide right
> >> now:
> >>
> >> http://struts.apache.org/struts-sandbox/tiles/index.html
> >>
> >> I think we have some best practices in mind, we just haven't had a
> >> chance to get them into the official docs yet.
> >>
> >> Thanks,
> >> Greg
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Too many moving parts in Tiles
Posted by Greg Reddin <gr...@apache.org>.
On Oct 25, 2006, at 5:04 PM, Laurie Harper wrote:
> Chris Pratt wrote:
>> Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles
>> integrated
>> into Struts 1.2.9. I've tried using the ForwardAction to forward
>> something
>> like:
>> <action path="/loginPage.jsp" parameter="login.layout" type="
>> org.apache.struts.actions.ForwardAction"/>
>> But it doesn't work, it just returns 404's.
>
> You probably want something like
>
> <action path=".tile.name" ...
I think you actually want something like this:
<action path="/somepage" forward="tile.name"/>
The above assumes Struts 1.2.9 with the Tiles plugin installed. Of
course the path attribute is what you'd type into the browser and the
forward attribute is the tiles def.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Too many moving parts in Tiles
Posted by Laurie Harper <la...@holoweb.net>.
Chris Pratt wrote:
> Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles
> integrated
> into Struts 1.2.9. I've tried using the ForwardAction to forward something
> like:
>
> <action path="/loginPage.jsp" parameter="login.layout" type="
> org.apache.struts.actions.ForwardAction"/>
>
> But it doesn't work, it just returns 404's.
You probably want something like
<action path=".tile.name" ...
where .tile.name is the name of a definition in your tiles-defs.xml. You
definitely don't need the 2-line JSP when using Tiles with Struts like this.
L.
> As far as 2 definitions per page, I've been told by others on the list that
> because you can only define variables at the first level (or something like
> that) that you have to separate the layout from the definition into two
> definitions. It seems very kludgy to me, which is why I'm asking here. I
> agree that the ability to nest and extend Tiles is an excellent idea,
> but if
> this is the "best practice" approach, it leaves a lot to be desired.
>
> I've tried implementing it the way I'd like it to work, and with help from
> people on the list, this was the only way I could get it to work, so my
> wishes are a bit moot at this point.
>
> I'm just trying to get a handle on this "simplifying" technology and make
> sure I'm not making things harder than they should be. If anyone can point
> to a simpler solution (using Tiles and Struts, please refrain from
> suggesting "switch to a completely different package"), I'd be very
> grateful.
> (*Chris*)
>
> On 10/24/06, Greg Reddin <gr...@apache.org> wrote:
>>
>>
>> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
>>
>> > First I have to create
>> > an essentially empty file for each page that uses Tiles, something
>> > like:
>> >
>> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
>> > el"%>
>> > <tiles:insert definition="login.pane"/>
>>
>> First off, I'm assuming you're using Tiles 2? That may affect the
>> way we answer the rest of your questions.
>>
>> This is a drawback to using Tiles in standalone mode. Tiles is meant
>> to be inserted into the view layer of an MVC application. It is
>> meant to interface with the controller component of an MVC
>> framework. So, if you're using Struts or JSF, you'd configure your
>> controller layer to forward requests to Tiles. Instead of a 2-line
>> JSP page along with a Tile definition and associated pages for every
>> "page" you'd have 2 lines of configuration in your controller layer
>> along with the Tiles components for every page. But in standalone
>> mode you don't have a front controller so your intermediate JSP page
>> becomes the front controller. In my current project I'm using
>> Facelets. I'd like to see Tiles implement a feature of Facelets in
>> which the "page" calls the template. Tiles works the other way
>> around. In Tiles you have to define a definition that references
>> both the template and the page content. In Facelets you invoke a
>> page that, in turn, pulls in a template.
>>
>> But Tiles is currently missing this feature. Maybe you should
>> consider including a controller in your app to avoid this problem.
>> Currently, there is no Struts 1.x support for Tiles 2, but there is
>> Struts 2 and JSF (by way of Shale) support. Note that I haven't used
>> either in an application yet.
>>
>> > Then since 90% of our files are separated into a blue section (with
>> > breadcrumbs) at the top of the page and a white section at the
>> > bottom, I
>> > extended the main layout definition to add those tiles. But to
>> > extend a
>> > tile it apparently takes two definitions (which doesn't make any
>> > sense to
>> > me):
>> >
>> > <definition name="default.pane" extends="site.layout">
>> > <put name="body" value="default.layout" type="definition"/>
>> > </definition>
>> >
>> > <definition name="default.layout" path="default-layout.jsp">
>> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
>> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
>> > <putList name="breadcrumbs">
>> > <add value="/|head.home" type="string"/>
>> > </putList>
>> > </definition>
>>
>> The above defines the frame of your template, but you don't have to
>> provide 2 defs for every page do you? For example, for a "foobar"
>> page you only need the following (plus the intermediate JSP page),
>> correct?
>>
>> <definition name="foobar" extends="default.layout">
>> <put name="bluearea" value="mybluearea.jsp"/>
>> <put name="whitearea" value="mywhitearea.jsp"/>
>> </definition>
>>
>> Or have I missed something?
>>
>> I've heard talk of nested definitions whereby maybe you could combine
>> default.pane and default.layout into one, but I'm not sure if it
>> works or if it would be a best practice. It might depend on who you
>> ask :-) The fact that you can extend definitions is a good thing,
>> IMO, but you can only take the inheritance paradigm so far before it
>> breaks down when dealing with XML-based definitions.
>>
>> > And since our site is internationalized we have externalized text in
>> > resources as well as internationalized tiles_defs_fr.xml files. It
>> > seems
>> > like Tiles is making flow and maintainability harder not easier.
>>
>> To this point, in some cases, you're probably correct. It would be
>> helpful if you would think for a minute about how you might "like" it
>> to work. If you can post some example defs and pages that would
>> represent your ideal environment we might be able to modify Tiles to
>> suit. For example:
>>
>> * What would be your alternative to using the intermediate JSP?
>> * What would be your alternative to using 2 extension defs to build
>> 90% of your pages? (I know the answer is "one" def, but what would
>> it look like?)
>>
>> With Tiles 2, we're still in development so, pretty much anything goes.
>>
>> > Is there a
>> > best practice document somewhere that defines how to use this
>> > technology to
>> > make life easier rather than just making more work?
>>
>> Well, the doc is in progress. This is the best we can provide right
>> now:
>>
>> http://struts.apache.org/struts-sandbox/tiles/index.html
>>
>> I think we have some best practices in mind, we just haven't had a
>> chance to get them into the official docs yet.
>>
>> Thanks,
>> Greg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Too many moving parts in Tiles
Posted by Chris Pratt <th...@gmail.com>.
Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles integrated
into Struts 1.2.9. I've tried using the ForwardAction to forward something
like:
<action path="/loginPage.jsp" parameter="login.layout" type="
org.apache.struts.actions.ForwardAction"/>
But it doesn't work, it just returns 404's.
As far as 2 definitions per page, I've been told by others on the list that
because you can only define variables at the first level (or something like
that) that you have to separate the layout from the definition into two
definitions. It seems very kludgy to me, which is why I'm asking here. I
agree that the ability to nest and extend Tiles is an excellent idea, but if
this is the "best practice" approach, it leaves a lot to be desired.
I've tried implementing it the way I'd like it to work, and with help from
people on the list, this was the only way I could get it to work, so my
wishes are a bit moot at this point.
I'm just trying to get a handle on this "simplifying" technology and make
sure I'm not making things harder than they should be. If anyone can point
to a simpler solution (using Tiles and Struts, please refrain from
suggesting "switch to a completely different package"), I'd be very
grateful.
(*Chris*)
On 10/24/06, Greg Reddin <gr...@apache.org> wrote:
>
>
> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
>
> > First I have to create
> > an essentially empty file for each page that uses Tiles, something
> > like:
> >
> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> > el"%>
> > <tiles:insert definition="login.pane"/>
>
> First off, I'm assuming you're using Tiles 2? That may affect the
> way we answer the rest of your questions.
>
> This is a drawback to using Tiles in standalone mode. Tiles is meant
> to be inserted into the view layer of an MVC application. It is
> meant to interface with the controller component of an MVC
> framework. So, if you're using Struts or JSF, you'd configure your
> controller layer to forward requests to Tiles. Instead of a 2-line
> JSP page along with a Tile definition and associated pages for every
> "page" you'd have 2 lines of configuration in your controller layer
> along with the Tiles components for every page. But in standalone
> mode you don't have a front controller so your intermediate JSP page
> becomes the front controller. In my current project I'm using
> Facelets. I'd like to see Tiles implement a feature of Facelets in
> which the "page" calls the template. Tiles works the other way
> around. In Tiles you have to define a definition that references
> both the template and the page content. In Facelets you invoke a
> page that, in turn, pulls in a template.
>
> But Tiles is currently missing this feature. Maybe you should
> consider including a controller in your app to avoid this problem.
> Currently, there is no Struts 1.x support for Tiles 2, but there is
> Struts 2 and JSF (by way of Shale) support. Note that I haven't used
> either in an application yet.
>
> > Then since 90% of our files are separated into a blue section (with
> > breadcrumbs) at the top of the page and a white section at the
> > bottom, I
> > extended the main layout definition to add those tiles. But to
> > extend a
> > tile it apparently takes two definitions (which doesn't make any
> > sense to
> > me):
> >
> > <definition name="default.pane" extends="site.layout">
> > <put name="body" value="default.layout" type="definition"/>
> > </definition>
> >
> > <definition name="default.layout" path="default-layout.jsp">
> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
> > <putList name="breadcrumbs">
> > <add value="/|head.home" type="string"/>
> > </putList>
> > </definition>
>
> The above defines the frame of your template, but you don't have to
> provide 2 defs for every page do you? For example, for a "foobar"
> page you only need the following (plus the intermediate JSP page),
> correct?
>
> <definition name="foobar" extends="default.layout">
> <put name="bluearea" value="mybluearea.jsp"/>
> <put name="whitearea" value="mywhitearea.jsp"/>
> </definition>
>
> Or have I missed something?
>
> I've heard talk of nested definitions whereby maybe you could combine
> default.pane and default.layout into one, but I'm not sure if it
> works or if it would be a best practice. It might depend on who you
> ask :-) The fact that you can extend definitions is a good thing,
> IMO, but you can only take the inheritance paradigm so far before it
> breaks down when dealing with XML-based definitions.
>
> > And since our site is internationalized we have externalized text in
> > resources as well as internationalized tiles_defs_fr.xml files. It
> > seems
> > like Tiles is making flow and maintainability harder not easier.
>
> To this point, in some cases, you're probably correct. It would be
> helpful if you would think for a minute about how you might "like" it
> to work. If you can post some example defs and pages that would
> represent your ideal environment we might be able to modify Tiles to
> suit. For example:
>
> * What would be your alternative to using the intermediate JSP?
> * What would be your alternative to using 2 extension defs to build
> 90% of your pages? (I know the answer is "one" def, but what would
> it look like?)
>
> With Tiles 2, we're still in development so, pretty much anything goes.
>
> > Is there a
> > best practice document somewhere that defines how to use this
> > technology to
> > make life easier rather than just making more work?
>
> Well, the doc is in progress. This is the best we can provide right
> now:
>
> http://struts.apache.org/struts-sandbox/tiles/index.html
>
> I think we have some best practices in mind, we just haven't had a
> chance to get them into the official docs yet.
>
> Thanks,
> Greg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Too many moving parts in Tiles
Posted by Greg Reddin <gr...@apache.org>.
On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
> First I have to create
> an essentially empty file for each page that uses Tiles, something
> like:
>
> <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-
> el"%>
> <tiles:insert definition="login.pane"/>
First off, I'm assuming you're using Tiles 2? That may affect the
way we answer the rest of your questions.
This is a drawback to using Tiles in standalone mode. Tiles is meant
to be inserted into the view layer of an MVC application. It is
meant to interface with the controller component of an MVC
framework. So, if you're using Struts or JSF, you'd configure your
controller layer to forward requests to Tiles. Instead of a 2-line
JSP page along with a Tile definition and associated pages for every
"page" you'd have 2 lines of configuration in your controller layer
along with the Tiles components for every page. But in standalone
mode you don't have a front controller so your intermediate JSP page
becomes the front controller. In my current project I'm using
Facelets. I'd like to see Tiles implement a feature of Facelets in
which the "page" calls the template. Tiles works the other way
around. In Tiles you have to define a definition that references
both the template and the page content. In Facelets you invoke a
page that, in turn, pulls in a template.
But Tiles is currently missing this feature. Maybe you should
consider including a controller in your app to avoid this problem.
Currently, there is no Struts 1.x support for Tiles 2, but there is
Struts 2 and JSF (by way of Shale) support. Note that I haven't used
either in an application yet.
> Then since 90% of our files are separated into a blue section (with
> breadcrumbs) at the top of the page and a white section at the
> bottom, I
> extended the main layout definition to add those tiles. But to
> extend a
> tile it apparently takes two definitions (which doesn't make any
> sense to
> me):
>
> <definition name="default.pane" extends="site.layout">
> <put name="body" value="default.layout" type="definition"/>
> </definition>
>
> <definition name="default.layout" path="default-layout.jsp">
> <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
> <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
> <putList name="breadcrumbs">
> <add value="/|head.home" type="string"/>
> </putList>
> </definition>
The above defines the frame of your template, but you don't have to
provide 2 defs for every page do you? For example, for a "foobar"
page you only need the following (plus the intermediate JSP page),
correct?
<definition name="foobar" extends="default.layout">
<put name="bluearea" value="mybluearea.jsp"/>
<put name="whitearea" value="mywhitearea.jsp"/>
</definition>
Or have I missed something?
I've heard talk of nested definitions whereby maybe you could combine
default.pane and default.layout into one, but I'm not sure if it
works or if it would be a best practice. It might depend on who you
ask :-) The fact that you can extend definitions is a good thing,
IMO, but you can only take the inheritance paradigm so far before it
breaks down when dealing with XML-based definitions.
> And since our site is internationalized we have externalized text in
> resources as well as internationalized tiles_defs_fr.xml files. It
> seems
> like Tiles is making flow and maintainability harder not easier.
To this point, in some cases, you're probably correct. It would be
helpful if you would think for a minute about how you might "like" it
to work. If you can post some example defs and pages that would
represent your ideal environment we might be able to modify Tiles to
suit. For example:
* What would be your alternative to using the intermediate JSP?
* What would be your alternative to using 2 extension defs to build
90% of your pages? (I know the answer is "one" def, but what would
it look like?)
With Tiles 2, we're still in development so, pretty much anything goes.
> Is there a
> best practice document somewhere that defines how to use this
> technology to
> make life easier rather than just making more work?
Well, the doc is in progress. This is the best we can provide right
now:
http://struts.apache.org/struts-sandbox/tiles/index.html
I think we have some best practices in mind, we just haven't had a
chance to get them into the official docs yet.
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org