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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
