Managing subscriptions to q.e.message.Bus

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

Managing subscriptions to q.e.message.Bus

Werner Thie
Hi all

what's the envisioned pattern for managing subscriptions, where a lot of
participating objects distributed among a hierarchy do
subscribe/unsubscribe a lot to the bus (say for a simple status change)

var bus = qx.event.message.Bus.getInstance();
bus.subscribe("statuschange", function(e) {
     //do some status changing
   }
}, this);
    :
    :
bus.unsubscribe(???);

With this elegant registration I completely lose the possibility to
unsubscribe, the function has be to be defined locally in some embracing
function, such that I can pass the proper params to unsubscribe, namely
(message, subscriber, context), with subscriber being the function.

var bus = qx.event.message.Bus.getInstance();
function status(e) {
     //do some status changing
}

bus.subscribe("statuschange", status, this);
    :
    :
bus.unsubscribe("statuschange", status, this);

Now, what's the reason for not passing back a unique key when
subscribing, which could be used as a weak link to the subscription and
thus passed to unsubscribe to allow for a coding style like

var bus = qx.event.message.Bus.getInstance();
var sub = bus.subscribe("statuschange", function(e) {
     //do some status changing
   }
}, this);
    :
    :
bus.unsubscribe(sub);

Thxs for enlightening me, I might be groping for something obvious,
which I simply do not see.

Werner




------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Managing subscriptions to q.e.message.Bus

Romeo Kenfack Tsakem
Hi Werner,

you are right, passing back a unique key when subscribing could be an enhancement.
Please open a bug and we will have a look into it.

Regards,
Romeo

-----Ursprüngliche Nachricht-----
Von: Werner Thie [mailto:[hidden email]]
Gesendet: Sonntag, 31. März 2013 19:42
An: qooxdoo Development
Betreff: [qooxdoo-devel] Managing subscriptions to q.e.message.Bus

Hi all

what's the envisioned pattern for managing subscriptions, where a lot of participating objects distributed among a hierarchy do subscribe/unsubscribe a lot to the bus (say for a simple status change)

var bus = qx.event.message.Bus.getInstance();
bus.subscribe("statuschange", function(e) {
     //do some status changing
   }
}, this);
    :
    :
bus.unsubscribe(???);

With this elegant registration I completely lose the possibility to unsubscribe, the function has be to be defined locally in some embracing function, such that I can pass the proper params to unsubscribe, namely (message, subscriber, context), with subscriber being the function.

var bus = qx.event.message.Bus.getInstance();
function status(e) {
     //do some status changing
}

bus.subscribe("statuschange", status, this);
    :
    :
bus.unsubscribe("statuschange", status, this);

Now, what's the reason for not passing back a unique key when subscribing, which could be used as a weak link to the subscription and thus passed to unsubscribe to allow for a coding style like

var bus = qx.event.message.Bus.getInstance();
var sub = bus.subscribe("statuschange", function(e) {
     //do some status changing
   }
}, this);
    :
    :
bus.unsubscribe(sub);

Thxs for enlightening me, I might be groping for something obvious, which I simply do not see.

Werner




------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Managing subscriptions to q.e.message.Bus

Werner Thie
On 4/2/13 9:44 AM, Romeo Kenfack Tsakem wrote:

> Hi Werner,
>
> you are right, passing back a unique key when subscribing could be an enhancement.
> Please open a bug and we will have a look into it.
>
> Regards,
> Romeo
>
> -----Ursprüngliche Nachricht-----
> Von: Werner Thie [mailto:[hidden email]]
> Gesendet: Sonntag, 31. März 2013 19:42
> An: qooxdoo Development
> Betreff: [qooxdoo-devel] Managing subscriptions to q.e.message.Bus
>
> Hi all
>
> what's the envisioned pattern for managing subscriptions, where a lot of participating objects distributed among a hierarchy do subscribe/unsubscribe a lot to the bus (say for a simple status change)
>
> var bus = qx.event.message.Bus.getInstance();
> bus.subscribe("statuschange", function(e) {
>       //do some status changing
>     }
> }, this);
>      :
>      :
> bus.unsubscribe(???);
>
> With this elegant registration I completely lose the possibility to unsubscribe, the function has be to be defined locally in some embracing function, such that I can pass the proper params to unsubscribe, namely (message, subscriber, context), with subscriber being the function.
>
> var bus = qx.event.message.Bus.getInstance();
> function status(e) {
>       //do some status changing
> }
>
> bus.subscribe("statuschange", status, this);
>      :
>      :
> bus.unsubscribe("statuschange", status, this);
>
> Now, what's the reason for not passing back a unique key when subscribing, which could be used as a weak link to the subscription and thus passed to unsubscribe to allow for a coding style like
>
> var bus = qx.event.message.Bus.getInstance();
> var sub = bus.subscribe("statuschange", function(e) {
>       //do some status changing
>     }
> }, this);
>      :
>      :
> bus.unsubscribe(sub);
>
> Thxs for enlightening me, I might be groping for something obvious, which I simply do not see.
>
> Werner
Hi

I'm currently using the attached solution

Thxs, Werner



------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

idbus.js (11K) Download Attachment