Re: How to observe property binding events
To answer the last question first, maybe. That depends on how you do it. :)
If the solution involves any potential added overhead for all properties to
handle a 2% use-case then it'll get scrutinized and not likely make it
in...If the design fits in line with the rest of the system + doesn't incur
any extra memory/perf overhead then "maybe" :) I don't see why not...but...
This goes back to my original point. Because of the way the IBinding works
there's really no such thing as the parameter changing, it's the root
reference that the Binding points to that changes..So, just keep that in
mind while you are playing around in there.
Don't take my first block of comments as me saying the contribution isn't
wanted, it is...But that's a ~very~ delicate piece of code to make your
contribution for so I just wanted you to know up front that there won't be
as much leniency there wrt "percieved perfection" as there might be in other
placesThat doesn't mean that it might not be perfect on the first time,
or after a couple revisions...We'll just have to see how you do it ;)
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
This pretty much confirms to me that there's a lack of a notification
feature for parameter binding events. Seems pretty basic and would be easy
to add. May I add that in a way that might make its way back into the code
base?
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 1:09 PM
To: Tapestry users
Subject: Re: How to observe property binding events
I'm not sure what the requirements are wrt properties and specific users.
I've done similar things on a "per request" basis via doing something
like:
public abstract int getProp();
public abstract void setProp(int value);
public int getComplicatedValue()
{
if(getProp() == -1) {
// do something complicated
setProp(newVal);
}
return getProp();
}
The idea being that the heavy operation will only happen once for that
request/response cycle.
This all changes if you want it to be done for "all users" ? You can do
that as well I suppose but I think I probably need more clarification on who
the properties are supposed to be exposed to/etc..
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> That's the opposite of the functionality I want. These are not PER
> request. They are per instance of a component. Thus true instance
> variables are the way to go. Tapestry recycles Components and it seems
> that within a request the same component is re-used but not cleared
> (ivars reset) even though it is re-parametrized. So, I don't think
> request vars would work.
>
> Thanks,
>
> Ezra Epstein
> Amazon.com - Developer Tools
> 206-266-2259
>
>
> -Original Message-
> From: andyhot [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 12:35 AM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> Why store them in local variables?
> Store it in the current request cycle...
> First do a cycle.getAttribute("myexpensivevar") if that returns null,
> do the computations and store the result back cycle.setAttribute
> ("myexpensivevar",obj);
>
> See
>
> http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapes
> try/IRequestCycle.html
>
>
> Epstein, Ezra wrote:
> > OK, let's get to brass tacks.
> >
> > I have some derived values that are somewhat expensive to compute so
> > I
> compute them once per request/response cycle and then they're in local
> instance variables (non-persisted).
> >
> > The particular component in question (with the semi-expensive
> > derived
> values) is used inside a loop and so may appear multiple times on a
> page. By default the first time I use the component I compute the
> value and then display from that computed value... The 2nd, 3rd, etc
> instance of those component on the page is actually the exact same
> Java instance and so the computed/derived ivar is still set. I've
> added a hack that records an original property value when the derived
> ivar is computed and if the original and current property values don't
> match I reset the derived ivar. It works, but it a total hack.
> >
> > The common way I'd imagine doing it is to listen to when the
> > property
> (parameter) is set by Tapestry. But now that I've lain out the use
> case maybe some knows the "right" way to do this in Tapestry.
> >
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> >
> > -Original Message-
> > From: Jesse
RE: How to observe property binding events
This pretty much confirms to me that there's a lack of a notification feature
for parameter binding events. Seems pretty basic and would be easy to add.
May I add that in a way that might make its way back into the code base?
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 1:09 PM
To: Tapestry users
Subject: Re: How to observe property binding events
I'm not sure what the requirements are wrt properties and specific users.
I've done similar things on a "per request" basis via doing something like:
public abstract int getProp();
public abstract void setProp(int value);
public int getComplicatedValue()
{
if(getProp() == -1) {
// do something complicated
setProp(newVal);
}
return getProp();
}
The idea being that the heavy operation will only happen once for that
request/response cycle.
This all changes if you want it to be done for "all users" ? You can do that as
well I suppose but I think I probably need more clarification on who the
properties are supposed to be exposed to/etc..
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> That's the opposite of the functionality I want. These are not PER
> request. They are per instance of a component. Thus true instance
> variables are the way to go. Tapestry recycles Components and it seems
> that within a request the same component is re-used but not cleared
> (ivars reset) even though it is re-parametrized. So, I don't think
> request vars would work.
>
> Thanks,
>
> Ezra Epstein
> Amazon.com - Developer Tools
> 206-266-2259
>
>
> -Original Message-
> From: andyhot [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 12:35 AM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> Why store them in local variables?
> Store it in the current request cycle...
> First do a cycle.getAttribute("myexpensivevar") if that returns null,
> do the computations and store the result back cycle.setAttribute
> ("myexpensivevar",obj);
>
> See
>
> http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapes
> try/IRequestCycle.html
>
>
> Epstein, Ezra wrote:
> > OK, let's get to brass tacks.
> >
> > I have some derived values that are somewhat expensive to compute so
> > I
> compute them once per request/response cycle and then they're in local
> instance variables (non-persisted).
> >
> > The particular component in question (with the semi-expensive
> > derived
> values) is used inside a loop and so may appear multiple times on a
> page. By default the first time I use the component I compute the
> value and then display from that computed value... The 2nd, 3rd, etc
> instance of those component on the page is actually the exact same
> Java instance and so the computed/derived ivar is still set. I've
> added a hack that records an original property value when the derived
> ivar is computed and if the original and current property values don't
> match I reset the derived ivar. It works, but it a total hack.
> >
> > The common way I'd imagine doing it is to listen to when the
> > property
> (parameter) is set by Tapestry. But now that I've lain out the use
> case maybe some knows the "right" way to do this in Tapestry.
> >
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> >
> > -Original Message-
> > From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 09, 2006 3:33 PM
> > To: Tapestry users
> > Subject: Re: How to observe property binding events
> >
> > There's also the org.apache.tapestry.event.ChangeObserver interface,
> > though this is currently only used by the services in
> > tapestry.persist to observe page property changes when they are
> > being managed via a particular persistence strategy. (like
> > session/client/etc..)
> >
> > ~Maybe~ it's an oversight, and maybe not..I guess that depends on
> what/why you are trying to do. You'll find that there is very little
> in the framework that wasn't put there for an actual need, so adding
> in support for things that no one has needed yet doesn't seem to fall
> in line with sound design.
> > (imho of course..)
> >
> > If you can outline why you need this, and exactly what
> properties/conditions you'd want to observe we might be able to work
> something out...A general "anything" is harder to understand / design
> around.
> >
> > There is
Re: How to observe property binding events
I'm not sure what the requirements are wrt properties and specific users.
I've done similar things on a "per request" basis via doing something like:
public abstract int getProp();
public abstract void setProp(int value);
public int getComplicatedValue()
{
if(getProp() == -1) {
// do something complicated
setProp(newVal);
}
return getProp();
}
The idea being that the heavy operation will only happen once for that
request/response cycle.
This all changes if you want it to be done for "all users" ? You can do that
as well I suppose but I think I probably need more clarification on who the
properties are supposed to be exposed to/etc..
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
That's the opposite of the functionality I want. These are not PER
request. They are per instance of a component. Thus true instance
variables are the way to go. Tapestry recycles Components and it seems that
within a request the same component is re-used but not cleared (ivars reset)
even though it is re-parametrized. So, I don't think request vars would
work.
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: andyhot [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 12:35 AM
To: Tapestry users
Subject: Re: How to observe property binding events
Why store them in local variables?
Store it in the current request cycle...
First do a cycle.getAttribute("myexpensivevar") if that returns null, do
the computations and store the result back cycle.setAttribute
("myexpensivevar",obj);
See
http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapestry/IRequestCycle.html
Epstein, Ezra wrote:
> OK, let's get to brass tacks.
>
> I have some derived values that are somewhat expensive to compute so I
compute them once per request/response cycle and then they're in local
instance variables (non-persisted).
>
> The particular component in question (with the semi-expensive derived
values) is used inside a loop and so may appear multiple times on a
page. By default the first time I use the component I compute the value and
then display from that computed value... The 2nd, 3rd, etc instance of
those component on the page is actually the exact same Java instance and so
the computed/derived ivar is still set. I've added a hack that records an
original property value when the derived ivar is computed and if the
original and current property values don't match I reset the derived
ivar. It works, but it a total hack.
>
> The common way I'd imagine doing it is to listen to when the property
(parameter) is set by Tapestry. But now that I've lain out the use case
maybe some knows the "right" way to do this in Tapestry.
>
>
> Thanks,
>
> Ezra Epstein
>
>
> -----Original Message-----
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 09, 2006 3:33 PM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> There's also the org.apache.tapestry.event.ChangeObserver interface,
> though this is currently only used by the services in tapestry.persist
> to observe page property changes when they are being managed via a
> particular persistence strategy. (like session/client/etc..)
>
> ~Maybe~ it's an oversight, and maybe not..I guess that depends on
what/why you are trying to do. You'll find that there is very little in the
framework that wasn't put there for an actual need, so adding in support for
things that no one has needed yet doesn't seem to fall in line with sound
design.
> (imho of course..)
>
> If you can outline why you need this, and exactly what
properties/conditions you'd want to observe we might be able to work
something out...A general "anything" is harder to understand / design
around.
>
> There is no such thing as a "parameter" property listener because
parameters have no meaning in the context of something taking a
parameter...There has to be a source for that parameter value (usually a
page ) somewhere.
>
> On 10/9/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
>> Hi Jesse,
>>
>> Thanks for that reply.
>>
>> If I read it correctly, it sounds, simply, like the framework is
>> missing this feature. It's a pretty common thing to ask for listener
>> call-backs on framework events. ("Listener" here in the generic
>> sense rather than the way tapestry uses the term for direct-link
>> targets.) In short, this sounds like a design over-sight. It's
>> common when beans are bound to be able to receive a call-back --
>> Hibernate, for example, offers this. So much of Tapestry seems
>> "automagic" I'm surprised that there's no wa
RE: How to observe property binding events
That's the opposite of the functionality I want. These are not PER request.
They are per instance of a component. Thus true instance variables are the way
to go. Tapestry recycles Components and it seems that within a request the same
component is re-used but not cleared (ivars reset) even though it is
re-parametrized. So, I don't think request vars would work.
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: andyhot [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 12:35 AM
To: Tapestry users
Subject: Re: How to observe property binding events
Why store them in local variables?
Store it in the current request cycle...
First do a cycle.getAttribute("myexpensivevar") if that returns null, do the
computations and store the result back cycle.setAttribute("myexpensivevar",obj);
See
http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapestry/IRequestCycle.html
Epstein, Ezra wrote:
> OK, let's get to brass tacks.
>
> I have some derived values that are somewhat expensive to compute so I
> compute them once per request/response cycle and then they're in local
> instance variables (non-persisted).
>
> The particular component in question (with the semi-expensive derived values)
> is used inside a loop and so may appear multiple times on a page. By default
> the first time I use the component I compute the value and then display from
> that computed value... The 2nd, 3rd, etc instance of those component on the
> page is actually the exact same Java instance and so the computed/derived
> ivar is still set. I've added a hack that records an original property value
> when the derived ivar is computed and if the original and current property
> values don't match I reset the derived ivar. It works, but it a total hack.
>
> The common way I'd imagine doing it is to listen to when the property
> (parameter) is set by Tapestry. But now that I've lain out the use case
> maybe some knows the "right" way to do this in Tapestry.
>
>
> Thanks,
>
> Ezra Epstein
>
>
> -----Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 09, 2006 3:33 PM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> There's also the org.apache.tapestry.event.ChangeObserver interface,
> though this is currently only used by the services in tapestry.persist
> to observe page property changes when they are being managed via a
> particular persistence strategy. (like session/client/etc..)
>
> ~Maybe~ it's an oversight, and maybe not..I guess that depends on what/why
> you are trying to do. You'll find that there is very little in the framework
> that wasn't put there for an actual need, so adding in support for things
> that no one has needed yet doesn't seem to fall in line with sound design.
> (imho of course..)
>
> If you can outline why you need this, and exactly what properties/conditions
> you'd want to observe we might be able to work something out...A general
> "anything" is harder to understand / design around.
>
> There is no such thing as a "parameter" property listener because parameters
> have no meaning in the context of something taking a parameter...There has to
> be a source for that parameter value (usually a page ) somewhere.
>
> On 10/9/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
>> Hi Jesse,
>>
>> Thanks for that reply.
>>
>> If I read it correctly, it sounds, simply, like the framework is
>> missing this feature. It's a pretty common thing to ask for listener
>> call-backs on framework events. ("Listener" here in the generic
>> sense rather than the way tapestry uses the term for direct-link
>> targets.) In short, this sounds like a design over-sight. It's
>> common when beans are bound to be able to receive a call-back --
>> Hibernate, for example, offers this. So much of Tapestry seems
>> "automagic" I'm surprised that there's no way to register to be informed of
>> the events as they occur.
>>
>> If Howard's reading this perhaps he has a better perspective that he
>> may offer.
>>
>> Thanks,
>>
>> Ezra Epstein
>> Amazon.com - Developer Tools
>> 206-266-2259
>>
>>
>> -Original Message-
>> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 06, 2006 7:22 PM
>> To: Tapestry users
>> Subject: Re: How to observe property binding events
>>
>> Yes, but the usefulness of my answer largely depends on how
>
Re: How to observe property binding events
Why store them in local variables?
Store it in the current request cycle...
First do a cycle.getAttribute("myexpensivevar") if that returns null, do
the computations and store
the result back cycle.setAttribute("myexpensivevar",obj);
See
http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapestry/IRequestCycle.html
Epstein, Ezra wrote:
> OK, let's get to brass tacks.
>
> I have some derived values that are somewhat expensive to compute so I
> compute them once per request/response cycle and then they're in local
> instance variables (non-persisted).
>
> The particular component in question (with the semi-expensive derived values)
> is used inside a loop and so may appear multiple times on a page. By default
> the first time I use the component I compute the value and then display from
> that computed value... The 2nd, 3rd, etc instance of those component on the
> page is actually the exact same Java instance and so the computed/derived
> ivar is still set. I've added a hack that records an original property value
> when the derived ivar is computed and if the original and current property
> values don't match I reset the derived ivar. It works, but it a total hack.
>
> The common way I'd imagine doing it is to listen to when the property
> (parameter) is set by Tapestry. But now that I've lain out the use case
> maybe some knows the "right" way to do this in Tapestry.
>
>
> Thanks,
>
> Ezra Epstein
>
>
> -Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 09, 2006 3:33 PM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> There's also the org.apache.tapestry.event.ChangeObserver interface, though
> this is currently only used by the services in tapestry.persist to observe
> page property changes when they are being managed via a particular
> persistence strategy. (like session/client/etc..)
>
> ~Maybe~ it's an oversight, and maybe not..I guess that depends on what/why
> you are trying to do. You'll find that there is very little in the framework
> that wasn't put there for an actual need, so adding in support for things
> that no one has needed yet doesn't seem to fall in line with sound design.
> (imho of course..)
>
> If you can outline why you need this, and exactly what properties/conditions
> you'd want to observe we might be able to work something out...A general
> "anything" is harder to understand / design around.
>
> There is no such thing as a "parameter" property listener because parameters
> have no meaning in the context of something taking a parameter...There has to
> be a source for that parameter value (usually a page ) somewhere.
>
> On 10/9/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
>> Hi Jesse,
>>
>> Thanks for that reply.
>>
>> If I read it correctly, it sounds, simply, like the framework is
>> missing this feature. It's a pretty common thing to ask for listener
>> call-backs on framework events. ("Listener" here in the generic sense
>> rather than the way tapestry uses the term for direct-link targets.)
>> In short, this sounds like a design over-sight. It's common when
>> beans are bound to be able to receive a call-back -- Hibernate, for
>> example, offers this. So much of Tapestry seems "automagic" I'm
>> surprised that there's no way to register to be informed of the events as
>> they occur.
>>
>> If Howard's reading this perhaps he has a better perspective that he
>> may offer.
>>
>> Thanks,
>>
>> Ezra Epstein
>> Amazon.com - Developer Tools
>> 206-266-2259
>>
>>
>> -Original Message-
>> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 06, 2006 7:22 PM
>> To: Tapestry users
>> Subject: Re: How to observe property binding events
>>
>> Yes, but the usefulness of my answer largely depends on how
>> clever/efficient you are trying to be doing it.
>>
>> Now, there is IBinding. The one object to bind them all ;)
>>
>> If you work your way down the type hierarchy you'll find
>> AbstractBinding, which holds the method you care about most -
>> "setObject". This will be called by tapestry when managing all of the page
>> properties "automagically"
>> for you.
>>
>> Some of the magic happens in (for your exact case at least)
>> org.apache.tapestry.enhance.ParameterPropertyWorker.
>>
>> The other half of the work
RE: How to observe property binding events
Also, that title should have been "parameter binding events" not (generic)
property. The situation I have occurs when the framework sets the parameter on
a Component.
Thanks,
Ezra Epstein
-Original Message-
From: Epstein, Ezra [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 3:00 PM
To: Tapestry users
Subject: RE: How to observe property binding events
Hi Jesse,
Thanks for that reply.
If I read it correctly, it sounds, simply, like the framework is missing this
feature. It's a pretty common thing to ask for listener call-backs on
framework events. ("Listener" here in the generic sense rather than the way
tapestry uses the term for direct-link targets.) In short, this sounds like a
design over-sight. It's common when beans are bound to be able to receive a
call-back -- Hibernate, for example, offers this. So much of Tapestry seems
"automagic" I'm surprised that there's no way to register to be informed of the
events as they occur.
If Howard's reading this perhaps he has a better perspective that he may offer.
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Friday, October 06, 2006 7:22 PM
To: Tapestry users
Subject: Re: How to observe property binding events
Yes, but the usefulness of my answer largely depends on how clever/efficient
you are trying to be doing it.
Now, there is IBinding. The one object to bind them all ;)
If you work your way down the type hierarchy you'll find AbstractBinding, which
holds the method you care about most - "setObject". This will be called by
tapestry when managing all of the page properties "automagically"
for you.
Some of the magic happens in (for your exact case at least)
org.apache.tapestry.enhance.ParameterPropertyWorker.
The other half of the work happens in each specific binding implementation that
will handle these set/get object calls..(Like ognl bindings, etc..)
I'm not sure where you are going with this but I guess you could use the
hivemind chain of command service sort of configuration (like I did for
org.apache.tapestry.services.ComponentRenderWorker ) to generically call a
single interface method for a hivemind configuration point...Then you can
contribute as many workers into the chain you like if you decide that you have
more than one use for it.
Again...Not knowing what you are doing - and taking the exact parameters given
I'd probably extend and override the default ParameterPropertyWorker (a
hivemind service, so replacing it inline with what Tapestry does already should
be easy ) and just override whatever section of code I needed to in that
implementation to inject + call my service reference.
It may look a little complicated in there at first, but the whole
org.apache.tapestry.enhance package is filled with lots of different
enhancement works - and most of them inject a service into the object they work
on...So finding an easier to follow worker to reference before modifying
ParameterPropertyWorker might be easier.
Hope that helps.
On 10/6/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> I've got a component which accepts a parameter. I want to listen
> (receive a callback) when the parameter is set (bound). Does Tapestry
> provide such a facility?
>
> Thanks,
>
> Ezra Epstein
>
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
http://blog.opencomponentry.com
-
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: How to observe property binding events
OK, let's get to brass tacks.
I have some derived values that are somewhat expensive to compute so I compute
them once per request/response cycle and then they're in local instance
variables (non-persisted).
The particular component in question (with the semi-expensive derived values)
is used inside a loop and so may appear multiple times on a page. By default
the first time I use the component I compute the value and then display from
that computed value... The 2nd, 3rd, etc instance of those component on the
page is actually the exact same Java instance and so the computed/derived ivar
is still set. I've added a hack that records an original property value when
the derived ivar is computed and if the original and current property values
don't match I reset the derived ivar. It works, but it a total hack.
The common way I'd imagine doing it is to listen to when the property
(parameter) is set by Tapestry. But now that I've lain out the use case maybe
some knows the "right" way to do this in Tapestry.
Thanks,
Ezra Epstein
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Monday, October 09, 2006 3:33 PM
To: Tapestry users
Subject: Re: How to observe property binding events
There's also the org.apache.tapestry.event.ChangeObserver interface, though
this is currently only used by the services in tapestry.persist to observe page
property changes when they are being managed via a particular persistence
strategy. (like session/client/etc..)
~Maybe~ it's an oversight, and maybe not..I guess that depends on what/why you
are trying to do. You'll find that there is very little in the framework that
wasn't put there for an actual need, so adding in support for things that no
one has needed yet doesn't seem to fall in line with sound design.
(imho of course..)
If you can outline why you need this, and exactly what properties/conditions
you'd want to observe we might be able to work something out...A general
"anything" is harder to understand / design around.
There is no such thing as a "parameter" property listener because parameters
have no meaning in the context of something taking a parameter...There has to
be a source for that parameter value (usually a page ) somewhere.
On 10/9/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> Hi Jesse,
>
> Thanks for that reply.
>
> If I read it correctly, it sounds, simply, like the framework is
> missing this feature. It's a pretty common thing to ask for listener
> call-backs on framework events. ("Listener" here in the generic sense
> rather than the way tapestry uses the term for direct-link targets.)
> In short, this sounds like a design over-sight. It's common when
> beans are bound to be able to receive a call-back -- Hibernate, for
> example, offers this. So much of Tapestry seems "automagic" I'm
> surprised that there's no way to register to be informed of the events as
> they occur.
>
> If Howard's reading this perhaps he has a better perspective that he
> may offer.
>
> Thanks,
>
> Ezra Epstein
> Amazon.com - Developer Tools
> 206-266-2259
>
>
> -Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 06, 2006 7:22 PM
> To: Tapestry users
> Subject: Re: How to observe property binding events
>
> Yes, but the usefulness of my answer largely depends on how
> clever/efficient you are trying to be doing it.
>
> Now, there is IBinding. The one object to bind them all ;)
>
> If you work your way down the type hierarchy you'll find
> AbstractBinding, which holds the method you care about most -
> "setObject". This will be called by tapestry when managing all of the page
> properties "automagically"
> for you.
>
> Some of the magic happens in (for your exact case at least)
> org.apache.tapestry.enhance.ParameterPropertyWorker.
>
> The other half of the work happens in each specific binding
> implementation that will handle these set/get object calls..(Like ognl
> bindings, etc..)
>
> I'm not sure where you are going with this but I guess you could use
> the hivemind chain of command service sort of configuration (like I
> did for org.apache.tapestry.services.ComponentRenderWorker ) to
> generically call a single interface method for a hivemind
> configuration point...Then you can contribute as many workers into the
> chain you like if you decide that you have more than one use for it.
>
> Again...Not knowing what you are doing - and taking the exact
> parameters given I'd probably extend and override the default
> ParameterPropertyWorker (a hivemind service, so replacing it inline
>
Re: How to observe property binding events
There's also the org.apache.tapestry.event.ChangeObserver interface, though
this is currently only used by the services in tapestry.persist to observe
page property changes when they are being managed via a particular
persistence strategy. (like session/client/etc..)
~Maybe~ it's an oversight, and maybe not..I guess that depends on what/why
you are trying to do. You'll find that there is very little in the framework
that wasn't put there for an actual need, so adding in support for things
that no one has needed yet doesn't seem to fall in line with sound design.
(imho of course..)
If you can outline why you need this, and exactly what properties/conditions
you'd want to observe we might be able to work something out...A general
"anything" is harder to understand / design around.
There is no such thing as a "parameter" property listener because parameters
have no meaning in the context of something taking a parameter...There has
to be a source for that parameter value (usually a page ) somewhere.
On 10/9/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
Hi Jesse,
Thanks for that reply.
If I read it correctly, it sounds, simply, like the framework is missing
this feature. It's a pretty common thing to ask for listener call-backs on
framework events. ("Listener" here in the generic sense rather than the way
tapestry uses the term for direct-link targets.) In short, this sounds like
a design over-sight. It's common when beans are bound to be able to receive
a call-back -- Hibernate, for example, offers this. So much of Tapestry
seems "automagic" I'm surprised that there's no way to register to be
informed of the events as they occur.
If Howard's reading this perhaps he has a better perspective that he may
offer.
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Friday, October 06, 2006 7:22 PM
To: Tapestry users
Subject: Re: How to observe property binding events
Yes, but the usefulness of my answer largely depends on how
clever/efficient you are trying to be doing it.
Now, there is IBinding. The one object to bind them all ;)
If you work your way down the type hierarchy you'll find AbstractBinding,
which holds the method you care about most - "setObject". This will be
called by tapestry when managing all of the page properties "automagically"
for you.
Some of the magic happens in (for your exact case at least)
org.apache.tapestry.enhance.ParameterPropertyWorker.
The other half of the work happens in each specific binding implementation
that will handle these set/get object calls..(Like ognl bindings, etc..)
I'm not sure where you are going with this but I guess you could use the
hivemind chain of command service sort of configuration (like I did for
org.apache.tapestry.services.ComponentRenderWorker ) to generically call a
single interface method for a hivemind configuration point...Then you can
contribute as many workers into the chain you like if you decide that you
have more than one use for it.
Again...Not knowing what you are doing - and taking the exact parameters
given I'd probably extend and override the default ParameterPropertyWorker
(a hivemind service, so replacing it inline with what Tapestry does already
should be easy ) and just override whatever section of code I needed to in
that implementation to inject + call my service reference.
It may look a little complicated in there at first, but the whole
org.apache.tapestry.enhance package is filled with lots of different
enhancement works - and most of them inject a service into the object they
work on...So finding an easier to follow worker to reference before
modifying ParameterPropertyWorker might be easier.
Hope that helps.
On 10/6/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> I've got a component which accepts a parameter. I want to listen
> (receive a callback) when the parameter is set (bound). Does Tapestry
> provide such a facility?
>
> Thanks,
>
> Ezra Epstein
>
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
RE: How to observe property binding events
Hi Jesse,
Thanks for that reply.
If I read it correctly, it sounds, simply, like the framework is missing this
feature. It's a pretty common thing to ask for listener call-backs on
framework events. ("Listener" here in the generic sense rather than the way
tapestry uses the term for direct-link targets.) In short, this sounds like a
design over-sight. It's common when beans are bound to be able to receive a
call-back -- Hibernate, for example, offers this. So much of Tapestry seems
"automagic" I'm surprised that there's no way to register to be informed of the
events as they occur.
If Howard's reading this perhaps he has a better perspective that he may offer.
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Friday, October 06, 2006 7:22 PM
To: Tapestry users
Subject: Re: How to observe property binding events
Yes, but the usefulness of my answer largely depends on how clever/efficient
you are trying to be doing it.
Now, there is IBinding. The one object to bind them all ;)
If you work your way down the type hierarchy you'll find AbstractBinding, which
holds the method you care about most - "setObject". This will be called by
tapestry when managing all of the page properties "automagically"
for you.
Some of the magic happens in (for your exact case at least)
org.apache.tapestry.enhance.ParameterPropertyWorker.
The other half of the work happens in each specific binding implementation that
will handle these set/get object calls..(Like ognl bindings, etc..)
I'm not sure where you are going with this but I guess you could use the
hivemind chain of command service sort of configuration (like I did for
org.apache.tapestry.services.ComponentRenderWorker ) to generically call a
single interface method for a hivemind configuration point...Then you can
contribute as many workers into the chain you like if you decide that you have
more than one use for it.
Again...Not knowing what you are doing - and taking the exact parameters given
I'd probably extend and override the default ParameterPropertyWorker (a
hivemind service, so replacing it inline with what Tapestry does already should
be easy ) and just override whatever section of code I needed to in that
implementation to inject + call my service reference.
It may look a little complicated in there at first, but the whole
org.apache.tapestry.enhance package is filled with lots of different
enhancement works - and most of them inject a service into the object they work
on...So finding an easier to follow worker to reference before modifying
ParameterPropertyWorker might be easier.
Hope that helps.
On 10/6/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> I've got a component which accepts a parameter. I want to listen
> (receive a callback) when the parameter is set (bound). Does Tapestry
> provide such a facility?
>
> Thanks,
>
> Ezra Epstein
>
>
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
http://blog.opencomponentry.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to observe property binding events
Yes, but the usefulness of my answer largely depends on how clever/efficient you are trying to be doing it. Now, there is IBinding. The one object to bind them all ;) If you work your way down the type hierarchy you'll find AbstractBinding, which holds the method you care about most - "setObject". This will be called by tapestry when managing all of the page properties "automagically" for you. Some of the magic happens in (for your exact case at least) org.apache.tapestry.enhance.ParameterPropertyWorker. The other half of the work happens in each specific binding implementation that will handle these set/get object calls..(Like ognl bindings, etc..) I'm not sure where you are going with this but I guess you could use the hivemind chain of command service sort of configuration (like I did for org.apache.tapestry.services.ComponentRenderWorker ) to generically call a single interface method for a hivemind configuration point...Then you can contribute as many workers into the chain you like if you decide that you have more than one use for it. Again...Not knowing what you are doing - and taking the exact parameters given I'd probably extend and override the default ParameterPropertyWorker (a hivemind service, so replacing it inline with what Tapestry does already should be easy ) and just override whatever section of code I needed to in that implementation to inject + call my service reference. It may look a little complicated in there at first, but the whole org.apache.tapestry.enhance package is filled with lots of different enhancement works - and most of them inject a service into the object they work on...So finding an easier to follow worker to reference before modifying ParameterPropertyWorker might be easier. Hope that helps. On 10/6/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: I've got a component which accepts a parameter. I want to listen (receive a callback) when the parameter is set (bound). Does Tapestry provide such a facility? Thanks, Ezra Epstein -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
