You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jim Crossley <jc...@ifleet.com> on 2002/02/19 21:39:27 UTC
Why don't tiles "cascade"?
Apparently it's not possible to access attributes of any tiles other
than your immediate "parent". IMHO, this restricts my ability to
partition my presentation code into simple, reusable chunks.
Here's a semi-practical example.
Consider this snippet from a definitions file...
<definition name="training" path="/layout.jsp">
<put name="content" value="/training.jsp"/>
<put name="title" value="Training"/>
</definition>
layout.jsp
-- CUT --
<tiles:insert path="/header.jsp"/>
<tiles:insert attribute="content"/>
<tiles:insert path="/footer.jsp"/>
-- CUT --
header.jsp
-- CUT --
<html>
<head>
<title><tiles:getAsString name="title"/></title>
</head>
<body>
-- CUT --
footer.jsp
-- CUT --
</body>
</html>
-- CUT --
The above example, as simple as it is, won't work, because header.jsp
can't find the attribute named "title".
Have I completely misunderstood the intent behind Tiles, or is it
simply not quite ready for prime time? Is there a better (simpler)
approach than the one taken in the above example?
-- Jim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why don't tiles "cascade"?
Posted by Jim Crossley <jc...@ifleet.com>.
Cedric Dumoulin <ce...@lifl.fr> writes:
> > An export attribute with a value of "true" would essentially cause
> > the tile to inherit the context of its parent[s].
>
> I am agree with such feature. But, should we propose 'export' or
> 'import' (parent > attribute) ;-).
It depends on your perspective! I suppose "import" makes more sense
though.
> Another solution could be :
>
> <tiles:insert path="/header.jsp">
> <put beanName="*" beanScope="tiles" />
> </tiles:insert>
I guess I'm just not crazy about the explicit put, but I'll yield to
majority opinion.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why don't tiles "cascade"?
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Jim Crossley wrote:
>
>
> > If you want to use an attribute value inside another inserted Tile, you have to
> > pass it explicitly. In your example, you could write something like :
>
> Instead of this...
>
> > <tiles:insert path="/header.jsp">
> > <put beanName="title" beanScope="template" />
> > </tiles:insert>
>
> Maybe this?
>
> <tiles:insert path="/header.jsp" export="true"/>
> An export attribute with a value of "true" would essentially cause the
> tile to inherit the context of its parent[s].
I am agree with such feature. But, should we propose 'export' or 'import' (parent
attribute) ;-).
Another solution could be :
<tiles:insert path="/header.jsp">
<put beanName="*" beanScope="tiles" />
</tiles:insert>
>
>
> > Reading your example, I think you should better not cut a tag into
> > two separate files (<body> and </body>). Putting a start and end tag
> > in the same file improve legibility, and minimize potential errors
> > (forget the closing tags, forget to insert the corresponding file,
> > ...).
>
> You're right: it did hurt to separate the begin/end tags into two
> files, but we have fairly complex <body> and <div> tags replicated in
> multiple layout (and non-layout) HTML files. For example, would you
> want to have to maintain the following muck in multiple files?
>
> <body leftmargin="0" topmargin="0" bgproperties="fixed"
> background="<%=request.getContextPath()%><bean:message key='image.background'/>"
> onload="javascript:motd();"
> bgcolor="<bean:message key='html.bgcolor'/>">
>
> BTW, please don't misunderstand my feedback on this forum. Tiles is
> wonderful, and we're using it quite happily. The fact that it allows
> me to replace a JSP file with a definition tag in a config file is a
> beautiful thing. It's such a beautiful thing that I want to do it
> even for files "beneath the top tier" of defined tiles.
I just share my own experience :-) You certainly have good reasons to do it in this way,
and I respect them.
Cedric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why don't tiles "cascade"?
Posted by Jim Crossley <jc...@ifleet.com>.
Hi Cedric
Cedric Dumoulin <ce...@lifl.fr> writes:
> It is an expected behavior ! Tiles can be seen like functions : they
> takes parameters, and parameters are only visible inside the
> function, not outside, neither in called functions.
[...]
I agree the potential naming conflicts could be a problem, but at
least they can be reasonably well managed in one place: the
definitions file. How about a compromise?
> If you want to use an attribute value inside another inserted Tile, you have to
> pass it explicitly. In your example, you could write something like :
Instead of this...
> <tiles:insert path="/header.jsp">
> <put beanName="title" beanScope="template" />
> </tiles:insert>
Maybe this?
<tiles:insert path="/header.jsp" export="true"/>
An export attribute with a value of "true" would essentially cause the
tile to inherit the context of its parent[s].
> Reading your example, I think you should better not cut a tag into
> two separate files (<body> and </body>). Putting a start and end tag
> in the same file improve legibility, and minimize potential errors
> (forget the closing tags, forget to insert the corresponding file,
> ...).
You're right: it did hurt to separate the begin/end tags into two
files, but we have fairly complex <body> and <div> tags replicated in
multiple layout (and non-layout) HTML files. For example, would you
want to have to maintain the following muck in multiple files?
<body leftmargin="0" topmargin="0" bgproperties="fixed"
background="<%=request.getContextPath()%><bean:message key='image.background'/>"
onload="javascript:motd();"
bgcolor="<bean:message key='html.bgcolor'/>">
BTW, please don't misunderstand my feedback on this forum. Tiles is
wonderful, and we're using it quite happily. The fact that it allows
me to replace a JSP file with a definition tag in a config file is a
beautiful thing. It's such a beautiful thing that I want to do it
even for files "beneath the top tier" of defined tiles.
-- Jim
>
> Cedric
>
> Jim Crossley wrote:
>
> > Apparently it's not possible to access attributes of any tiles other
> > than your immediate "parent". IMHO, this restricts my ability to
> > partition my presentation code into simple, reusable chunks.
> >
> > Here's a semi-practical example.
> >
> > Consider this snippet from a definitions file...
> >
> > <definition name="training" path="/layout.jsp">
> > <put name="content" value="/training.jsp"/>
> > <put name="title" value="Training"/>
> > </definition>
> >
> > layout.jsp
> > -- CUT --
> > <tiles:insert path="/header.jsp"/>
> > <tiles:insert attribute="content"/>
> > <tiles:insert path="/footer.jsp"/>
> > -- CUT --
> >
> > header.jsp
> > -- CUT --
> > <html>
> > <head>
> > <title><tiles:getAsString name="title"/></title>
> > </head>
> > <body>
> > -- CUT --
> >
> > footer.jsp
> > -- CUT --
> > </body>
> > </html>
> > -- CUT --
> >
> > The above example, as simple as it is, won't work, because header.jsp
> > can't find the attribute named "title".
> >
> > Have I completely misunderstood the intent behind Tiles, or is it
> > simply not quite ready for prime time? Is there a better (simpler)
> > approach than the one taken in the above example?
> >
> > -- Jim
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why don't tiles "cascade"?
Posted by Cedric Dumoulin <ce...@lifl.fr>.
It is an expected behavior ! Tiles can be seen like functions : they takes
parameters, and parameters are only visible inside the function, not outside,
neither in called functions.
This behavior allows to write a Tile without taking care about possible
conflicts with attribute names.
Imagine that you write a complex page with several nested Tiles, and several
time the same Tile with different values for the same attribute. If you "cascade"
attributes, you will have names clashing. Furthermore, while developing a Tile
you will need to thing about the names used in the whole page and in other Tiles,
to avoid possible conflict ! This will forbid reusable Tiles.
If you want to use an attribute value inside another inserted Tile, you have to
pass it explicitly. In your example, you could write something like :
layout.jsp
-- CUT --
<tiles:insert path="/header.jsp">
<put beanName="title" beanScope="template" />
// In future release, beanScope will accept "tiles" also (same as
template)
</tiles:insert>
<tiles:insert attribute="content"/>
<tiles:insert path="/footer.jsp"/>
-- CUT --
Reading your example, I think you should better not cut a tag into two separate
files (<body> and </body>). Putting a start and end tag in the same file improve
legibility, and minimize potential errors (forget the closing tags, forget to
insert the corresponding file, ...).
Cedric
Jim Crossley wrote:
> Apparently it's not possible to access attributes of any tiles other
> than your immediate "parent". IMHO, this restricts my ability to
> partition my presentation code into simple, reusable chunks.
>
> Here's a semi-practical example.
>
> Consider this snippet from a definitions file...
>
> <definition name="training" path="/layout.jsp">
> <put name="content" value="/training.jsp"/>
> <put name="title" value="Training"/>
> </definition>
>
> layout.jsp
> -- CUT --
> <tiles:insert path="/header.jsp"/>
> <tiles:insert attribute="content"/>
> <tiles:insert path="/footer.jsp"/>
> -- CUT --
>
> header.jsp
> -- CUT --
> <html>
> <head>
> <title><tiles:getAsString name="title"/></title>
> </head>
> <body>
> -- CUT --
>
> footer.jsp
> -- CUT --
> </body>
> </html>
> -- CUT --
>
> The above example, as simple as it is, won't work, because header.jsp
> can't find the attribute named "title".
>
> Have I completely misunderstood the intent behind Tiles, or is it
> simply not quite ready for prime time? Is there a better (simpler)
> approach than the one taken in the above example?
>
> -- Jim
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Why don't tiles "cascade"?
Posted by Jim Crossley <jc...@ifleet.com>.
I understand how to make the example work, but the point of my example
was that tile attributes should be "recursively accessible" so that I
don't have to clutter up intermediary files with code that only serves
to export attributes.
You only have to expand the example a little bit to make your solution
a even more unwieldy.
Say you wanted to parameterize the content somehow. Say you have two
types of training: "light" and "heavy". You might be tempted to
break training.jsp out into two files, training-light.jsp and
training-heavy.jsp, and end up with two definitions:
<definition name="training.light" path="/layout.jsp">
<put name="content" value="/training-light.jsp"/>
<put name="title" value="Training"/>
</definition>
<definition name="training.heavy" path="/layout.jsp">
<put name="content" value="/training-heavy.jsp"/>
<put name="title" value="Training"/>
</definition>
The problem with that solution is that those two files happen to
differ by only one word. All of their code is exactly alike except
one contains the word "light" and the other has the word "heavy".
Regardless of how much they differ, the point is that they have
something in common and could therefore benefit by sharing it. What I
would like to be able to do with Tiles is something like this:
<definition name="training.light" path="/layout.jsp">
<put name="content" value="/training.jsp"/>
<put name="title" value="Training"/>
<put name="type" value="light"/>
</definition>
<definition name="training.heavy" extends="training.light">
<put name="type" value="heavy"/>
</definition>
The above is legal Tiles syntax, and it saves me from having to create
two extra almost-identical files, but unfortunately, it won't
work. :-(
-- Jim
"Robert D. Morse" <rm...@mdesignz.com> writes:
> You're correct that it won't find "title". layout.jsp needs to store it so
> it can be accessed by header (e.g., session.setAttribute()).
>
> -----Original Message-----
> From: jim@jimmy.ifleet.com [mailto:jim@jimmy.ifleet.com]On Behalf Of Jim
> Crossley
> Sent: Tuesday, February 19, 2002 12:39 PM
> To: Struts Users Mailing List
> Cc: James CE Johnson
> Subject: Why don't tiles "cascade"?
>
>
> Apparently it's not possible to access attributes of any tiles other
> than your immediate "parent". IMHO, this restricts my ability to
> partition my presentation code into simple, reusable chunks.
>
> Here's a semi-practical example.
>
> Consider this snippet from a definitions file...
>
> <definition name="training" path="/layout.jsp">
> <put name="content" value="/training.jsp"/>
> <put name="title" value="Training"/>
> </definition>
>
> layout.jsp
> -- CUT --
> <tiles:insert path="/header.jsp"/>
> <tiles:insert attribute="content"/>
> <tiles:insert path="/footer.jsp"/>
> -- CUT --
>
> header.jsp
> -- CUT --
> <html>
> <head>
> <title><tiles:getAsString name="title"/></title>
> </head>
> <body>
> -- CUT --
>
> footer.jsp
> -- CUT --
> </body>
> </html>
> -- CUT --
>
> The above example, as simple as it is, won't work, because header.jsp
> can't find the attribute named "title".
>
> Have I completely misunderstood the intent behind Tiles, or is it
> simply not quite ready for prime time? Is there a better (simpler)
> approach than the one taken in the above example?
>
> -- Jim
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Why don't tiles "cascade"?
Posted by "Robert D. Morse" <rm...@mdesignz.com>.
You're correct that it won't find "title". layout.jsp needs to store it so
it can be accessed by header (e.g., session.setAttribute()).
-----Original Message-----
From: jim@jimmy.ifleet.com [mailto:jim@jimmy.ifleet.com]On Behalf Of Jim
Crossley
Sent: Tuesday, February 19, 2002 12:39 PM
To: Struts Users Mailing List
Cc: James CE Johnson
Subject: Why don't tiles "cascade"?
Apparently it's not possible to access attributes of any tiles other
than your immediate "parent". IMHO, this restricts my ability to
partition my presentation code into simple, reusable chunks.
Here's a semi-practical example.
Consider this snippet from a definitions file...
<definition name="training" path="/layout.jsp">
<put name="content" value="/training.jsp"/>
<put name="title" value="Training"/>
</definition>
layout.jsp
-- CUT --
<tiles:insert path="/header.jsp"/>
<tiles:insert attribute="content"/>
<tiles:insert path="/footer.jsp"/>
-- CUT --
header.jsp
-- CUT --
<html>
<head>
<title><tiles:getAsString name="title"/></title>
</head>
<body>
-- CUT --
footer.jsp
-- CUT --
</body>
</html>
-- CUT --
The above example, as simple as it is, won't work, because header.jsp
can't find the attribute named "title".
Have I completely misunderstood the intent behind Tiles, or is it
simply not quite ready for prime time? Is there a better (simpler)
approach than the one taken in the above example?
-- Jim
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>