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]
