By the way, what's the use case for putting definitions in a jsp? Why
would someone prefer that method over another. . .
David
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.
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
You have to read "AttributeTag" instead of "InsertTag". I did not update
the issue waiting for an answer from you.
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]
