Sort of - but I wouldn't have the controller dispatch anything. I would only have it listen to the view(s) (your other classes with a visual presence). The controller first creates an instance of "A" (what determines when that happens, I don't know because I don't know what "A" or your app is all about). When it does, it also creates listeners for "B", "C", "D" if they are present in the view. Controller also of course has the handler that tells whatever else to do what it has to do (now I'm just guessing because I don't know what you're ultimately trying to accomplish).
If something needs to happen when something changes data-wise in the model, then you would listen to the model which dispatches events and have the controller respond, perhaps by telling the view to change. IMO, the Controller is the most ambiguous part of the MVC pattern. View and Model are pretty straightforward (esp. the Model). Different people have different ways of using the controller, but this is how I use it. It listens to other parts of your app, and then tells other parts of your app to do something. It's the central nervous system to use a methaphor - at least how I use it. AS3 Frameworks get more broken down than that, using things like Command classes, Mediators, and Facades and junk for even better OOP development and control, but there can be a steep learning curve to most of those frameworks. 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 Andrew Sinning Sent: Tuesday, February 23, 2010 12:05 PM To: Flash Coders List Subject: Re: [Flashcoders] accessing event dispatchers in a loosely-coupled,modular design In other words: Create a Controller class before creating any other classes. Any instances that need to know when potential event dispatchers are created should listen to the Controller class. When dispatchers are created, the Controller class should dispatch an event. This way I won't need to use a Timer to repeatedly look for the dispatchers. Merrill, Jason wrote: > If an instance of those classes has been created, then it will eval to > true, otherwise it will be null, so this should work for that part of > the problem: > > if(_myinstance) _myInstance.addEventListener(myEvent, myHandler); > > However, if you're creating "A" after "B", "C", and "D", then you'll > want to call the code above from say, a Controller class whenever "A" is > created. Once "A" is created, then that's a trigger to add the > listeners to the other classes if they exist. 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 > (inote: 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 Andrew > Sinning > Sent: Tuesday, February 23, 2010 10:04 AM > To: Flash Coders List > Subject: [Flashcoders] accessing event dispatchers in a > loosely-coupled,modular design > > Following the discussion about "root" yesterday, it got me thinking > about a constant problem I face. > > Object-A needs to listen to events coming from objects B, C and D, but > only if and when these objects actually exist. There's no guarantee > that any of the objects B, C and D will be instantiated before or after > A is instantiated. So, what's the proper way for A to add itself as a > listener to B, C and D? > > What I'm currently do is this: > > The event dispatchers (B, C, D etc) implement a singleton interface. > > Within the target (A), I set up a Timer event to repeatedly check > for instances of the dispatchers. Once a dispatcher is found, the > target adds itself as a listener, and a pointer to the dispatcher is > created so that the target can later remove itself. > > > I'm not very happy with this design, but it's the best that I've been > able to come up with. > > Thanks! > _______________________________________________ > 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 mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
