Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's
a given that this will break backwards compatibility. You can't
reduce an API without breaking compatibility. But as long as we're
seeing this version of Tiles as a rework, I don't think it's a
problem. Also, I don't think it's a difficult thing to fix in
existing applications. No functionality will be removed, but
redundant hooks to the same functionality will be removed. Finally,
I think this will be one of the greatest improvements to the
usability of Tiles. I'm currently working on a patch to implement this.
the attributes that are currently supported by InsertTag, I
believe the following are redundant:
1) attribute, definition, name could all be resolved to name.
2) component, page, and template could all be resolved to template.
In addition the name attribute can be interpreted as either a pointer
to a Tiles definition or attribute or an URL, which essentially makes
it equivalent to page and template. I propose that we reduce all
these meanings down to the "name" attribute. IW, name can be a
definition name or an attribute name. I suspect this is how Tiles is
being used in 90% of applications anyway. I know that's how I use
it. Further, I propose that we reduce all the URL-based attributes
to the "template" attribute. So if you want to directly insert a
page you must use the template attribute.
The net result is that you can use the insert tag in the following ways:
<tiles:insert name="someName"/>
- to insert a Tiles definition or attribute.
<tiles:insert template="/somepage.jsp"/>
- to insert a URL.
I'm not really sure what the use of the beanName and beanProperty
values are, so if someone wants to enlighten me on that, I'd
appreciate it.
Finally, I personally don't see the use for including a
controllerClass or controllerUrl in the insert tag. IM, if you want
to do something like that you should use the definition tag instead.
I still intend to completely support attributes defined in the tag
body as such:
<tiles:insert name="someDefinition">
<tiles:put name="someAttribute" value="someValue"/>
</tiles:insert>
And the other attributes like flush, ignore, and role will continue
to function as always. Have I left out any major uses of the insert
tag? Does this change remove any functionality that anyone is
currently relying on?
Thanks,
Greg
[1]
To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Antonio Petrelli ha scritto:
Maybe an optional "type" attribute could be used to distinguish
between attribute and name

Errata corrige: I meant "to distinguish between attribute and definition"

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Greg Reddin ha scritto:
the attributes that are currently supported by InsertTag, I believe
the following are redundant:

1) attribute, definition, name could all be resolved to name.

In addition the name attribute can be interpreted as either a pointer
to a Tiles definition or attribute or an URL, which essentially makes
it equivalent to page and template.

a little problem: what if there is a definition that has the same
name of an attribute? Will it get the attribute or the definition?
I think this is pretty rare, but I think also that it needs attention.
Maybe an optional "type" attribute could be used to distinguish between
attribute and name, and when it is absent the tag gives precedence to
the attribute.
For all the rest I totally agree with you.
Just my 2 eurocents

Antonio

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Jun 14, 2006, at 2:09 AM, Antonio Petrelli wrote:

Greg Reddin ha scritto:
>the attributes that are currently supported by InsertTag, I
>believe the following are redundant:
>>
>1) attribute, definition, name could all be resolved to name.
>
>>
>In addition the name attribute can be interpreted as either a
>pointer to a Tiles definition or attribute or an URL, which
>essentially makes it equivalent to page and template.
>
a little problem: what if there is a definition that has the
same name of an attribute? Will it get the attribute or the
definition?
I think this is pretty rare, but I think also that it needs attention.
Maybe an optional "type" attribute could be used to distinguish
between attribute and name, and when it is absent the tag gives
precedence to the attribute.

Good call. I'll make sure that gets included.

Greg

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

I like the idea. I've always felt tiles was more complicated than
necessary. Simplify it. Antonio's question is a good one. The
lookup order needs to be well documented and a
type="definition|attribute" attribute would probably need to be
available to override the standard lookup procedure.

6/13/06, Greg Reddin <greddin (AT) apache (DOT) orgwrote:
Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's
a given that this will break backwards compatibility. You can't
reduce an API without breaking compatibility. But as long as we're
seeing this version of Tiles as a rework, I don't think it's a
problem. Also, I don't think it's a difficult thing to fix in
existing applications. No functionality will be removed, but
redundant hooks to the same functionality will be removed. Finally,
I think this will be one of the greatest improvements to the
usability of Tiles. I'm currently working on a patch to implement this.

the attributes that are currently supported by InsertTag, I
believe the following are redundant:

1) attribute, definition, name could all be resolved to name.
2) component, page, and template could all be resolved to template.

In addition the name attribute can be interpreted as either a pointer
to a Tiles definition or attribute or an URL, which essentially makes
it equivalent to page and template. I propose that we reduce all
these meanings down to the "name" attribute. IW, name can be a
definition name or an attribute name. I suspect this is how Tiles is
being used in 90% of applications anyway. I know that's how I use
it. Further, I propose that we reduce all the URL-based attributes
to the "template" attribute. So if you want to directly insert a
page you must use the template attribute.

The net result is that you can use the insert tag in the following ways:

<tiles:insert name="someName"/>
- to insert a Tiles definition or attribute.

<tiles:insert template="/somepage.jsp"/>
- to insert a URL.

I'm not really sure what the use of the beanName and beanProperty
values are, so if someone wants to enlighten me on that, I'd
appreciate it.

Finally, I personally don't see the use for including a
controllerClass or controllerUrl in the insert tag. IM, if you want
to do something like that you should use the definition tag instead.

I still intend to completely support attributes defined in the tag
body as such:

<tiles:insert name="someDefinition">
<tiles:put name="someAttribute" value="someValue"/>
</tiles:insert>

And the other attributes like flush, ignore, and role will continue
to function as always. Have I left out any major uses of the insert
tag? Does this change remove any functionality that anyone is
currently relying on?

Thanks,
Greg

[1]

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Jun 14, 2006, at 11:00 AM, Wendy Smoak wrote:

6/14/06, Joe Germuska <Joe (AT) germuska (DOT) comwrote:
>
>Would you consider some kind of compatibility mode? That is, before
>you remove support for these, could there be a way for people to
>configure things for a more strict or more compatible evaluation, to
>ease migration? It seems like the closest you can get to deprecation
>warnings in tag libs/JSPs.
>
Rather than keep these things around in Standalone Tiles, I think the
responsibility for 'deprecation' warnings falls to Struts Action.

we know which attributes are going away, if we start warning
people in 1.3.x it won't be a surprise. But that's assuming SAF1
intends to switch to Standalone Tiles behind the scenes at some point.

George and Greg's exchange assuming the presence of EL points to
moving Standalone Tiles to a Servlet 2.4 baseline, which might
preclude SAF1 from using it at all.

I tend to agree with you and I'm not sure keeping it out of SAF1 is a
good idea. I was hoping ST would gain a bigger user base by
integrating it into SAF1 but I don't think that can happen if we
refactor the API. But I believe the API refactoring is a wise
choice. So I'll just play it by ear and see what happens.

Greg

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Jun 14, 2006, at 11:21 AM, Joe Germuska wrote:

At 9:00 AM -0700 6/14/06, Wendy Smoak wrote:
>6/14/06, Joe Germuska <Joe (AT) germuska (DOT) comwrote:
>>
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure things for a more strict or more compatible evaluation, to
ease migration? It seems like the closest you can get to
deprecation
warnings in tag libs/JSPs.
>>
>Rather than keep these things around in Standalone Tiles, I think the
>responsibility for 'deprecation' warnings falls to Struts Action.
>
but in Struts action, it would only be documentation, while in
tiles, it could be done in a way that you could transition in code.

However, I realize as I write this that saddling Standalone Tiles
with that kind of weight is wrong. SAT is essentially a 2.0
release, and should clean up all these kinds of things (and I too
find the Tiles API overly cluttered, so i'm totally in favor of
these kinds of changes)

Agreed. Part of the reason Tiles is in the shape it is in is for the
sake of compatibility. The problem is I don't think the story was
told very well. So, in a Java class you deprecate and say "use this
instead" but with Tiles the "use this instead" message was lost. The
result is you have people out there doing all kinds of things that
were "accidentally" supported. I agree that ST is basically a 2.0
version. I aim to clean it up as much as possible. I just hope we
don't lose the user base in the process.

My other comment was kind of reflexive. I suppose it could be
applied to struts-tiles -- or maybe you mean that the
responsibility falls to the struts-tiles component of struts-action?

That's the way I took it (struts-tiles). And maybe that's a
compatibility API. We wrap a struts-tiles compatibility layer around
standalone Tiles, deprecate it and add notes to the taglib doc. Cut
a release, then remove it and cut another release :-)

Greg

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org