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 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]
