Thanks for the replay Robert, I'll try to explain better. Here's the component hierarchy, '->' means contains.
Page -> Component -> Sub-component Page passes parameter (results) to Component which extracts a derived object (grouper) using the statement "grouper = results.getGrouper();" in setupRender(). The source parameter passed to Sub-component for it to do its work is the grouper object. In event handlers in Sub-component, the grouper parameter is null because although results has been obtained by the page's onActivate() method, and passed to Component, grouper is not initialised and so null is passed as a paremeter to Sub-component for action requests. Does that make any more sense? > -----Original Message----- > From: robert zeigler [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Zeigler > Sent: 27 May 2008 18:02 > To: Tapestry users > Subject: Re: T5: Components initialising derived variables for action > requests? > > It makes some sense, but more details would help. > You said that the parameter is "redundant": in what way is it > redundant? > If the parameter is already passed to the component, then what's the > issue? > If the value is calculated, why can't the component calculate it? > Incidentally, if the component has the value at render time, couldn't > the component stick the value into the context for the action/event > link? Then your event handler would accept a parameter which is the > value of interest, and you're done. :) > > Sometimes, to understand the general concept, specific situations/ > details are helpful; I suggest more specifics on your use case. > > Robert > > On May 27, 2008, at 5/2711:48 AM , 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
