Assuming that all the UI events created by one clock face (view) are included in the events on the other clock face (another view) and the events are defined by the business rules to have identical effects on the state of the application, then the same controller could be used for both.
If two (or more) views generate identical UI events that have the identical effect upon the state of the application (change to the model), then I would use one controller. If one controller generates extra events, then I would use two controllers, with the more complex controller derived from the other controller. It would be possible to use conditional logic within one controller to handle multiple views, but this typically indicates the need for polymorphism (same message, different results), which is generally best implemented by having different classes. In my implementations, I have an class that represents the application that is the "chicken" or Main. The Main class has class variables for the model and each of the views. The model is created first, then I create a controller and a view, the controller is passed as a parameter to the view's constructor. The view is then registered as a listener with the model. I repeat the controller and view process as many times as needed. In the constructor method of the view class, the view class registers itself with the given model. Moock provides a good example of the MVC pattern in Essential AS 2.0. The example has the view classes create a default controller if one has not been provided, but I felt it easier to just require a controller to be provided in the constructor. As Moock indicates, "there is no single "right" way to implement MVC". I think he provides an excellent discussion of the pattern and choices that a developer can make in implementing the pattern. Jim ________________________________ From: Karina Steffens <kar...@neo-archaic.net> To: Flash Coders List <flashcoders@chattyfig.figleaf.com> Sent: Tue, March 30, 2010 9:53:34 AM Subject: RE: [Flashcoders] What good is a Controller? 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 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. _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
