Canonical usage pattern for event listeners

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Canonical usage pattern for event listeners

Werner Thie
Aloha

what is the common usage pattern with event listeners attached to elements?

Googling reveals examples with popup menues using addListenerOnce() vs
others using addListener(), the addListenerOnce case seemingly trying to
avoid the problem of handling the listener removal automatically, which
does not make sense because only one of the several menu items involved
will fire and then be subsequentally removed.

Too bad, that the documentation (or at least what I was able to find)
does not provide a canonical pattern for event listeners.

The documentation of addListener()'s return value says:

An opaque ID, which CAN be used to remove the event listener using the
#removeListenerById method

(emphasis added)

After browsing the source I'm pretty much inclined to say, that event
listeners MUST be released by whoever added them.

May I humbly ask for a clarification of this matter, mahalo!

Werner

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Canonical usage pattern for event listeners

John Spackman-3
Making it so that the class that adds the listener is the class that
removes it is pretty sound advice; if you dispose an object which you have
added listeners to then those listeners will be automatically disposed,
which can save you some work.

addListenerOnce is designed for events you want to only use once, EG
addListenerOnce(³appear²...) fires the first time an object appears (I
often use that to initialise the UI or get data from the server)

When the docs say "the opaque ID CAN be used...² means that you have a
choice: either (a) you can remove listeners by passing the same parameters
to removeListener as you gave to addListener (ie the name, the callback,
and the context), or (b) pass the opaque ID to removeListenerById.

John

On 22/07/2015 18:08, "Werner Thie" <[hidden email]> wrote:

>Aloha
>
>what is the common usage pattern with event listeners attached to
>elements?
>
>Googling reveals examples with popup menues using addListenerOnce() vs
>others using addListener(), the addListenerOnce case seemingly trying to
>avoid the problem of handling the listener removal automatically, which
>does not make sense because only one of the several menu items involved
>will fire and then be subsequentally removed.
>
>Too bad, that the documentation (or at least what I was able to find)
>does not provide a canonical pattern for event listeners.
>
>The documentation of addListener()'s return value says:
>
>An opaque ID, which CAN be used to remove the event listener using the
>#removeListenerById method
>
>(emphasis added)
>
>After browsing the source I'm pretty much inclined to say, that event
>listeners MUST be released by whoever added them.
>
>May I humbly ask for a clarification of this matter, mahalo!
>
>Werner
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>qooxdoo-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Canonical usage pattern for event listeners

Werner Thie
Hello John

Thanks for clarifying this. Just wanted to make sure I'm not ending up
with huge amounts of stale objects not being collectable because of not
removed event listeners keeping them around.

Werner

On 7/22/15 9:48 PM, John Spackman wrote:

> Making it so that the class that adds the listener is the class that
> removes it is pretty sound advice; if you dispose an object which you have
> added listeners to then those listeners will be automatically disposed,
> which can save you some work.
>
> addListenerOnce is designed for events you want to only use once, EG
> addListenerOnce(³appear²...) fires the first time an object appears (I
> often use that to initialise the UI or get data from the server)
>
> When the docs say "the opaque ID CAN be used...² means that you have a
> choice: either (a) you can remove listeners by passing the same parameters
> to removeListener as you gave to addListener (ie the name, the callback,
> and the context), or (b) pass the opaque ID to removeListenerById.
>
> John
>
> On 22/07/2015 18:08, "Werner Thie" <[hidden email]> wrote:
>
>> Aloha
>>
>> what is the common usage pattern with event listeners attached to
>> elements?
>>
>> Googling reveals examples with popup menues using addListenerOnce() vs
>> others using addListener(), the addListenerOnce case seemingly trying to
>> avoid the problem of handling the listener removal automatically, which
>> does not make sense because only one of the several menu items involved
>> will fire and then be subsequentally removed.
>>
>> Too bad, that the documentation (or at least what I was able to find)
>> does not provide a canonical pattern for event listeners.
>>
>> The documentation of addListener()'s return value says:
>>
>> An opaque ID, which CAN be used to remove the event listener using the
>> #removeListenerById method
>>
>> (emphasis added)
>>
>> After browsing the source I'm pretty much inclined to say, that event
>> listeners MUST be released by whoever added them.
>>
>> May I humbly ask for a clarification of this matter, mahalo!
>>
>> Werner
>>
>> --------------------------------------------------------------------------
>> ----
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel