Greg Reddin ha scritto:
Of 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
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: [EMAIL
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
On Jun 14, 2006, at 2:09 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
Of 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
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.
On
Greg Reddin asked:
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.
I would guess that's just to get the tile name from a bean property.
With the availability of EL, that seems like an unnecessary
On Jun 14, 2006, at 9:32 AM, [EMAIL PROTECTED] wrote:
Greg Reddin asked:
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.
I would guess that's just to get the tile name from a bean property.
With
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
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
On Jun 14, 2006, at 11:00 AM, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
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
At 9:00 AM -0700 6/14/06, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
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,
On Jun 14, 2006, at 11:21 AM, Joe Germuska wrote:
At 9:00 AM -0700 6/14/06, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
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
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
12 matches
Mail list logo
