Antonio Petrelli wrote:
David H. DeWolf ha scritto:
ummm. . .yes, I specifically remember removing that for a reason, but
for the life of me can't remember why. Perhaps I just wasn't thinking
straight.
Good catch, I'd say let's add it back in as it will make the rest of
the attribute tag processing a little simpler.
The only reason why we wouldn't want to modify the underlying
ComponentAttribute would be if we want to support the case where:
1) type is calculated
2) no valid definition is found matching the name
3) type is set to string
4) definition is added to the container
5) tag is now in an invalid state as a recalculation would result in a
type of 'definition'
I added that "preprocessAttribute" method simply because attributes in
definitions created with DefinitionTag may be inconsistent, while those
created in tiles-defs.xml are consistent after resolving attributes. In
fact the "preprocessing" could be executed when the definition in
DefinitionTag is created, therefore there won't be need for such a
preprocessing in AttributeTag.
Can you help me understand why those created from the factory are
"consistent"?
We definitely could do this type of thing at creation time - for both
those defined through the tag and those defined through the factory. I
don't really have a strong opinion either way, but my inclination would
be to resolve the unspecified type 'just in time'. . .
On the other hand, the benefit of setting the type after calculation
is that it saves us a couple of nano-seconds because we don't have to
recalculate the next time around (which is basically a couple of
equals operations and a lookup in a map).
Speaking of performances, there is an issue for that:
http://issues.apache.org/struts/browse/SB-49
Agreed. It still behaves as described.
You have to read "AttributeTag" instead of "InsertTag". I did not update
the issue waiting for an answer from you.
It's always been in AttributeTag, correct? I would say that the
solution is one of the following:
1) Set the type after resolving it the first time so it can be reused
2) Accept this small overhead in order to allow this property to morph
as new definitions are registered.
What I don't think we want is to require the tag to differentiate
between tag created definitions and container created definitions.
Agree?
David
Thank you.
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
