Hi Jim, Thanks for another extensive reply, and getting the discussion back on the MVC track ;)
> 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. This makes sense. I've been experimenting with my MVC framework (trying very hard not to break existing functionality...), and the way it seems to work best for me is to have: One manager Controller for the entire application, which does all the linking of the general structure. This can also be extended to listen to Broadcaster messages from all the loaded views in the application. A Model layer (a manager Model with child models that handle separate tasks all linked to the main Controller) A main View that can also load other views (pages, components, etc.) - which are most likely to be self-contained movies, but could also be linked symbols. Each View will contain either the manager Controller directly (for backward functionality) or its own personal assistant - the ChildController. The ChildController implements the same interface as the manager Controller, but instead of doing all the linking itself, it will register the View and itself with the manager Controller, and then proceed to implement its own functionality. It taps into the Model layer via the manager (but could also have its own personal Model for localised tasks). > > 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. This clarifies matters for pages or components that are created as standalone movies - the Main should create all the views models and controllers. But what about library symbols? If I have a component like a CustomButton, at the moment it just does everything in the MovieClip class. Since the buttons are not necessarily created with ActionScript but are more likely to already be on the stage, can the button's movie clip be both the View and the Main? Or should the button's View be a child of the linked symbol? Personally, I'm more comfortable coding by inheritance, even though I can see the advantages of composition. > > > 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. You can only do that if your View isn't already on the stage, but it's easy to get around by passing the controller to an existing View. > > 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 Thanks a mil for taking the time to clarify your approach. I hope mine, or what I'm trying to achieve, isn't miles away from it, or at least that it makes some sense. Karina _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
