RE: Tapestry page (and other) event listeners
I declared the proper interface as being implemented and that was all that was
needed. Works on components.
Thanks,
Ezra Epstein
-Original Message-
From: andyhot [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 5:08 PM
To: Tapestry users
Subject: Re: Tapestry page (and other) event listeners
Jesse Kuhnert wrote:
> I don't remember whether or not Page listeners get attached to
> components or not. It doesn't sound like something that would make
> sense, but who knows..
They do get attached to components...
but i'm under the impression that your page also has to implement
PageBeginRenderListener for this to work...
Additionally,if you use Blocks from other pages, take a look at this entry:
http://jroller.com/page/genjitsuteki?entry=tapestry_avoid_pagerenderlistener
>
> For "components" specifically, you also have the other options
> involved,
> like:
>
> (from
> http://tapestry.apache.org/tapestry4.1/target/site/tapestry-framework/
> apidocs/org/apache/tapestry/AbstractComponent.html)
>
>
> finishLoad
> prepareForRender
> renderComponent
>
>
>
> On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>>
>> A-ha! So if I have a component that implements this that component
>> will auto-magically be registered and receive the call-back?
>>
>>
>> Thanks,
>>
>> Ezra Epstein
>> Amazon.com - Developer Tools
>> 206-266-2259
>>
>>
>> -----Original Message-
>> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, October 10, 2006 4:32 PM
>> To: Tapestry users
>> Subject: Re: Tapestry page (and other) event listeners
>>
>> I'd have to dig into the code to be sure I understood all points but
>> I don't think addPageBeginRenderListener is called by user code most
>> of the time. ..
>>
>> If you page implements one of the various Listener classes (like umm...
>> PageBeginRenderListener) - the framework will detect it and perform
>> the necessary registrations for you automatically when it enhances
>> the page class the first time.
>>
>> On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>> >
>> > The common idiom for listener registration (Swing, Java Beans,
>> > etc.) is that the remove() method returns the listener and the
>> > add() method only adds a listener if it's not already listening.
>> > Tapestry's impl follows neither of these approaches. Is there a
>> > reason for the naïve implementation of the methods like
>> >
>> > void addPageBeginRenderListener(PageBeginRenderListener listener)
>> >
>> > ? A LinkedHashSet() would give the ordering of the current
>> > ArrayList implementation plus the uniquing properties of a set...
>> >
>> > 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
Re: Tapestry page (and other) event listeners
Jesse Kuhnert wrote:
> I don't remember whether or not Page listeners get attached to
> components or
> not. It doesn't sound like something that would make sense, but who
> knows..
They do get attached to components...
but i'm under the impression that your page also has to
implement PageBeginRenderListener for this to work...
Additionally,if you use Blocks from other pages, take a look at this entry:
http://jroller.com/page/genjitsuteki?entry=tapestry_avoid_pagerenderlistener
>
> For "components" specifically, you also have the other options involved,
> like:
>
> (from
> http://tapestry.apache.org/tapestry4.1/target/site/tapestry-framework/apidocs/org/apache/tapestry/AbstractComponent.html)
>
>
> finishLoad
> prepareForRender
> renderComponent
>
>
>
> On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>>
>> A-ha! So if I have a component that implements this that component will
>> auto-magically be registered and receive the call-back?
>>
>>
>> Thanks,
>>
>> Ezra Epstein
>> Amazon.com - Developer Tools
>> 206-266-2259
>>
>>
>> -Original Message-----
>> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, October 10, 2006 4:32 PM
>> To: Tapestry users
>> Subject: Re: Tapestry page (and other) event listeners
>>
>> I'd have to dig into the code to be sure I understood all points but I
>> don't think addPageBeginRenderListener is called by user code most of
>> the
>> time. ..
>>
>> If you page implements one of the various Listener classes (like umm...
>> PageBeginRenderListener) - the framework will detect it and perform the
>> necessary registrations for you automatically when it enhances the page
>> class the first time.
>>
>> On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>> >
>> > The common idiom for listener registration (Swing, Java Beans, etc.)
>> > is that the remove() method returns the listener and the add() method
>> > only adds a listener if it's not already listening. Tapestry's impl
>> > follows neither of these approaches. Is there a reason for the naïve
>> > implementation of the methods like
>> >
>> > void addPageBeginRenderListener(PageBeginRenderListener listener)
>> >
>> > ? A LinkedHashSet() would give the ordering of the current ArrayList
>> > implementation plus the uniquing properties of a set...
>> >
>> > 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
>> > >
>> > >
>> > &g
Re: Tapestry page (and other) event listeners
I don't remember whether or not Page listeners get attached to components or
not. It doesn't sound like something that would make sense, but who knows..
For "components" specifically, you also have the other options involved,
like:
(from
http://tapestry.apache.org/tapestry4.1/target/site/tapestry-framework/apidocs/org/apache/tapestry/AbstractComponent.html)
finishLoad
prepareForRender
renderComponent
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
A-ha! So if I have a component that implements this that component will
auto-magically be registered and receive the call-back?
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 4:32 PM
To: Tapestry users
Subject: Re: Tapestry page (and other) event listeners
I'd have to dig into the code to be sure I understood all points but I
don't think addPageBeginRenderListener is called by user code most of the
time. ..
If you page implements one of the various Listener classes (like umm...
PageBeginRenderListener) - the framework will detect it and perform the
necessary registrations for you automatically when it enhances the page
class the first time.
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> The common idiom for listener registration (Swing, Java Beans, etc.)
> is that the remove() method returns the listener and the add() method
> only adds a listener if it's not already listening. Tapestry's impl
> follows neither of these approaches. Is there a reason for the naïve
> implementation of the methods like
>
> void addPageBeginRenderListener(PageBeginRenderListener listener)
>
> ? A LinkedHashSet() would give the ordering of the current ArrayList
> implementation plus the uniquing properties of a set...
>
> 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/tap
> > es
> > 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 compon
RE: Tapestry page (and other) event listeners
A-ha! So if I have a component that implements this that component will
auto-magically be registered and receive the call-back?
Thanks,
Ezra Epstein
Amazon.com - Developer Tools
206-266-2259
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 4:32 PM
To: Tapestry users
Subject: Re: Tapestry page (and other) event listeners
I'd have to dig into the code to be sure I understood all points but I don't
think addPageBeginRenderListener is called by user code most of the time. ..
If you page implements one of the various Listener classes (like umm...
PageBeginRenderListener) - the framework will detect it and perform the
necessary registrations for you automatically when it enhances the page class
the first time.
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> The common idiom for listener registration (Swing, Java Beans, etc.)
> is that the remove() method returns the listener and the add() method
> only adds a listener if it's not already listening. Tapestry's impl
> follows neither of these approaches. Is there a reason for the naïve
> implementation of the methods like
>
> void addPageBeginRenderListener(PageBeginRenderListener listener)
>
> ? A LinkedHashSet() would give the ordering of the current ArrayList
> implementation plus the uniquing properties of a set...
>
> 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/tap
> > es
> > 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'
Re: Tapestry page (and other) event listeners
I'd have to dig into the code to be sure I understood all points but I don't
think addPageBeginRenderListener is called by user code most of the time. ..
If you page implements one of the various Listener classes (like umm...
PageBeginRenderListener) - the framework will detect it and perform the
necessary registrations for you automatically when it enhances the page
class the first time.
On 10/10/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
The common idiom for listener registration (Swing, Java Beans, etc.) is
that the remove() method returns the listener and the add() method only adds
a listener if it's not already listening. Tapestry's impl follows neither
of these approaches. Is there a reason for the naïve implementation of the
methods like
void addPageBeginRenderListener(PageBeginRenderListener listener)
? A LinkedHashSet() would give the ordering of the current ArrayList
implementation plus the uniquing properties of a set...
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
> propert
Tapestry page (and other) event listeners
The common idiom for listener registration (Swing, Java Beans, etc.) is that
the remove() method returns the listener and the add() method only adds a
listener if it's not already listening. Tapestry's impl follows neither of
these approaches. Is there a reason for the naïve implementation of the
methods like
void addPageBeginRenderListener(PageBeginRenderListener listener)
? A LinkedHashSet() would give the ordering of the current ArrayList
implementation plus the uniquing properties of a set...
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 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
