Ok, I will keep an eye out for 2.1 then. Do you know if no schedule = weeks or months. For now I will stick with my tag approach. These attributes really belong to the tiles context and I need to make sure they are limited to that. Otherwise I open myself up to finding some property in the request that was set by a earlier tile that shouldn't apply to the current one being rendered. I think even with the cascading values I would recommend adding the functionality to importAttributeTag where if you don't specify a name but you do specify a toName that you put either the attributeContext or a map of the attributeContext values in that toName in the scope specified. Jonathan
> Date: Wed, 16 Apr 2008 21:00:43 +0200> From: [EMAIL PROTECTED]> To: > [email protected]> Subject: Re: Iterate through Attributes> > 2008/4/16, > Jonathan DeRose <[EMAIL PROTECTED]>:> > The importAttribute tag takes > everything in the context and puts them individually into page scope.> > If > you use the "toScope" attribute with a value of "request", the> attribute > will be put in request scope.> > > When will 2.1.0 be out?> > It's hard to > say, we have no schedule.> > > And what scheme did you use for cascading? Do > you copy all attributes into the child context upon creation? Or does the > inserting def select the ones it wants.> > Not exactly. If you want to > cascade an attribute, use <put-attribute> cascade="true"> or > <tiles:putAttribute cascade="true" />, the> attribute will be cascaded to > inner definitions/templates.> Cascaded attributes are managed separately from > not-cascaded, with a> precedence to not-cascaded ones. Cascaded attributes > are copied from a> context to the inner.> > Antonio _________________________________________________________________ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008
