You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Antonio Petrelli <ap...@apache.org> on 2006/10/06 09:35:43 UTC
[tiles2] Separate attribute handling from
Re-Re-Hi again
I know I am bugging you again but I have another idea.
Personally I don't like using the same <tiles:insert> tag to define
attributes in a layout page and to insert templates/definitions/strings:
I think the concept of attribute is separated from the rest (it is
somewhat like specified a "setXXX" statement in a Java Bean).
Moreover if you take a look at InsertTag, attribute handling code is
almost separated (except of a set of "if-else if" statements) from
definition and template handling.
I think that a <tiles:attribute> tag could be created: I think that this
way the code of InsertTag (and the future AttributeTag) will be much
simpler, and the resulting application code will be more intuitive.
What do you think?
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Separate attribute handling from
Posted by Greg Reddin <gr...@apache.org>.
Yeah, I can accept that definition.
Greg
On Oct 10, 2006, at 1:40 AM, Antonio Petrelli wrote:
> Greg Reddin ha scritto:
>> I don't know. Having used Tiles for a while, I'm used to the way
>> things are. It doesn't bother me to use the same overloaded tag
>> in two different ways. I'm not sure if it's confusing to the
>> users or not.
>
> I don't know if it's the same for you, but in my mind a "tile" can
> be a page, a definition or a string. A layout page is like a tile
> pattern, <tiles:insert type="attribute"/> tags are like tile gaps,
> and the surrounding HTML code is made of tile joints...
> Sorry for this building analogy :-)
> What I mean is that the concept of attribute is that it is so
> different from the "tile" analogy, i.e. you put a tile (definition,
> page, string) where there is a tile gap (attribute).
> I hope that I have been clearer now :-)
>
> Ciao
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Separate attribute handling from
Posted by Antonio Petrelli <ap...@apache.org>.
Greg Reddin ha scritto:
> I don't know. Having used Tiles for a while, I'm used to the way
> things are. It doesn't bother me to use the same overloaded tag in
> two different ways. I'm not sure if it's confusing to the users or not.
I don't know if it's the same for you, but in my mind a "tile" can be a
page, a definition or a string. A layout page is like a tile pattern,
<tiles:insert type="attribute"/> tags are like tile gaps, and the
surrounding HTML code is made of tile joints...
Sorry for this building analogy :-)
What I mean is that the concept of attribute is that it is so different
from the "tile" analogy, i.e. you put a tile (definition, page, string)
where there is a tile gap (attribute).
I hope that I have been clearer now :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Separate attribute handling from
Posted by Antonio Petrelli <ap...@apache.org>.
Greg Reddin ha scritto:
> So are you suggesting we use 2 different tags to insert a definition
> as opposed to an attribute? That seems like a good idea.
I added a JIRA issue for that:
http://issues.apache.org/struts/browse/SB-55
Notice that I suggested to split <tiles:insert> into
<tiles:insertDefinition>, <tiles:insertTemplate>, <tiles:insertString>
and <tiles:attribute> but:
* <tiles:insertString> does not make sense IMO, the "string" type has a
meaning only for an attribute whose type is a string: in fact
<tiles:getAsString> would be like <tiles:attribute> forcing the view as
a string. There are better tags to put strings :-)
* <tiles:insertDefinition> and <tiles:insertTemplate> could be a single
<tiles:insert> tag since its management is very similar, or maybe they
could share the same base tag (to avoid code duplication) or,
alternatively, create a utility class to process templates and
definitions not depending on JSP tag libraries (this way it could be
ported also to FreeMarker, I suppose);
* <tiles:attribute> has a different name pattern because I would like to
push the idea of "defining" attributes and not "inserting" them.
What do you think?
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Separate attribute handling from
Posted by Greg Reddin <gr...@apache.org>.
Maybe we need <tiles:insertDefintion> and <tiles:insertAttribute> to
handle the 2 types specifically instead of one <tiles:insert> to
handle them generically.
I don't know. Having used Tiles for a while, I'm used to the way
things are. It doesn't bother me to use the same overloaded tag in
two different ways. I'm not sure if it's confusing to the users or
not. I guess if the logic is already split up by if statements it
makes sense to just move it into separate classes with their own
name. The only issue is that right now I can use <tiles:insert> to
generically include a named fragment. The fragment could be an
attribute of the "current" definition or it could be a completely
independent definition.
Part of the problem is with the definition of a tile. Right now a
"tile" can be any of three things, pretty much handled generically by
the <tiles:insert> tag. Those three things are:
* A JSP page.
* An attribute of the current Tiles definition.
* Another Tiles definition.
Maybe we need to call the definition a "tile", an attribute an
attribute, and a page a page. OTOH, maybe it's good practice to keep
the ambiguity and call everything a tile. I can see benefits and
drawbacks to both approaches. Keeping it generic gives Tiles a lot
of flexibility. Requiring more specificity makes it easier for
newbies to get used to. Could/Should we do both (i.e an <insert> tag
for generic inserts and <insertDefintion>, <insertAttribute>, and
<insertPage> tags for specificity)?
Greg
On Oct 6, 2006, at 2:35 AM, Antonio Petrelli wrote:
> Re-Re-Hi again
> I know I am bugging you again but I have another idea.
> Personally I don't like using the same <tiles:insert> tag to define
> attributes in a layout page and to insert templates/definitions/
> strings: I think the concept of attribute is separated from the
> rest (it is somewhat like specified a "setXXX" statement in a Java
> Bean).
> Moreover if you take a look at InsertTag, attribute handling code
> is almost separated (except of a set of "if-else if" statements)
> from definition and template handling.
> I think that a <tiles:attribute> tag could be created: I think that
> this way the code of InsertTag (and the future AttributeTag) will
> be much simpler, and the resulting application code will be more
> intuitive.
> What do you think?
>
> Ciao
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org