tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: svn commit: r503628 - in /tiles/framework/trunk: tiles-api/src/main/java/org/apache/tiles/TilesContainer.java tiles-core/src/main/java/org/apache/tiles/impl/BasicTilesContainer.java
Date Mon, 05 Feb 2007 13:39:43 GMT
But wouldn't it be better to simply modify the container to 
appropriately scope the attributes?  For intance, could there be a stack 
that we pop off when the attributes get out of scope?  I guess I don't 
see what this problem requires additional container methods.  It should 
be handled internally, not by requiring every client to use it.

David

Antonio Petrelli wrote:
> 2007/2/5, David H. DeWolf <ddewolf@apache.org>:
>> Antonio,
>>
>> I'm starting to get a *little* concerned that our container interface is
>> becoming more verbose than it needs to be.  Can you explain the use case
>> for the additions below and why we can't just add attributes to the
>> existing context?
> 
> The answer is almost completely here:
> http://issues.apache.org/struts/browse/TILES-96
> If you put an attribute using <tiles:putAttribute> every attribute
> with the same name will be overridden, instead of working only inside
> their parent tag.
> I think that the methods without the ComponentContext parameters are
> of no use (at least they are not used inside JSP tags).
> I added a new test link in the test webapp ("Test Insert Configured
> Definition with an overridden content and one with original content").
> 
> Antonio
> 

Mime
View raw message