Hi Jim, Thanks for the comprehensive examples, especially the clock face. I guess another advantage then would be the ability to swap the view instead of the controller, and (for example) have text-only console like view for testing & debugging? You might also say that Xray is another View.
In your framework, would the one controller for each view also mean that can be only one view per controller? I tend to use a single model for multiple views (the model could consist of a number of classes, but it's still one "model layer"), it might make sense to do the same with the controller. To clarify, I don't mean only one controller for all the views, more like clusters of views with a single controller in their middle. Or does that break the pattern? Another question about your implementation - who's the chicken and who's the egg? Does the view instantiate its controller, the controller the view, or a Main class that creates all? In my current implementation, I have a Main application class (linked to the stage) that creates the Model, the (limited) Controller, and passes the View (which is a symbol on the stage with Class Linkage) to the controller. The Controller's only function is to link them all together as Broadcaster listeners (all Views listen/broadcast to all Models. The Controller is the third part of the equation, because it can listen/broadcast to both Views and Models, but it sort of stops there. I also have some parts of the View interacting with each other via Broadcaster, but I'm beginning to think that this should really be the Controller's function - to intercept messages from one View to another: for example, from a PageView to the MainView, or from a ComponentView (eg the menu or breadcrumbs) to a PageView if necessity arises. Then on the smaller scale of Page or Component, I suppose each could have their own Controller class that's still linked to the main MVC structure, so that it can talk to the Model, but doesn't handle communications with other Views. Does that make sense to you guys, or am I overcomplicating here? Karina > -----Original Message----- > From: [email protected] [mailto:flashcoders- > [email protected]] On Behalf Of Jim Lafser > Sent: 29 March 2010 6:37 > To: Flash Coders List > Subject: Re: [Flashcoders] What good is a Controller? > > When I've implemented MVC: > * I have one controller for each view > * Each view knows about it's controller, but only as a generic > controller (either as an interface or a base class) > * Each View registers it's controller as the event listener for > each of it's buttons. > * Each controller translates a "generic call" in itself into a > specific call to the model that may or may not cause a state change. > * In response to state changes, the model notifies all views. > * The notification can include the state change information, OR > * The view can request the state change information from the > model. > * The view changes updates what is presented to the user as > needed based on the change in state. > The reason to implement the listener in the controller is to separate > the implementation of the business logic from the display logic. This > makes the implementation of the specific function on the model > independent of the generic function on the view. > > Example: an application has several views that each have a "next" and > "previous" button. Each view registers the next button with its > controllers next function. Each controller provides next and previous > functions that invoke one or more methods on the model that may cause a > state change. > > This provides a decoupling of the business logic from the display > logic. If I want to change what is displayed, or how it is displayed, I > change the view. If I want to change the response to user input, I > change the controller. > > An example of why this is nice: I've got a clock face that I want to > use as a stop watch (elapsed time) and as a timer (count-down timer). > View could be identical, and just change the controller to change the > functionality. Start, Stop and Reset would all have different meanings > that are handled by the controller. I know that a bug in the timer code > is independent of the stop watch code. > > In certain situations, it may be beneficial to implement a view as > another instance of the MVC pattern. An example of this would be where > a user is making choices in a configuration, and those choices don't > get saved into the application state until the "OK" or "Apply" > button is clicked. While the choices are being made, the views internal > state is stored in the views model, and when OK is clicked the choices > get stored into the application's model. > > Whether or not it's worthwhile to implement a view as another > internal MVC pattern depends upon the complexity of the view vs. the > added complexity of the overall system. IMHO, the choice should be to > go with what makes the overall system the easiest to support. > > Jim > > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
