You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tiles.apache.org by Antonio Petrelli <an...@gmail.com> on 2007/02/05 17:09:25 UTC
Attribute lists incoherences
Hi all!
It seems that there are some incoherences between how <tiles:putList>
works and the <putList> element inside tiles-defs.xml.
In particular:
- <tiles:putList>, with <tiles:putAttribute>, creates a list of
ComponentAttribute;
- <putList>, with element <add>, creates a list of values.
Now I wish to "refactor" all this stuff, but I would like your opinion on it:
- Rename the <put> element to <putAttribute>, just as the tag name.
- Rename the <add> element to <putAttribute>, and it adds attributes
and not values. Values are still stored by <item> and <bean> (this
erases the solution for a previous issue that I corrected, gulp!).
- Rename <tiles:putList> and <putList> to <tiles:putAttributeList> and
<putAttributeList>, for coherence.
- Remove the "required" clause to the name attribute of
<tiles:insertAttribute>, and add a "value" attribute (with
"rtexprvalue" set) to insert an attribute contained inside an iterated
list attribute value.
Thoughts?
Antonio
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/5, Joe Germuska <jo...@germuska.com>:
> Having still never encountered a use case myself for using the lists in
> tiles (anyone care to share one or more with me, just to give me a
> reference?)
Think about a "dynamic layout", where you, for example, want to put a
variable list of definitions one after the other.
This kind of things is right inside the showcase, but the way it is
implemented is really horrible.
> However, what is the solution that you are erasing with this change?
Never mind, I thought it was this:
http://issues.apache.org/struts/browse/TILES-47
but I thought the problem was in the value of the item, not in the
value of the attribute list. Well, I feel better now :-)
Antonio
Re: Attribute lists incoherences
Posted by Joe Germuska <jo...@germuska.com>.
Having still never encountered a use case myself for using the lists in
tiles (anyone care to share one or more with me, just to give me a
reference?), I feel like I shouldn't make much fuss over those areas of the
application; in any case, nothing here would lead me to make a fuss, as it
all seems reasonable.
However, what is the solution that you are erasing with this change?
Joe
On 2/5/07, Antonio Petrelli <an...@gmail.com> wrote:
>
> Hi all!
> It seems that there are some incoherences between how <tiles:putList>
> works and the <putList> element inside tiles-defs.xml.
> In particular:
> - <tiles:putList>, with <tiles:putAttribute>, creates a list of
> ComponentAttribute;
> - <putList>, with element <add>, creates a list of values.
> Now I wish to "refactor" all this stuff, but I would like your opinion on
> it:
> - Rename the <put> element to <putAttribute>, just as the tag name.
> - Rename the <add> element to <putAttribute>, and it adds attributes
> and not values. Values are still stored by <item> and <bean> (this
> erases the solution for a previous issue that I corrected, gulp!).
> - Rename <tiles:putList> and <putList> to <tiles:putAttributeList> and
> <putAttributeList>, for coherence.
> - Remove the "required" clause to the name attribute of
> <tiles:insertAttribute>, and add a "value" attribute (with
> "rtexprvalue" set) to insert an attribute contained inside an iterated
> list attribute value.
>
> Thoughts?
>
> Antonio
>
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"The truth is that we learned from João forever to be out of tune."
-- Caetano Veloso
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/10, Antonio Petrelli <an...@gmail.com>:
> You're welcome :-) but please reopen TILES-103:
> http://issues.apache.org/struts/browse/TILES-103
Well, already done :-) Anyway feel free to edit it.
Antonio
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
If you're ready to tackle it, go for it. I probably won't have a chance
to start it until tomorrow. If you knock this off, I'll spend that time
putting together a 2.0.1 build instead.
David
Antonio Petrelli wrote:
> 2007/2/10, Antonio Petrelli <an...@gmail.com>:
>> 2007/2/9, David H. DeWolf <dd...@apache.org>:
>> > Would you mind if I made one tweak (sorry, I know it's late and you
>> > already committed it).
>> >
>> > I'd like to change the xml entities to match the more conventional
>> > naming standard <add-attribute>, <put-attribute>, etc...this is what
>> all
>> > sun specs use, what struts uses, and I think it's more consistent with
>> > related technologies.
>>
>> You're welcome :-) but please reopen TILES-103:
>> http://issues.apache.org/struts/browse/TILES-103
>
> David, do you still want to take care of TILES-103? If not, I can
> assign it to myself and work on it.
>
> Antonio
>
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/10, Antonio Petrelli <an...@gmail.com>:
> 2007/2/9, David H. DeWolf <dd...@apache.org>:
> > Would you mind if I made one tweak (sorry, I know it's late and you
> > already committed it).
> >
> > I'd like to change the xml entities to match the more conventional
> > naming standard <add-attribute>, <put-attribute>, etc...this is what all
> > sun specs use, what struts uses, and I think it's more consistent with
> > related technologies.
>
> You're welcome :-) but please reopen TILES-103:
> http://issues.apache.org/struts/browse/TILES-103
David, do you still want to take care of TILES-103? If not, I can
assign it to myself and work on it.
Antonio
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Sorry, I should have been more specific.
I didn't expect the JSP Tags to change, just the xml elements. So, like
Joe, I'd personally go with your first option below.
xml:
insert-template
jsp tag:
insertTemplate
David
Antonio Petrelli wrote:
> 2007/2/10, Antonio Petrelli <an...@gmail.com>:
>> Do you think that the kind of refactoring that you suggested can be
>> done also for JSP tags? I think that if the names are the same, the
>> user will understand better their meaning.
>
>
> That's strange, it seems that JSP tag names prefer camel case and not
> dashes.
> So now I am asking myself if:
> * we should stick with the old JSP tags, though the names of XML
> elements are different to JSP tags;
> * we should change the JSP tags names, though it breaks the "standard";
> * rollback the changes for the XML elements to go back to camel case,
> though it breaks another "standard".
> This is really an hamletic question... Please help!
>
> Antonio
>
Re: Attribute lists incoherences
Posted by Joe Germuska <jo...@germuska.com>.
I think there's precedence for translation between systems, as seen in the
difference between CSS style property names and their JavaScript
counterparts.
I would prefer that the XML be all-lowercase/hyphenated and the JSP be camel
case, to maintain consistency with other styles in their respective domains.
However, I am not in a position to put a ton of time into either
implementing or debating...
Joe
On 2/14/07, Antonio Petrelli <an...@gmail.com> wrote:
>
> 2007/2/10, Antonio Petrelli <an...@gmail.com>:
> > Do you think that the kind of refactoring that you suggested can be
> > done also for JSP tags? I think that if the names are the same, the
> > user will understand better their meaning.
>
>
> That's strange, it seems that JSP tag names prefer camel case and not
> dashes.
> So now I am asking myself if:
> * we should stick with the old JSP tags, though the names of XML
> elements are different to JSP tags;
> * we should change the JSP tags names, though it breaks the "standard";
> * rollback the changes for the XML elements to go back to camel case,
> though it breaks another "standard".
> This is really an hamletic question... Please help!
>
> Antonio
>
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"The truth is that we learned from João forever to be out of tune."
-- Caetano Veloso
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/10, Antonio Petrelli <an...@gmail.com>:
> Do you think that the kind of refactoring that you suggested can be
> done also for JSP tags? I think that if the names are the same, the
> user will understand better their meaning.
That's strange, it seems that JSP tag names prefer camel case and not dashes.
So now I am asking myself if:
* we should stick with the old JSP tags, though the names of XML
elements are different to JSP tags;
* we should change the JSP tags names, though it breaks the "standard";
* rollback the changes for the XML elements to go back to camel case,
though it breaks another "standard".
This is really an hamletic question... Please help!
Antonio
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/14, Greg Reddin <gr...@gmail.com>:
> On 2/14/07, David H. DeWolf <dd...@apache.org> wrote:
> >
> > I think there's an implicit correlation made by most developers familiar
> > with web technologies that xml entities named "foo-bar" have jsp tag
> > counter parts named "fooBar". Just my opinion though. . .
>
>
> I agreee with that assessment.
Thanks Joe, David and Greg, at least now I know what to do :-)
Antonio
Re: Attribute lists incoherences
Posted by Greg Reddin <gr...@gmail.com>.
On 2/14/07, David H. DeWolf <dd...@apache.org> wrote:
>
> I think there's an implicit correlation made by most developers familiar
> with web technologies that xml entities named "foo-bar" have jsp tag
> counter parts named "fooBar". Just my opinion though. . .
I agreee with that assessment.
Greg
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
>
> Do you think that the kind of refactoring that you suggested can be
> done also for JSP tags? I think that if the names are the same, the
> user will understand better their meaning.
>
I think there's an implicit correlation made by most developers familiar
with web technologies that xml entities named "foo-bar" have jsp tag
counter parts named "fooBar". Just my opinion though. . .
David
> Antonio
>
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/9, David H. DeWolf <dd...@apache.org>:
> Would you mind if I made one tweak (sorry, I know it's late and you
> already committed it).
>
> I'd like to change the xml entities to match the more conventional
> naming standard <add-attribute>, <put-attribute>, etc...this is what all
> sun specs use, what struts uses, and I think it's more consistent with
> related technologies.
You're welcome :-) but please reopen TILES-103:
http://issues.apache.org/struts/browse/TILES-103
I was thinking about another incoherence: putListAttribute can have
putListAttribute as a child, I think that a "addListAttribute" element
(with a meaning similar to "addAttribute") should be its child (and
"addListAttribute" can be child of itself).
(Sorry for not using the "new" notation :-) )
Do you think that the kind of refactoring that you suggested can be
done also for JSP tags? I think that if the names are the same, the
user will understand better their meaning.
Antonio
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Would you mind if I made one tweak (sorry, I know it's late and you
already committed it).
I'd like to change the xml entities to match the more conventional
naming standard <add-attribute>, <put-attribute>, etc...this is what all
sun specs use, what struts uses, and I think it's more consistent with
related technologies.
David
David H. DeWolf wrote:
>
>
> Antonio Petrelli wrote:
>> 2007/2/6, David H. DeWolf <dd...@apache.org>:
>>>
>>> Actually, there is no "name" in add. That's the entire difference
>>> between the two. It separates a simple value in a list from a named
>>> attribute - right? Because it's not a name/value pair, I think I like
>>> add better than put.
>>
>> How about <addAttribute>, since it adds an attribute and not another
>> object?
>
> works for me.
>
> -D
>
>>
>> Antonio
>>
>
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> 2007/2/6, David H. DeWolf <dd...@apache.org>:
>>
>> Actually, there is no "name" in add. That's the entire difference
>> between the two. It separates a simple value in a list from a named
>> attribute - right? Because it's not a name/value pair, I think I like
>> add better than put.
>
> How about <addAttribute>, since it adds an attribute and not another
> object?
works for me.
-D
>
> Antonio
>
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/6, David H. DeWolf <dd...@apache.org>:
>
> Actually, there is no "name" in add. That's the entire difference
> between the two. It separates a simple value in a list from a named
> attribute - right? Because it's not a name/value pair, I think I like
> add better than put.
How about <addAttribute>, since it adds an attribute and not another object?
Antonio
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> 2007/2/6, David H. DeWolf <dd...@apache.org>:
>>
>>
>> Antonio Petrelli wrote:
>> > - Rename the <add> element to <putAttribute>, and it adds attributes
>> > and not values.
>>
>> I'm confused. Like Joe, I haven't found much use for the lists, but I
>> thought that the different between add and put was basically that the
>> add added a value directly to a list while the put added a new
>> Attribute. I kind of equated it to a list and a map.
>> If you rename it to putAttribute, then it will be identical to the
>> refactor above. In essence aren't you removing this tag instead of
>> renaming it?
>
>
> Yeah, in fact now I am thinking to rename it to "putAttributeValue".
> Moreover, the <add> element's name is not required, but <put> is.
Actually, there is no "name" in add. That's the entire difference
between the two. It separates a simple value in a list from a named
attribute - right? Because it's not a name/value pair, I think I like
add better than put.
>
>
>>
>> Values are still stored by <item> and <bean> (this
>> > erases the solution for a previous issue that I corrected, gulp!).
>>
>> ?
>
> Don't worry, I was mistaken myself...
>
>> > - Remove the "required" clause to the name attribute of
>> > <tiles:insertAttribute>, and add a "value" attribute (with
>> > "rtexprvalue" set) to insert an attribute contained inside an iterated
>> > list attribute value.
>>
>> Can you explain the use case more? I don't see how we can insert an
>> attribute which hasn't been named.
>
> A ComponentListAttribute is, in fact, a list of ComponentAttribute,
> whose name is not used at all.
> It is useful if you have some sort of "dynamic layout", such as a list
> of attributes one under another.
> For example, in the "vboxLayout.jsp" pages in the showcase there is
> (now) the following snippet:
>
> #SNIP#
> <tiles:useAttribute id="list" name="list" classname="java.util.List" />
>
> <%-- Iterate over names.
> We don't use <iterate> tag because it doesn't allow insert (in JSP1.1)
> --%>
> <c:forEach var="item" items="${list}">
> <tiles:insertAttribute value="${item}" flush="true" />
> <br>
> </c:forEach>
Gotcha. Thanks for the clarification. I hadn't considered that . .
.The change works for me.
> #SNAP#
>
> What it does is putting a definition or a template in those places.
>
> Antonio
>
Re: Attribute lists incoherences
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/6, David H. DeWolf <dd...@apache.org>:
>
>
> Antonio Petrelli wrote:
> > - Rename the <add> element to <putAttribute>, and it adds attributes
> > and not values.
>
> I'm confused. Like Joe, I haven't found much use for the lists, but I
> thought that the different between add and put was basically that the
> add added a value directly to a list while the put added a new
> Attribute. I kind of equated it to a list and a map.
> If you rename it to putAttribute, then it will be identical to the
> refactor above. In essence aren't you removing this tag instead of
> renaming it?
Yeah, in fact now I am thinking to rename it to "putAttributeValue".
Moreover, the <add> element's name is not required, but <put> is.
>
> Values are still stored by <item> and <bean> (this
> > erases the solution for a previous issue that I corrected, gulp!).
>
> ?
Don't worry, I was mistaken myself...
> > - Remove the "required" clause to the name attribute of
> > <tiles:insertAttribute>, and add a "value" attribute (with
> > "rtexprvalue" set) to insert an attribute contained inside an iterated
> > list attribute value.
>
> Can you explain the use case more? I don't see how we can insert an
> attribute which hasn't been named.
A ComponentListAttribute is, in fact, a list of ComponentAttribute,
whose name is not used at all.
It is useful if you have some sort of "dynamic layout", such as a list
of attributes one under another.
For example, in the "vboxLayout.jsp" pages in the showcase there is
(now) the following snippet:
#SNIP#
<tiles:useAttribute id="list" name="list" classname="java.util.List" />
<%-- Iterate over names.
We don't use <iterate> tag because it doesn't allow insert (in JSP1.1)
--%>
<c:forEach var="item" items="${list}">
<tiles:insertAttribute value="${item}" flush="true" />
<br>
</c:forEach>
#SNAP#
What it does is putting a definition or a template in those places.
Antonio
Re: Attribute lists incoherences
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> Now I wish to "refactor" all this stuff, but I would like your opinion
> on it:
> - Rename the <put> element to <putAttribute>, just as the tag name.
+1
> - Rename the <add> element to <putAttribute>, and it adds attributes
> and not values.
I'm confused. Like Joe, I haven't found much use for the lists, but I
thought that the different between add and put was basically that the
add added a value directly to a list while the put added a new
Attribute. I kind of equated it to a list and a map.
If you rename it to putAttribute, then it will be identical to the
refactor above. In essence aren't you removing this tag instead of
renaming it?
Values are still stored by <item> and <bean> (this
> erases the solution for a previous issue that I corrected, gulp!).
?
> - Rename <tiles:putList> and <putList> to <tiles:putAttributeList> and
> <putAttributeList>, for coherence.
+1
> - Remove the "required" clause to the name attribute of
> <tiles:insertAttribute>, and add a "value" attribute (with
> "rtexprvalue" set) to insert an attribute contained inside an iterated
> list attribute value.
Can you explain the use case more? I don't see how we can insert an
attribute which hasn't been named.
>
> Thoughts?
>
> Antonio
>