Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of ddewolf@gmail.com designates
 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=Obxw44WVdzcLuVDOwx18F/Z/mW2q0CSxIb8qTNYwGB5Ila4vxsI1v1bzc6den9ldufyIio+11RaROtDqwM0cN8zpPfwbMyCVBGF7aZiFqqCtB3KnNKYRq443JAuh1qzgcXay6CjEHJugSzU+Y/7LZnGh1ON6GMJDuGwgVZGfFaA=
Message-ID: <454F42B5.1050907@apache.org>
Date: Mon, 06 Nov 2006 09:12:05 -0500
From: "David H. DeWolf" <ddewolf@apache.org>
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: [tiles2] AttributeTag.preprocessAttribute disappearance
References: <454F310F.9020508@apache.org> <454F3620.4000502@apache.org>
 <454F3E67.2030004@apache.org>
In-Reply-To: <454F3E67.2030004@apache.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sender: "David H. DeWolf" <ddewolf@gmail.com>


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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org