RE: [Flashcoders] bubbling listening
@Jason, Hi Jason, Some time ago I ask if someone could explain the MVC-pattern with a example. Not using any frameworks which are already out there, but just to learn it myself. You offered, if your kid give you a night sleep, to get back on this someday. I can imagine you forgot, so if you allow me, I would kindly like to remember you. And if you can find the time for it... I, and it seems a few others, would highly appreciate it. Kind regards Cor -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: donderdag 18 maart 2010 15:51 To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mendelsohn, Michael Sent: Thursday, March 18, 2010 10:47 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Yes, I suspected I've been touching on MVC. I'm not that sophisticated in my design pattern usage yet. I will get there though. Thanks for the follow up responses Jason. I really appreciate the feedback. - Michael M. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? See the example I posted - you just have to extend on it. If you choose MVC as a pattern like I like to do, you have a controller class which listens to display objects and has handlers to uh, handle them. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Geen virus gevonden in het binnenkomende-bericht. Gecontroleerd door AVG - www.avg.com Versie: 9.0.791 / Virusdatabase: 271.1.1/2755 - datum van uitgifte: 03/18/10 20:33:00 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] bubbling listening
Essential AS 2.0 has a MVC example (in AS 2, of course). In MVC, the model essentially encapsulates the state of the application. The model provides methods that the controller(s) invoke to change the state. The model also handles system events that cause a state change (i.e. timer event). Each controller implements the business logic of the application. For example, on a calendar application, clicking the next button means go to the next day, week, month, year depending upon the screen. A click on the previous button means similar. There could be 4 controllers (day, week, month, year) each having a next and a previous function. The controller then invokes a method on the model to cause a state change - Day controller next function could invoke updateDay(+1) on model while the Week controller next function could invoke updateDay(+7) on model. The previous method on same controllers could invoke updateDay(-1) or updateDay(-7). After a change in state, the model informs all views of the change in state. The model can include the state change in the notification (model pushes the data out) or the model can require that the view ask for the information (views must pull the data out). The view responds to the notification by updating the presentation to the user (if needed). HTH Jim From: Mattheis, Erik (MIN - WSW) ematth...@webershandwick.com To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Thu, March 18, 2010 5:42:42 PM Subject: RE: [Flashcoders] bubbling listening I've been thinking about the below message from Jason and tried rearranging a simple project into a MVC for a while this afternoon, but couldn't figure out how to do it without breaking encapsulation. I think I'm not getting the MVC advantage because I don't understand one of two things - or maybe something else: The controller listens to an event from the model, how does the controller inform the view to react without a) breaking encapsulation or b)dispatching another event the view is listening for. In b it would seem better to me to have the view listen to the model directly. I tried it both with the controller being the document class and not. Help? Is there a simple example someone can point me to? _ _ _ Erik Mattheis Senior Web Developer Minneapolis T 952 346 6610 C 612 377 2272 Weber Shandwick Advocacy starts here. PRWeek Global Agency Report Card 2009 - Gold Medal Winner The Holmes Report Global Agency of the Year PR News Agency of the Year -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: Thursday, March 18, 2010 9:51 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
Thanks for the responses everyone! Yes, and what I am saying is, that architecture is wrong. You don't create instances of EventDispatcher and then put Display object inside of them. OK, it seems I've violated a golden rule about bubbling. My EventDispatcher obviously isn't on the display list, so it's the end of the road for that Sprite's event. For this project, I am passing along a custom event object like a hot potato, however inefficiently. Live and learn. But, there's a broader question I'd like to ask. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? See the example I posted - you just have to extend on it. If you choose MVC as a pattern like I like to do, you have a controller class which listens to display objects and has handlers to uh, handle them. Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mendelsohn, Michael Sent: Thursday, March 18, 2010 10:32 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Thanks for the responses everyone! Yes, and what I am saying is, that architecture is wrong. You don't create instances of EventDispatcher and then put Display object inside of them. OK, it seems I've violated a golden rule about bubbling. My EventDispatcher obviously isn't on the display list, so it's the end of the road for that Sprite's event. For this project, I am passing along a custom event object like a hot potato, however inefficiently. Live and learn. But, there's a broader question I'd like to ask. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
Yes, I suspected I've been touching on MVC. I'm not that sophisticated in my design pattern usage yet. I will get there though. Thanks for the follow up responses Jason. I really appreciate the feedback. - Michael M. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? See the example I posted - you just have to extend on it. If you choose MVC as a pattern like I like to do, you have a controller class which listens to display objects and has handlers to uh, handle them. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mendelsohn, Michael Sent: Thursday, March 18, 2010 10:47 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Yes, I suspected I've been touching on MVC. I'm not that sophisticated in my design pattern usage yet. I will get there though. Thanks for the follow up responses Jason. I really appreciate the feedback. - Michael M. In my project, this EventDispatcher managing all the Sprites. Is there a better way of managing all the displayObjects from one class, other than having instructions come from an EventDispatcher? See the example I posted - you just have to extend on it. If you choose MVC as a pattern like I like to do, you have a controller class which listens to display objects and has handlers to uh, handle them. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
I've been thinking about the below message from Jason and tried rearranging a simple project into a MVC for a while this afternoon, but couldn't figure out how to do it without breaking encapsulation. I think I'm not getting the MVC advantage because I don't understand one of two things - or maybe something else: The controller listens to an event from the model, how does the controller inform the view to react without a) breaking encapsulation or b)dispatching another event the view is listening for. In b it would seem better to me to have the view listen to the model directly. I tried it both with the controller being the document class and not. Help? Is there a simple example someone can point me to? _ _ _ Erik Mattheis Senior Web Developer Minneapolis T 952 346 6610 C 612 377 2272 Weber Shandwick Advocacy starts here. PRWeek Global Agency Report Card 2009 - Gold Medal Winner The Holmes Report Global Agency of the Year PR News Agency of the Year -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: Thursday, March 18, 2010 9:51 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
The view would have public methods the controller calls. The views retain their encapsulation/loose coupling as does the model. The controller however, is tied into calling specific methods on views - so it's tightly coupled. There are patterns to break this down further (i.e. Cairngorm uses Commands) - but I usually don't care if the controller has to call specific public methods on views. That's my take anyway, there are others that are far better at abstracting this than I am and certainly there are a million ways to skin a cat. Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mattheis, Erik (MIN - WSW) Sent: Thursday, March 18, 2010 5:43 PM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening I've been thinking about the below message from Jason and tried rearranging a simple project into a MVC for a while this afternoon, but couldn't figure out how to do it without breaking encapsulation. I think I'm not getting the MVC advantage because I don't understand one of two things - or maybe something else: The controller listens to an event from the model, how does the controller inform the view to react without a) breaking encapsulation or b)dispatching another event the view is listening for. In b it would seem better to me to have the view listen to the model directly. I tried it both with the controller being the document class and not. Help? Is there a simple example someone can point me to? _ _ _ Erik Mattheis Senior Web Developer Minneapolis T 952 346 6610 C 612 377 2272 Weber Shandwick Advocacy starts here. PRWeek Global Agency Report Card 2009 - Gold Medal Winner The Holmes Report Global Agency of the Year PR News Agency of the Year -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: Thursday, March 18, 2010 9:51 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
Ah, I was trying to do it without public methods or variables, just passing things around through custom events. _ _ _ Erik Mattheis Senior Web Developer Minneapolis T 952 346 6610 C 612 377 2272 Weber Shandwick Advocacy starts here. PRWeek Global Agency Report Card 2009 - Gold Medal Winner The Holmes Report Global Agency of the Year PR News Agency of the Year -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: Thursday, March 18, 2010 4:49 PM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening The view would have public methods the controller calls. The views retain their encapsulation/loose coupling as does the model. The controller however, is tied into calling specific methods on views - so it's tightly coupled. There are patterns to break this down further (i.e. Cairngorm uses Commands) - but I usually don't care if the controller has to call specific public methods on views. That's my take anyway, there are others that are far better at abstracting this than I am and certainly there are a million ways to skin a cat. Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mattheis, Erik (MIN - WSW) Sent: Thursday, March 18, 2010 5:43 PM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening I've been thinking about the below message from Jason and tried rearranging a simple project into a MVC for a while this afternoon, but couldn't figure out how to do it without breaking encapsulation. I think I'm not getting the MVC advantage because I don't understand one of two things - or maybe something else: The controller listens to an event from the model, how does the controller inform the view to react without a) breaking encapsulation or b)dispatching another event the view is listening for. In b it would seem better to me to have the view listen to the model directly. I tried it both with the controller being the document class and not. Help? Is there a simple example someone can point me to? _ _ _ Erik Mattheis Senior Web Developer Minneapolis T 952 346 6610 C 612 377 2272 Weber Shandwick Advocacy starts here. PRWeek Global Agency Report Card 2009 - Gold Medal Winner The Holmes Report Global Agency of the Year PR News Agency of the Year -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, Jason Sent: Thursday, March 18, 2010 9:51 AM To: Flash Coders List Subject: RE: [Flashcoders] bubbling listening Well, that's OK and you don't even have to get fancy yet - just write a class that has references to all the display objects, and listens to your custom events. It also has the handlers in it to respond to the events. This in effect, is a controller class. Jason Merrill ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
[Flashcoders] bubbling listening
Hi list... I have a singleton that contains an instance of an EventDispatcher. The EventDispatcher contains an instance of a sprite. I want that sprite to dispatch a custom event that is listened to by the singleton, but I can't seem to make it happen, even by saying bubbles = true. I could have a listener on the EventDispatcher, then dispatch another event going one level higher to the singleton, but I'm wondering if there's a way to bypass that sort of step by step architecture. I thought that within the singleton, I could have referred directly to the sprite itself within the EventDispatcher, but I have not been able to do that either. Any feedback is appreciated, thanks! - Michael M. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
What do you mean The EventDispatcher contains an instance of a sprite. Normally what you would do is not create an instance of EventDispatcher, but instead have your custom class extend Sprite (which already extends EventDispatcher anyway), have that sprite dispatch a custom event. Then have your class listen to the instance of that class for the custom event you dispatch. So in summary, you write an event class, dispatch that custom event from the sprite class (the custom class that extends sprite) and listen for that event on that instance in your Singleton (the fact that it's a Singleton should be irrelevant). Your singleton class then has a handler you write that runs when the event is heard. Make sense? Jason Merrill Bank of America Global Learning Learning Performance Solutions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Mendelsohn, Michael Sent: Wednesday, March 17, 2010 1:38 PM To: Flash Coders List Subject: [Flashcoders] bubbling listening Hi list... I have a singleton that contains an instance of an EventDispatcher. The EventDispatcher contains an instance of a sprite. I want that sprite to dispatch a custom event that is listened to by the singleton, but I can't seem to make it happen, even by saying bubbles = true. I could have a listener on the EventDispatcher, then dispatch another event going one level higher to the singleton, but I'm wondering if there's a way to bypass that sort of step by step architecture. I thought that within the singleton, I could have referred directly to the sprite itself within the EventDispatcher, but I have not been able to do that either. Any feedback is appreciated, thanks! - Michael M. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
Hi Jason, thanks for responding! Make sense? Almost. :-) What do you mean The EventDispatcher contains an instance of a sprite. The EventDispatcher has a private var that's a reference to a custom class that extends Sprite. The Event Dispatcher is instanced in the singleton, it's not on the stage, it just directs traffic, so to speak. Normally what you would do is not create an instance of EventDispatcher, but instead have your custom class extend Sprite (which already extends EventDispatcher anyway), have that sprite dispatch a custom event. Yes, that's happening. Then have your class listen to the instance of that class for the custom event you dispatch. Yes, I'm doing that too. So in summary, you write an event class, dispatch that custom event from the sprite class (the custom class that extends sprite) and listen for that event on that instance in your Singleton (the fact that it's a Singleton should be irrelevant). This is the part I'm not getting to work. What I have working is the following: Singleton - has private var EventDispatcher EventDispatcher - has private var CustomSprite CustomSprite dispatches CustomEvent. EventDispatcher catches CustomEvent from Sprite. EventDispatcher dispatches same CustomEvent. -- unnecessary step?? Singleton catches CustomEvent from EventDispatcher (passed along from CustomSprite). What I want is: CustomSprite dispatches CustomEvent Singleton catches CustomEvent. Within singleton, this does *not* work: myEventDispatcher[myCustomSprite].addEventListener... I have to pass the event up the ladder to the singleton. I'd rather leap over the EventDispatcher. - Michael M. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] bubbling listening
(feel free to shoot me if this is a bad idea)
Cheat.
Assuming EventDispatcher is a custom class and you're using AS3, create a
method within EventDispatcher to add Singleton as an event listener to
CustomSprite. Something like
public function myAddCustomSpriteListener(eventName:String,
listener:Function):void
{
CustomSprite.addEventListener(eventName, listener) ;
}
And just call the method within Singleton like so:
EventDispatcher.myAddCustomSpriteListener(myEventName, listenerFunction) ;
Jer
On Wed, Mar 17, 2010 at 1:39 PM, Mendelsohn, Michael
michael.mendels...@fmglobal.com wrote:
Hi Jason, thanks for responding!
Make sense?
Almost. :-)
What do you mean The EventDispatcher contains an instance of a sprite.
The EventDispatcher has a private var that's a reference to a custom class
that extends Sprite.
The Event Dispatcher is instanced in the singleton, it's not on the stage,
it just directs traffic, so to speak.
Normally what you would do is not create an instance of EventDispatcher,
but instead have your custom class extend Sprite (which already extends
EventDispatcher anyway), have that sprite dispatch a custom event.
Yes, that's happening.
Then have your class listen to the instance of that class for the custom
event you dispatch.
Yes, I'm doing that too.
So in summary, you write an event class, dispatch
that custom event from the sprite class (the custom class that extends
sprite) and listen for that event on that instance in your Singleton
(the fact that it's a Singleton should be irrelevant).
This is the part I'm not getting to work. What I have working is the
following:
Singleton
- has private var EventDispatcher
EventDispatcher
- has private var CustomSprite
CustomSprite dispatches CustomEvent.
EventDispatcher catches CustomEvent from Sprite.
EventDispatcher dispatches same CustomEvent. -- unnecessary step??
Singleton catches CustomEvent from EventDispatcher (passed along from
CustomSprite).
What I want is:
CustomSprite dispatches CustomEvent
Singleton catches CustomEvent.
Within singleton, this does *not* work:
myEventDispatcher[myCustomSprite].addEventListener...
I have to pass the event up the ladder to the singleton. I'd rather leap
over the EventDispatcher.
- Michael M.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] bubbling listening
Might be obvious, but bubbling only works on the display list. So if your classes aren't all on the display list, then it won't work. Steve On Wed, Mar 17, 2010 at 11:39 AM, Mendelsohn, Michael michael.mendels...@fmglobal.com wrote: Hi Jason, thanks for responding! Make sense? Almost. :-) What do you mean The EventDispatcher contains an instance of a sprite. The EventDispatcher has a private var that's a reference to a custom class that extends Sprite. The Event Dispatcher is instanced in the singleton, it's not on the stage, it just directs traffic, so to speak. Normally what you would do is not create an instance of EventDispatcher, but instead have your custom class extend Sprite (which already extends EventDispatcher anyway), have that sprite dispatch a custom event. Yes, that's happening. Then have your class listen to the instance of that class for the custom event you dispatch. Yes, I'm doing that too. So in summary, you write an event class, dispatch that custom event from the sprite class (the custom class that extends sprite) and listen for that event on that instance in your Singleton (the fact that it's a Singleton should be irrelevant). This is the part I'm not getting to work. What I have working is the following: Singleton - has private var EventDispatcher EventDispatcher - has private var CustomSprite CustomSprite dispatches CustomEvent. EventDispatcher catches CustomEvent from Sprite. EventDispatcher dispatches same CustomEvent. -- unnecessary step?? Singleton catches CustomEvent from EventDispatcher (passed along from CustomSprite). What I want is: CustomSprite dispatches CustomEvent Singleton catches CustomEvent. Within singleton, this does *not* work: myEventDispatcher[myCustomSprite].addEventListener... I have to pass the event up the ladder to the singleton. I'd rather leap over the EventDispatcher. - Michael M. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] bubbling listening
. What I have working is the following:
Singleton - has private var EventDispatcher
EventDispatcher- has private var CustomSprite
CustomSprite dispatches CustomEvent.
Yes, and what I am saying is, that architecture is wrong. You don't
create instances of EventDispatcher and then put Display object inside
of them.
I have to pass the event up the ladder to the singleton. I'd
rather leap over the EventDispatcher.
Right, exactly, so don't use it at all.
What I want is:
CustomSprite dispatches CustomEvent
Singleton catches CustomEvent.
Right, so just do that. Like this. First, create your custom event:
//MyCustomEvent.as
package
{
import flash.events.Event;
public class MyCustomEvent extends Event
{
public static const MYEVENT:String = myevent;
public function MyCustomEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new MyCustomEvent(type, bubbles,
cancelable);
}
public override function toString():String
{
return formatToString(MyCustomEvent, type,
bubbles, cancelable, eventPhase);
}
}
}
Then, create your custom display object and dispatch that event:
//MyCustomEvent.as
package
{
import flash.display.Sprite;
public class MyCustomDisplayObject extends Sprite
{
public function MyCustomDisplayObject()
{
somethingHappens();
}
private function somethingHappens()
{
dispatchEvent(new
MyCustomEvent(MyCustomEvent.MYEVENT));
}
}
}
Then, in your class (which in your case happens to be a Singleton class,
(which again, is irrelevant whether it is a Singleton or not), listen to
it:
//MyClass.as
package
{
import MyCustomEvent;
public class MyClass extends
{
private var
_myCustomDisplayObject:MyCustomDisplayObject;
public function MyClass()
{
_myCustomDisplayObject = new
MyCustomDisplayObject();
_myCustomDisplayObject.addEventListener(MyCustomEvent.MYEVENT,
onMyEvent);
}
private function onMyEvent(event:MyCustomEvent):void
{
trace(MyCustomEvent fired)
}
}
}
For only moving one level up the display object chain, you don't need to
bother with bubbling. If you go more than one level up, then turn
bubbling on when you dispatch from the MyCustomDisplayObject class:
dispatchEvent(new MyCustomEvent(MyCustomEvent.MYEVENT, true));
Jason Merrill
Bank of America Global Learning
Learning Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of
Mendelsohn, Michael
Sent: Wednesday, March 17, 2010 2:39 PM
To: Flash Coders List
Subject: RE: [Flashcoders] bubbling listening
Hi Jason, thanks for responding!
Make sense?
most. :-)
What do you mean The EventDispatcher contains an instance of a
sprite.
The EventDispatcher has a private var that's a reference to a custom
class that extends Sprite.
The Event Dispatcher is instanced in the singleton, it's not on the
stage, it just directs traffic, so to speak.
Normally what you would do is not create an instance of
EventDispatcher,[Merrill, Jason] t
but instead have your custom class extend Sprite (which already extends
EventDispatcher anyway), have that sprite dispatch a custom event.
Yes, that's happening.
Then have your class listen to the instance of that class for the
custom
event you dispatch.
Yes, I'm doing that too.
So in summary, you write an event class, dispatch
that custom event from the sprite class (the custom class that extends
sprite) and listen for that event on that instance in your Singleton
(the fact that it's a Singleton should be irrelevant).
This is the part I'm not getting to work. What I have working is the
following:
Singleton
- has private var EventDispatcher
EventDispatcher
- has private var CustomSprite
CustomSprite dispatches CustomEvent.
EventDispatcher catches CustomEvent from Sprite.
EventDispatcher dispatches same CustomEvent. -- unnecessary step??
Singleton catches CustomEvent from EventDispatcher (passed along from
CustomSprite).
What
RE: [Flashcoders] bubbling listening
What he said - events only bubble up the display list. EventDispatcher doesn't extend DisplayObject (rather the other way round) - so even if your Sprite is an instance inside an EventDispatcher it can't be on the EventDispatcher's stage (EventDispatcher doesn't have a stage). Instead of subclassing EventDispatcher, consider subclassing a DisplayObject (Sprite or MovieClip) - which because they extend EventDispatcher will give you access to all the functionality you need. Barry. -Original Message- From: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Steve Mathews Sent: Thursday, 18 March 2010 2:08 p.m. To: Flash Coders List Subject: Re: [Flashcoders] bubbling listening Might be obvious, but bubbling only works on the display list. So if your classes aren't all on the display list, then it won't work. Steve On Wed, Mar 17, 2010 at 11:39 AM, Mendelsohn, Michael michael.mendels...@fmglobal.com wrote: Hi Jason, thanks for responding! Make sense? Almost. :-) What do you mean The EventDispatcher contains an instance of a sprite. The EventDispatcher has a private var that's a reference to a custom class that extends Sprite. The Event Dispatcher is instanced in the singleton, it's not on the stage, it just directs traffic, so to speak. Normally what you would do is not create an instance of EventDispatcher, but instead have your custom class extend Sprite (which already extends EventDispatcher anyway), have that sprite dispatch a custom event. Yes, that's happening. Then have your class listen to the instance of that class for the custom event you dispatch. Yes, I'm doing that too. So in summary, you write an event class, dispatch that custom event from the sprite class (the custom class that extends sprite) and listen for that event on that instance in your Singleton (the fact that it's a Singleton should be irrelevant). This is the part I'm not getting to work. What I have working is the following: Singleton - has private var EventDispatcher EventDispatcher - has private var CustomSprite CustomSprite dispatches CustomEvent. EventDispatcher catches CustomEvent from Sprite. EventDispatcher dispatches same CustomEvent. -- unnecessary step?? Singleton catches CustomEvent from EventDispatcher (passed along from CustomSprite). What I want is: CustomSprite dispatches CustomEvent Singleton catches CustomEvent. Within singleton, this does *not* work: myEventDispatcher[myCustomSprite].addEventListener... I have to pass the event up the ladder to the singleton. I'd rather leap over the EventDispatcher. - Michael M. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
