Hi Andrew,
if I got you right, Component hands over a parameter grouper to Sub-Component
although grouper actually is null. This seems a bit smelly. Perhaps you should
rethink your concept (no offense meant :-) ).
But anyway, maybe Tapestry's Environment service could solve your problem. That
is a stack you can push Objects on and pop them of again. Once on the stack
those Objects can be read from virtually anywhere. For your use case the code
would look like:
public class Component {
@Inject
private Environment environment;
void methodAfterGrouperWasAssignedAValue() {
this.environment.push(Grouper.class, this.grouper);
}
void cleanupRender() {
// this has to be done to get rid of the grouper in the environment
this.environment.pop(Grouper.class);
}
}
public class Sub-Component {
@Environmental
private Grouper grouper;
someMethod() {
this.grouper.doSomething();
}
}
It might be usefull to have a look at the source code of Tapestrys Form
component and how it uses the Environment to provide contained fields with
FormSupport.
Hope this helps,
nillehammer
-----
> 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]
>
>
--- original Nachricht Ende ----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
