Re: T5: Components initialising derived variables for action requests?

["Filip S. Adamsen" <fs...@fsadev.com>]

Hi Andy,

There's nothing wrong with letting events bubble - this is a core part 
of the Tapestry design and you pretty much have to do this when using, 
for example, BeanEditForm.

-Filip

On 2008-05-27 18:48, Blower, Andy wrote:
> Replying to myself so quickly - not a good sign. ;-)
> 
> Anyway, I found another solution which is to let the event bubble up to the parent component which needs to do the initialisation of the derived variable (which is then provided as a source for the sub-component) and do the init in the event handler method.
> 
> Not so bad, but it does force me to have my event handler in the component containing the sub-component which is actually generating the event. I'm unsure as to the best practice for this, I was assuming that a component should always handle its own events, which isn't possible in this case without session usage or a redundant parameter in the parent component.
> 
> I do hope this makes sense to someone out there on the list... rather than sounding like the babblings of a crazy man. ;-)
> 
> Thanks,
> 
> Andy
> 
> 
>> -----Original Message-----
>> From: Blower, Andy
>> Sent: 27 May 2008 17:20
>> To: 'Tapestry users'
>> Subject: T5: Components initialising derived variables for action
>> requests?
>>
>> How should a component initialise a derived variable from a parameter
>> for the purposes of handling events?
>>
>> As far as I've seen so far, derived variable initialisation is usually
>> done in a setupRender() method. This works for rendering, but not for
>> the event handling phase. The containing page has the onActivate()
>> method which sets up all required data for both the action requests as
>> well as render requests, but the components setupRender() only sets up
>> the component variable for render requests. Since pageAttached() fires
>> before onActivate(), that can't be used. What else could be used?
>>
>> I know that the component variable could be made a (kinda redundant)
>> parameter rather than being derived, or it could be persisted, but both
>> solutions seem clumsy and inelegant since all the information is
>> already available but only tied together for render requests.
>>
>> I find it hard to believe that Tapestry 5 has all the wonderful
>> activation context for restoring state without it being held in the
>> session but not have a mechanism for deriving variables on action
>> requests. I'm probably going to feel silly if it's really obvious, but
>> I can't figure it out.
>>
>> Thanks,
>>
>> Andy.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org