AS3 Signals Bubbling note
Sunday, March 07th, 2010 | Author: dehash
Working with this now and just a note that it looks like a way to bubble Signals from a nested display class is as follows:
public var deluxeSignal:DeluxeSignal = new DeluxeSignal(this);
…
deluxeSignal.dispatch(new GenericEvent(true));
and the listening class further up the display list implements IBubbleEventHandler and requires the following method:
public function onEventBubbled(e:IEvent):void {
trace(e +"-"+ e.target +"-"+ e.currentTarget +"-"+ e.signal);
}
- – -
Added a quick example below with source code using the current signals release unedited
here
PS there is an excellent Signals video tutorial here
- – -
Update: Added a new version of the simple example that works with the latest Signals release (0.7). The onEventBubbled method now has a boolean return value to determine whether to continue bubbling or stop.
The new example code can be downloaded here
- – -
Some ideas on passing parameters:
var deluxeSignal:DeluxeSignal = new DeluxeSignal(this);
deluxeSignal.dispatch(new GenericEvent(true));
Here you are passing “this”, ie the sending instance, as the GenericEvent event target so that it is available as the event.target within onEventBubbled(event:IEvent).
Alternately pass in a Value Object (VO) instead of “this” to pass more precise and data typed parameters (you would need to give it a “parent” property) or another option is to extend GenericEvent and give it some custom properties which can be read within onEventBubbled.



That’s really cool you can do this with Signals. I’ve loved working with Signals because of how much less code it requires to dispatch notifications. The only thing I’m having a hard time understanding is what the benefit of bubbling a signal is? Wouldn’t it be easier to bubble a normal event?
Thanks, I wasn’t sure how to achieve bubbling using Signals. I’m still not sure how you can send data along with the event though. Any ideas?
@Kipp
I am learning about it myself now but I think you could use Signals bubbling wherever you would use Event bubbling – so for example when you have a deeply nested dynamically generated sprite which needs to communicate with its parent component that type of thing. One place where Signal bubbling looks to have an advantage is that it seems it is not limited to display classes – so you can bubble through regular classes if you set a parent property on them. From what I have read though it is still a bit experimental and so it might be easier to use events but it is interesting to have the choice now.
@Jon
Yes the ‘this’ in “new DeluxeSignal(this);” when I used it passes through the sending instance as the target so in the listener function e.target is a reference to the sending instance. So you could read off any data from that but there are probably better ways and I want to find them myself too. One other thing is that in my test the bubbling stops after finding the first class that implements IBubbleEventHandler but that should not usually be a problem and you could redispatch it if needed.
Thats right I forgot that “this” was a param of DeluxeSignal.
thank you!
@Jon
Yes that is right – I got thrown by that myself for a while. Might also be an idea set a VO as the target as an alternative. Give it a parent property and then you get a strongly typed and more logical set of values passed to e.target than “this” will send. Might also help differentiate which event is bubbling if there is more than one. May try that out in a RobotLegs project to see how it goes.
Not being able to bubble signals to more than just the immediate
parent is a show stopper for me…since I rely heavily on bubbling in
all my projects.
Anyone have a workaround?
@eco_bach
I think you have it wrong – you can bubble a signal beyond its immediate parent and all the way up the display list using the approach described above. If you try it out for yourself you can see it working and whether it ticks all the boxes you need.
Check out secoif’s approach where he adds a Boolean return value from
onEventBubbled():
http://github.com/secoif/as3-signals/commit/770f6c8c0a36025355c00109d9e1793e186a22eb
I have a TODO comment in my DeluxeSignal code that refers to this (line 161).
Robert
@Robert
Had a go at integrating the secoif changes with the current signals src and initial test works with a simple example. For now I zipped up signalssecoif.zip here in case anyone wants to see it.
Thanks dehash, I integrated this into the v0.7 release. Changelog here:
http://github.com/robertpenner/as3-signals/blob/master/CHANGELOG.textile
@Robert
Cool. I updated the simple example above to use 0.7 and it worked. Added a download for the updated code above at the foot of the original blog post.
Hi All,
I played with this approach and it works well. I am enjoying Signals very much. Learning a lot too!
There are 2 things I find myself needing in some scenarios when bubbling and wanted to know if they are valid needs or is there a better model I could be using.
1. Ability to pass along some params with the bubbling event.
For example this would be useful for a tooltip class that lives in your document class. Dispatch a signal from anywhere in your app and send along the tooltip string for display.
2. Would be nice to listen for a specific bubbling event as opposed to listening for all bubbling events and then checking to see if it’s the event you wanted.
For example a single onEventBubbled handler may find one event to show a tooltip and another to tell when an animation is finished.
Using a single handler for all bubbling events would require me identify every event bubbling through the chain – then either kill it and handle it or let it move on by. Would we need to re-dispatch unwanted bubbling events? Would this slow things down if there was an onEventBubbled handler on every level up the chain?
Thanks!
@Will
I would defer to Penner the Signals main author for a definitive answer but I think a lot of what you have asked is open for discussion. So if you have an idea for implementation it is worth pursuing to see how well it works and what others think.
Regarding tooltips yes you could use Signals for that and bubble from the Sprite to the document class as you say. It is not that different to the example movie posted above. Using that approach might not scale well though so for larger projects though I would recommend using Signals within a structure like RobotLegs.
Passing params is referenced a little above and there are at least three methods using the existing Signals source code: Passing “this”, passing a VO, extending GenericEvent.