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: [email protected]
[mailto:[email protected]] 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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
