Cliff,

Thanks for your insightful answer. I'll keep in mind everything you said in your post, as I venture forward and get going with pureMVC. The warning about not making mediators too "smart" was especially helpful. Thanks for not letting me jump to a wrong conclusion about MVC itself. As I look at the Head First Design Patterns book again, I see that even though the controller creates the view, it didn't necessarily add event listeners to it (they didn't show that part of the code).

I really, really appreciate you taking the time to write that.

Thanks for the reply, Cliff.

What I meant was that studying pureMVC was helping to shed some light for me in my own thinking about ordinary, plain vanilla MVC (without the pureMVC framework), which always seemed to me to be an odd fit for Flash and AS3, mostly for the reason outlined above, that is, the idea that the controller should be passed an event rather than adding the event listener for it itself.

I intend to keep rolling with pureMVC, it's just that I had already been very close to implementing ordinary MVC into my programming projects. I could see the value of using a model, but I would always get hung up over the issue of passing events to the controller, in addition to just general confusion over what code should go where.

I love PureMVC, it's just that after all this time of studying design patterns in general, I have this inner need to understand how the MVC pattern itself might work with Flash, and the various sources out there all seem to see it differently, and sometimes even contradict each other.

EDIT: I guess I should kind of apologize, as my question wasn't about pureMVC itself, more like MVC in general. I'll try to stay more focused on pureMVC questions in future posts. But with your knowledge of patterns, I guess I was kind of expecting an answer like, "Yeah, it's okay to let the Controller observe the View that way and add event listeners to it... perfectly fine" --OR-- "No, you wouldn't want to do that, as that would (for whatever reason) go against the Strategy pattern that the View uses to delegate events to the Controller."

Mr. Jody Hall
"Mazoonist"

PureMVC has opened my eyes in a lot of ways. I had been struggling to understand MVC for a long time. One thing I could never understand (at least in terms of Flash and AS3) was why the View should delegate events to the Controller. Suppose I have a group of buttons in the view, and they are in an array (also defined in the View), and they share an event listener. The first thing the listener does is figure out which button was clicked using event.currentTarget.

The View can do this because it has the array and all the references to the buttons. If I pass the event to the Controller to process it, the Controller will not have the array reference, nor any references to any of the other buttons, and so some other way must be found to identify the button. Using the name property might be a solution, but then the same problem pops up: the Controller then needs to know all the names.

The book "Actionscript 3.0 Design Patterns" advocates passing the event to the Controller to handle it. Their scenario goes like this: Model is instantiated first.
The Controller is instantiated and given a reference to the Model in its constructor.
The View (or views) is then instantiated and given reference to the Model and Controller.

Notice that, in the above, the Controller is never given a reference to the View, although the authors seems to indicate that the Controller can have a reference to its view, and even should in some cases.

However, the book "Head First Design Patterns," while not an AS3 book, seems to advocate a system something like this:
Model is instantiated first.
The Controller is instantiated and given a reference to the Model in its constructor.
The Controller then instantiates its View and passes a reference to both the Model and itself to the View's constructor.

Since the Controller now has a reference to its View, it could then freely add event listeners to the View's buttons itself. The Controller could then house the array that refers to the View's buttons, like:

private var buttonArray:Array = [view.button1, view.button2, view.button3];

In this scenario, the View becomes something like the view components of PureMVC. They can be reused in another project by simply writing a new controller for them.

My question, then, is-- doesn't this kind of system-- where the Controller becomes an observer of its View-- just make a lot more sense? I mean, the View still communicates to the Controller, it just does it by dispatching events (instead of just passing them directly). I don't see the downside, and I wonder why so many sources advocate passing an event to a Controller that just doesn't have the right references in place to handle it.

Studying PureMVC has made me aware of this. I love the way it decouples everything. In PureMVC the Mediator classes observe their view component much like my hypothetical controller above.

Any thoughts?