Re: T5: Components initialising derived variables for action requests?
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]
Re: T5: Components initialising derived variables for action requests?
Gotcha.
Why not do something simple like make the bound property a pseudo-
property?
Something like:
"Component".java:
@Component(parameters={"source=subSource",...})
SubComponent sub;
public Object getSubSource() {
return results.getGrouper();
}
...
Now subSource will be evaluated "on demand", so the component's
parameter won't be null?
If results.getGrouper() is expensive, you can throw a
@Cached onto getSubSource to avoid calling it multiple times.
Robert
On May 27, 2008, at 5/2712:24 PM , Blower, Andy wrote:
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 comman
Re: RE: T5: Components initialising derived variables for action requests?
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
RE: T5: Components initialising derived variables for action requests?
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]
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]
RE: T5: Components initialising derived variables for action requests?
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]
