MVC Structure - Need a little help.

[tom_w2000]

Hi Guys,

I need some help with how to structure a major application in MVC, basically I have several applications (a gallery app, a coverflow app and a dataGrid application) that I want to display inside an main application.

The main application has a menu to select each application to load, and each loaded application is a Composite View containing other views like image display views, scrollbar views, sliders etc.

I am using the MVC pattern and the Composite pattern to create the applications themselves and simplify the update process, and I have a few questions about structure:

1. At present I am creating each view (i.e. galleryView, CoverflowView, dataGridView) and each Model for each view in the Main (document class), and to each model I am passing an different XML file for that application from the document class. Is this the right way to do it? or is there a better way? Also, should eventListeners to the model, do inside the document class, or the views themselves?

2. Also, is it normal to create views inside other views? In other words, say I have a galleryView that is a Composite Object. Should I be creating and adding new views (i.e. scrollBarView, imageView) to the galleryView - inside the galleryView class, or is it better to create other views outside the galleryView class and then add() them to it as part of its composite structure (as below), for updating?

var galleryView:Composite = new galleryView(model, controller);
var scrollview:Composite = new ScrollView(model, controller)
galleryView.add(scrollView).


3. One other thing I am having trouble with is how to change between views. In other words if I have a navigation that changes between the galleryView and the DataGridView, would I have to remove all the (component) views inside the galleryView first, and then create the DataGridView, or is it better to simply hide the galleryView and un-hide the DataGridView, and vice versa?

Any help on this would be greatly appreciated, as I have been on it for days...

Tom.

[marlopax]

I need some help with how to structure a major application in MVC, basically I have several applications (a gallery app, a coverflow app and a dataGrid application) that I want to display inside an main application.

What OOPs tells that you have only one apps with multiple utilities and their own different views. All are integrated in one Application.

1. At present I am creating each view (i.e. galleryView, CoverflowView, dataGridView) and each Model for each view in the Main (document class), and to each model I am passing an different XML file for that application from the document class. Is this the right way to do it? or is there a better way? Also, should eventListeners to the model, do inside the document class, or the views themselves?

Yes the way is right.

2. Also, is it normal to create views inside other views? In other words, say I have a galleryView that is a Composite Object. Should I be creating and adding new views (i.e. scrollBarView, imageView) to the galleryView - inside the galleryView class, or is it better to create other views outside the galleryView class and then add() them to it as part of its composite structure (as below), for updating?

It is best practice to make all component independent. Interact with each other.

3. One other thing I am having trouble with is how to change between views. In other words if I have a navigation that changes between the galleryView and the DataGridView, would I have to remove all the (component) views inside the galleryView first, and then create the DataGridView, or is it better to simply hide the galleryView and un-hide the DataGridView, and vice versa?

If it is needed create it if not remove all. Recreate when it need again, if need to keep history create an array or a history or bookmark class to hold the history of whatever data you want to hold there.
This will manage the memory issue. Hiding is not a good practice. All are in fly.

Best Wishes


Note: Please don't create multiple threads for one topic.




marlopax

[tom_w2000]

Hi marlopax,

Thanks for your prompt response, appreciate that.

When you say "It is best practice to make all component independent. Interact with each other.", are you saying that you can create other views inside other views (i.e. a scrollBarView inside galleryView)?

The way I understand it is that a galleryView is one view, a scrollBarView could be another inside the galleryView (say for scrolling images in the galleryView). An imageDisplayView could be another (for containing the movieclip, preloader and current image reference for the gallery etc..)

Using the Composite pattern with MVC I was thinking to create galleryView and its model in the document class, and then create scrollBarView and imageDisplayView INSIDE the galleryView constructor itself. I would then hold these two views as components in an array inside galleryView, and update them both when the model changes, with one call to the gallerView() update method. Am I missing something - i.e. should the scrollbar, and scrollList be moviclips or other objects?

The only other way I can think of adding views to other view is to create scrollBarView and ImageDisplayView in the document class and then add them to galleryView from the document. However this way my document class would get very bulky if I was to add every component for a view from the document class?

Also - should I be listening to the model from within the view, or from the document?

Sorry if I'm not getting this..

Tom.

[tom_w2000]

Hi Again Marloplax,

I thought it best if I post some of the code I've abstracted for clarity reasons:

Below is an example of my Main class and a galleryView class I am using. galleryView itself extends a composite view that includes an array for storing components (other views in this case).

As you can see I am creating other views that relate the the galleryView, inside the galleryView itself, and then adding these views as components of galleryView. When update is called on galleryView in response to a change in the model, it loops through these other components and updates them as well (composite pattern).

Is this the right way to go about it? (sorry for any bad comments)


MAIN CLASS:

public class Main extends MovieClip
{
public function Main ()
{
// APPLICATION 1: 3D GALLERY:

var galleryXml:String = galleryXml.xml”;
var galleryModel:IGalleryModel = new GalleryModel(galleryXml):
var galleryView:Composite = new galleryView (galleryModel, null);
//
galleryView.x = 0;
galleryView.y = 0;
addChild(galleryView);
galleryModel.addEventListener(“navChange”, galleryView.update());


// APPLICATION 2: COVERFLOW

var cFlowXml:String = galleryXml.xml”;
var cFlowModel:IGalleryModel = new GalleryModel(cFlowXml):
var cFlowView:Composite = new galleryView (cFlowModel, null);
//
cFlowView.x = 0;
cFlowView.y = 0;
addChild(cFlowView);
cFlowModel.addEventListener(“change”, cFlowView.update());

}
}
}


GALLERY VIEW CLASS:

package
{
import flash.display.MovieClip;

public class galleryView extends Composite
{
public function galleryView (model:Imodel, controller:IController = null)
{
super(model, controller);

var navController:IMouseInputHandler = new NavController(model);
var navView:Component = new Component (model, navController);
// add controller to current composite view
this.add(navView);
//

var imgController:IMouseInputHandler = new imgController(model);
var imgView:Component = new Component (model, navController);
// add image viewer to current composite view
this.add(imgView);

// ScrollView contains and updates listview.
var scrollView:Composite = new Composite("Scroll View");
// List view contains and updates SliderView based of number of items
var listController:IMouseInputHandler = new listController(model);
var ListView:Composite = new Composite(model, listController);
scrollView.add(ListView);
//
var sldrController:IMouseInputHandler = new sliderController(model);
var SliderView:Component = new Component(model,sldrController)
ListView.add(SliderView);
// add scrollView to current composite view
this.add(scrollView);

// update added views, so they can get the latest data from the model.
this.update( );
// add EventListener to model and change gallery view
model.addEventListener(“navChange”, this.update( ));
}
}
}

[marlopax]

Making the Model to collect the XMLList from the Document Class and pass into the ModelComponents Class.

ModelComponents pass to the ViewComponents Class which display views differently.

ModelComponents will Compose all the information of the other components/object which are independent which the ViewComponents will just display. Also ModelController Class which is the main Controller Class for the Model Class can also update data to ModelComponents Class to update the View or can change the view accordingly if needed.



You might need Observer Pattern in combination with MVC Pattern to make proper implementation of your Application.




marlopax

[tom_w2000]

Hi Marloplax,

Thanks again for all your time on this. I'm going to try to keep this shortish as I know your time is important.

Here's what I have so far:

1. In the main Document class, Create a Model for each application passing each one a separate XML file for the application it represents. The Model separates the XML into Variables/Arrays for its related View.

2. In the Document class, create a "ViewComponents" class for each application, and pass it it's related Model (i.e. for galleryViewComponents pass galleryViewModel).

3. Inside each "ViewComponents" class, instantiate any other views needed for that view (application), for example ImageView, buttonView, ComboBoxView etc, and reference the Model passed to ViewComponents to provide these 'smaller' views inside ViewComponents with data.

4. Set up any listeners for any Views inside the ViewComponents class - inside the ViewComponents class itself, to update when model for ViewComponents changes.

5. A ViewComponents class represents each application, so an application can have multiple viewComponents classes, that each represent a collection of other views that make up the main view?

Is this right?

I guess my main question here is where I instantiate the 'smaller' views of the Main (application) View.

Naturally the Main View (i.e. GalleryView) would contain smaller views that make up that view. But do I instantiate these smaller views (i.e. ImageViews, ComboBoxView etc.) inside the Main View (GalleryView), or create these Views in the document class and then add them to the view as components of the 'GalleryView' (following the composite pattern)?

The bottom line is - Am I right in saying the "ViewComponents" class is the Main class for a Main View (i.e. a Gallery application), and that this class creates/encapsualtes it's own (smaller Views), i.e. scrollView, thumbView etc, for that View?

Tom.

[tom_w2000]

Hi Again Marloplax,

I've been doing a little more thinking and writing some test code, and am starting to see things in the 'bigger picture'.

My initial thoughts drawing on what you said, are that if I wanted to create an application that contained various 'apps' (kinda like an iphone), and allow changing between these apps, I would have to do the following:

1. Create a Main Navigation View (menu) in the document class to navigate between various applications, and set up a listener in the document class to listen to changes in this navigation view.

2. Create a ModelComponents class in the document class and pass it an xml file containing all the data for all the models in the application, which would then create all the models for each application view in the project, and pass each model the relevant xml data for the view it represents?

3. Create a 'ViewComponents' class in the document class to holds all the Main application views (i.e. gallery, Coverflow etc.), while in turn passing the ViewComponents the ModelComponents class. The ViewComponents class would then reference the ModelComponents class to create all the application views for the project while passing each its relevant model.
ViewComponents class would also accept an integer from the main document class (from the main navigation), and remove or create application views based on this integer from the Navigation in the document class.

4. Each View in the ViewComponents class (once passed its own model) would instantiate its own (smaller) views that make up that view, as well as deal with its own updating of its views.

Does this sound about right?

Also, if it is - should I be passing ModelComponents class 1 big xml file containing all the data for each application, or an xml file for each model I want to create?

[marlopax]

Well,

What you are doing is not a wrong way. I think you are not uncomfortable by doing that way which is correct in sense of MVC Pattern. By that way you might not get any problem as far as this project goes. What I am trying to accomplish is a Framework of Patterns with independent components or a group of many components which creates a complete objects of certain part of an application will bubble and dissolved according their needs. The object in my words here , is the combination of many input and output components or the primary objects like TextFields or a ComboBox.

If you think a team with a team leader who is the main manager to handle its own team and also can handle other related or depended vendors of that team. Every team member has power to handle other team to give command or send request to that team leader and the whole thing will execute according to that command which is given by the engine/machine or through the controller by itself directly. Here main operator is the user, so all the commands starts from the users and end to the users as a result. So basically, if you think MVC pattern is a combination of three individual class with their functions, then this will become as it coded as a hard code Composite Engine and not a Engine for any universal Project.

If you go through any Frame work of any Design Pattern you will see that you can adopt that framework in any Project. But the choice will depends what project you are going to handle.

In my sense Model is a team where Model is the team leader. View is a team where View is the team leader and controller is a framework of fixed components by which the user can interact with its functions and above all there will be an administrator who will set or create the controller for the users for the application, or for each different applications under the same hood of framework.




marlopax

[marlopax]

Technically, you can think an admin part and a client part in one framework. The client part will reflect as the admin setup the application. If you are going to take a bunch of apps as an example then the main menu is the main controller and each individual app also has its own controller. So if you are going through xml format the just loading the main setup xml for the main menu controller is enough to handle the main app. The sub apps setup xml will load according to the need of users and will unload when it is no longer in use mean when other app takes place on the view. Only the main setup xml for the main menu will remain there till the application is running.

This is just a concept.



marlopax

[tom_w2000]

Hi Marloplax,

Are you saying that the Main views themseleves, for example 'galleryView' should be collections of UIComponents (or custom objects), and not other Views?

For example, if galleryView was one of many application views I had in my document class, and galleryView contains an imageLoader, a scrollbar with scroller and a thumbnail selector, are you saying I should compose these UI objects as UI COMPONENTS and compose them into the galleryView, as oppose to adding them as new VIEWS?

When I read the book by Orielly on OOP design patterns in as3, he had an example of a comboBox View (created in the main document class), that extended a Composite class to allow other views to be added to the comboBox view as child components. He then went on to add a mapView to the comboBox view as a child of comboBox. Both of these Views he composed in the document class, and added to the stage. Code Below:


// DOCUMENT CLASS:

var model:INewModel = new NewModel();
var controller:ICompInputHandler = new Controller(model);
// COMBO BOX VIEW
var view:CompositeView = new ComboBoxView(model, controller);
view.x = view.y = 10;
addChild(view); // add combo box to stage

// MAP VIEW
var map:ComponentView = new MapView(model);
view.add(map); // add to ComboBox view as a child component

map.x = 0;
map.y = 40;
addChild(map); // add map view to stage


This is an example taken directly from the book, whereby when the user changed the selected item on the combo box View, the view would loop through its child components (map View) and update them automatically.
In other words the map view was a child view of Combo Box view and updated with one call to the combo box update method.

Leading on from this principle I have though of creating all my views in the document class, and then adding any other related views of each view, in the document class as well. Code Below;

// DOCUMENT CLASS
var galleryView:Composite = new Composite(galleryModel, controller);
galleryView.x = galleryView.y = 0;
addChild(galleryView);

var galleryNavView:Component = new Component(galleryModel, controller)
galleryView.add(galleryNavView) << add gallery Nav View to Gallery View
galleryNavView.x = galleryNavView.y = 100;
addChild(galleryNavView);


... This is following on from the theory in the book, whereby views are composed into other views using the composite pattern to help with updating. But If I were to code up every view inside a view in the document class, the document class would undoubtedly get very bloated.

This is why I was thinking to compose any related views to a Main View, inside the Main view itself.

I am starting to think that in the case of the galleryView, the Navigation and ImageLoader and Thumbs should be coded as UI COMPONENTS and seperate objects, that I then compose into the galleryView as concrete objects that dispatch events through the galleryView controller.

Am I making any sense here?

..It would really help if I could communicate with you over a chat system.

[tom_w2000]

Hi Marlopax, thought this might give you more of an idea of what I'm trying to achieve. The Document class contains the App Selector View, and then views themselves. The gallery View is a composition of other views made up of UI components. The nav View from within galleryView changes the image View and displayed image, and reloads (updates) the Scoll View with images for that gallery. Any thoughts on how best to code this?

[tom_w2000]

Hows this Marlopax?

1. Document Class Contains a Navigation which has its own controller for dispatching events. The Navigation View dispatches events based on which Nav button within the naviation view is clicked.

2. The Document class also has a listener which listens to the navigation view, and calls a method in the document class to create a view based on the navigation button pressed.

3. The method in the document class called by the event listener to the navigation, accepts an event, and uses a case statement to evaluate which nav button has been pressed, and thus which view should be built. Based on the Nav button pressed the method first checks to see whether the current view showing in the document class is the same as the view passed from the nav to be created, if not - the case statement instructs the current view showing to remove any of its child components/components as well as itself, and (when removed) instructs the new view to be built.

4. Each View to be build is defined within the case statement of the document class, with its own xml file, model, controller and root view class. And each view encapsulates its own set of child views or UI components for that view.

I've drawn on what you said about the Navigation being the root controller and instructing views to be created, and tried to implement that idea into a theoretical workable concept (above).

How does this approach sound to you?

Thanks again for all your help.

Tom.

[marlopax]

I send you PMs

This sounds more OOP.

3. The method in the document class called by the event listener to the navigation, accepts an event, and uses a case statement to evaluate which nav button has been pressed, and thus which view should be built. Based on the Nav button pressed the method first checks to see whether the current view showing in the document class is the same as the view passed from the nav to be created, if not - the case statement instructs the current view showing to remove any of its child components/components as well as itself, and (when removed) instructs the new view to be built.

case will not make your architecture flexible. What about pushing it in a temp array which store the last and the current events state?

If you determined that you are going to keep calling a fixed method then case statement will be the easiest way to go for events.

or a boolean for the display objects only.




marlopax


Note: Nav View will create outside the Gallery View. So Nav View will keep itself free from Gallery View and not dependent with any View.

[tom_w2000]

Hi Marlopax,

Thanks again for all your time.

I've been on this again today thinking about different ways I could create an interface for the different apps.

From what I understand after all we've talked about, is that the document class should contain all the app views (coverflowView, galleryView, mapView etc). And each app view should have its own model and controller and xml file.

The document class will also contain a Nav view (seperate from the app views in the document class). Ultimately though, the Nav view will be responsible for changing between app views.

Looking at it this way, all the views (each app, and the navigation) are independent and responsible for their own functionality and sub views.


.....I feel I am nearly there. However, I am still stuck on how to tie this all together in the document class - i.e. how to tie events from the Nav View to the creation/removal of app views in the document class. Is there an easy OOP way to do this?

I mentioned placing a method in the document class to create/remove the views according to events from the Navigation, but as you said "
case will not make your architecture flexible.".

You also mentioned that the Navigation View IS the Controller, and that all I need to do is load the XML for the navigation, and that the other XML files for each app would load according to the users need, but I don't quite understand this? Could you be more specific about how the Nav View could control the loading of the different XML files and creation of other views?

Also, if I do create all the views as well as their models and controllers in the document class, they will all compose at the same time and overlay each other unless given some kind of condition tied to the navigation view.

In basic terms, what I want is the following:

1. Document class loads up and displays app 1 and provides a navigation view for changing to other apps.

2. user changes the app shown from the current app view in the document class. Document class removes current app view in the document class and tells the new view to build based on the navigation button pressed in the Nav View - cycle repeats.

Should I be including this logic to change between views in the document class? Should I be encasing all the app views inside another view that listens to the document and handles changing between views? Should each app view itself contain the logic to build or remove it using some kind of init() function?

... I think i'm going crazy over this.

[jAQUAN]

Heh, ok this was a little tough for me to read through. I kinda just glazed over about half way. I know what you're trying to do but lets not over-complicate things.

I remember those pattern examples well from the as3 dp book and frankly, its a terrible book. The key to design patterns is to remember that they are available options to solving reoccurring problems. They are not hard rules by any means.

For starters, let me clarify a few things the book fails to illustrate well.
1. The composite pattern has nothing to do with the programming term "composition". A composite pattern comes in handy when you want to treat any branch or leaf in a tree the same way. Lets say you have a class called Shape and you could tell shape to draw a triangle, a square or a circle. Now we might create a bunch of instances of Shape and store a reference to each in an array. This would essentially be a tree with no branches, just leaves. Each shape in the array is considered a leaf because it is the end of the line. A leaf cannot have branches. Now, we might also want a few members of our array to point to groups of shapes instead of just one shape. The array now is a mix of groups (branches) and single instances (leaves). The branches of course contain references to their own leaves.

Now lets say we want to call a scale() method on every member of the array. If both our Shape class and ShapeGroup class define a method called scale(), we are free to loop over the array and call scale() on each member and we get a logically similar behavior from each one. The key to what makes this a Composite patter is that each member is very similar in nature. A scroll bar and an image viewer are not similar so even though they both exist in the save view, it is not a composite.

Composition on the other hand refers to one of two type of class anatomy. When a class gets most of its feature set by extending another class, that is inheritance. When class creates instances of other classes it is composition. In OOP we favor composition over inheritance unless inheritance simply makes more sense like for similar buttons.

2. The term View can be confusing. It does not necessarily mean "things you see". A view is merely a piece of an application that represents part of the models current data. An audio view for example might simply change the volume of an audio channel to match a value in the model which was recently set by a volume slider view. The main reason behind that communication loop is to allow for things such a separate Mute view to also change the models volume and the audio view is none the wiser who changed the info. Separate views can come and go and the audio view never needs to be edited. This is effective decoupling. Now, that said, it should not be taken to mean that each little component needs to be written up as a view. Painfully separating each little piece of an app into separate line of communication not only kills deadlines but invites spaghetti code. Do not lose sight of the fact that you're decoupling in order to make updates easier and too many subdivisions defeats that.

A view composited of a scrollbar, image viewer etc. is quite capable of listening to and informing its children of updates. This is what marlopax meant by suggesting a view be made up of one or more components. A component is just an autonomous bit that broadcasts an event when interacted with and the event contains information about the result. A scrollbar would broadcast a change event and the event object would contain a value of its new position. The view that has the scroll bar can send that info to the model and the scrollbar takes care of redrawing itself. The scrollbar should however define a public method that allows its position to be updated by its parent. This allows another part of the app to change the scroll panes position and the scroll bar can be updated to reflect that position. Again, effective decoupling but not wasteful.

3. You seem to have a good grasp of the MVC pattern as a whole but there are a couple of pieces I should explain.
One is not technically part of the definition academically but the real name of the pattern is MVCS. The S stands for Services. A service is much like a model in that it deals with data but its purpose is to go and get it and send it out. You would use a service to load xml, send form data to a server, communicate with other apps or generally any communication outside of the app. Generally they just pass retrieved data to the model who updates the app as normal.

The other important piece is the C. Controllers act as mediators between the views and models. Their job is to listen to views for changes from the user and to update the views about changes in the model. Your document class is well suited to be your controller. Now, if you need to place a view inside of another view, create and listen to it in the controller and then pass it to the parent view. The parent view should not be in charge of listening to its children views.

This of course creates the issue of cramming a ton of logic into the controller. We alleviate this by separating the decision making part of the code into classes called Commands. A controller simply reacts to a change by creating a command object. The command is the one who actually thinks about the change and decides what part of the model to update. This reduces the controller down to just a bootstrapper and messenger. Commands have a very brief lifespan, they don't even have to be recorded to class level variables since all they do is some business logic and update some data. They are not needed after that and should be allowed to die.

To sum up, a view is made up of dumb objects called components, only objects tied to model data should be views, the Composite pattern is only useful for leaves and branches of those leaves, use a service to load or send data and use commands to decide how events affect the model.

[tom_w2000]

Hi JAquan,

Just wanted to reply quickly to say thanks for getting back in touch. Marlo has since made me aware of my need to keep things shorter to aid 'digestion' and readability .. so I apologize for that. It can be very difficult when you have so many questions.

Again and as always your answers were very clear and succinct. There are just a few things I still have questions on.

I now understand that Views should never be added directly inside other views, and that views should be composed of 'dumb' objects called components that the view uses and dispatches events from.

You also mentioned, that the document class should be the 'controller' and that if I wanted to place a view inside another view I should create and listen to it in the controller (document class), and then pass it to the parent view. This follows exactly what the book says..

The only trouble I can see with this is that - say I have many views inside views. For example: an outer GalleryView on the document class, then an inner scrollerView (containing a list component and a slider), and then a ImageView (containing multiple image objects and loader components). Would I have to create GalleryView, scrollerView and ImageView (as well as their controllers) on the document class and then add() these to the GalleryView document class composite?

As I think you said, if you have to create all the views for each view on the document class, the document class would be full of Views for each view, as well as controllers for each view, and become crazy in larger apps.

You mentioned command objects to resolve this problem, do you have any examples of a command object I can look at? Or is there some documentation I can look at in a similar context?

I've been wondering instead, whether it might be possible to instantiate a 'Main' class inside the document for each application you wanted to create.

For example If I wanted multiple applications in a Document class, and each application contained multiple views, I could say, create a GalleryMain class in the document class, and then inside that Main class, create the model as well as all the views and subviews for that application. I could then for example, create a DataGridMain class in the document class, in which I would create the model and all the views and subViews for that application. In other words the Document class would consist of only the Main.as classes for each application I wanted to create within the document. Each main class could then act as a container for all the views of that application, which I could then remove from the document at any time?

This is probably a really bad concept, but any thoughts?

Again, thanks for all your time.



Tom.

[jAQUAN]

1. A view can certainly sit inside another view, it just shouldn't be managed there. If a parent view had to directly manipulate a child view, that would tightly couple them together making it difficult to eliminate the child or use another child in its place.

2. You can set up your controller environment in any way that makes you happy. This is why I say to not blindly adhere to a design patterns spec. Ultimately its your bacon.
For a single application, I generally use a single controller, but your main class could certainly create a series of controllers. The exact hierarchy is up to you, as long as you are centralizing your data and separating logic and display you are still using MVC effectively.

3. Using a single bootstrap class to instantiate a series of applications is exactly what you should do. This is what we mean by "black boxing". The individual pieces should be able to work with each other without having to know how each other does their job.

Earlier you asked about managing multiple running apps. Again, its up to you to weigh the risks and decide how careful you have to be. If some are processor intensive, you'll want to create a clean shut down routine, destroy and recreate them as needed. If you simply don't want mouse clicks to trigger you could addChild or removeChild as needed.

A Command class is a simple class that usually takes a reference to the model and an event object in its constructor. They will then examine things such as model state and event data and call one or more methods on models or services. If they decide nothing has to change in the model but the view should still update somehow, they can also inform the controller too. They're just carrier pigeons that die when done. In most applications, any number of commands could be processing at once so if the need arises, they include an execute() method so they can instantiated, stored in a stack and then executed in order. Wait until you've identified a need for this level of control before you waste time implementing a command stack. Never add functionality early.

Say we had a detonator view with a big red button but we only wanted the bomb to explode on wednesday.
Our controller might look like this:

private var _model:Model;
private var _denotatorView:DetonatorView;
function init(){
  _model = new Model();
  _model.init();

  _detonatorView = new DetonatorView();
  _detonatorView.addEventListener(DetonatorEvent.DETONATE, onDetonate);
  addChild(_detonatorView);
}

function onDetonate(event:DetonatorEvent):void{
  var detonatorCommand:DetonatorCommand = new DetonatorCommand(event, model);
  detonatorCommand.execute();
}

Then DetonatorCommand.as might look like this:

package{
  public class DetonatorCommand{
    private var _event:DetonatorEvent;
    private var _model:Model;
    public function DetonatorCommand(event:DetonatorEvent, model:Model){
      _event = event;
      _model = model;
    }

    public function execute():void{
      if(model.getDay() == "Wednesday"){
         model.explosionMode = true;
      }
    }
  }
}

The model might have an explosionMode setter who if set to true, dispatched an event that told our controller to have detonatorView play its explosion animation.

[tom_w2000]

Hi JAquan,

Sorry for not replying yesterday, didn't mean to be rude.

I'm currently working on something (a prototype) that will hopefully bring together all I've learnt from you guys on here..

I may still have one or two questions if that's ok.. Thanks again for all your time.

Tom.

[tom_w2000]

Hi again guys,

I have been doing some thinking and some planning about all this over the weekend, and taken on board what you have said. To be honest its driving me crazy trying to find the perfect solution to this, while thinking of all the different ways I could implement things. I think the right solution will only become apparent with more experience with MVC coding and practical application. I also know the deeper you go the more subjective things are.

Ultimately I am trying to create something like the iphone interface that loads different applications based on the app clicked. Disregarding command objects at the moment, The solution I am thinking of is as follows:

1. Create a 'system View' in the document class, with its own model and controller. This system view would be like the iphone applications screen and would contain a button for each application and simply change the system model to reflect the button pressed.

2. Once the system model has loaded and the system view built, initialize a method in the document class that instantiates all the applications as single views, and push them into an array in the document class for referencing and initializing based on the navigation pressed.

3. Lastly, create a listener in the document class to listen to changes in the system Model via the system view, and dispatch an event from the model to say that a new navigation button has been pressed. The listener would then delegate this change to another method in the document class which would evaluate the application change and create the appropriate application view.

I was considering having the main system model simply dispatch an integer when a nav button (application) is pressed. The document class would contain all the application views, and these views would essentially be single classes and applications in themselves that define their own xml file, their own model, as well as their own views and controllers. This way I figured I could keep each application completely separate or swap them out in the main document class for other applications, without breaking the naviation view.

Ultimately, I am thinking each application is essentially its own programme, and therefore should have its own document class. It should thus instantiate its own xml, views, model and controller. So the main document class would simply create/ remove/initialize a series of other document (main) classes (as movieClips) based on the state of the main navigation in the main document class, does this sound right?

Marlo, you mentioned having superModels and passing superXml data to represent all the models of each application in the system, and then referencing this from the document class, but to be honest I'm having a hard time getting my head around this solution.

If you feel the superModel approach is a better way to go I will spend some more time on figuring out how I should do it exactly, I just feel I need some reassurance from you guys to say which is the better approach (OOP wise)... I think I can figure out the rest.

Cheers again,

Tom.

[jAQUAN]

You're definitely thinking correctly about separation of duties. You might even consider making each "app" a separate .swf which the main "OS" app will load/unload.
To be honest it sounds like an awful lot to tackle for one's first foray into MVC. You might want to hone your skills by first working on these individual apps. Each one is bound to use some similar start up routine which will help you get familiar with what constitutes reusable code. Like each app's Main would probably implement the same Interface. This would help you prepare to start plugging them into the OS app in way where you could be confident about calling init methods on them in the same way.

Each app will also likely load and unload assets which will help you get comfortable doing so on the OS level.

The truth is, you're simply not going to write the perfect implementation your first few times out. After a certain point, it doesn't make you a better developer to constantly refactor a finished app. You will however learn a ton of things you'd like to do differently next time, and next time is when you should try them. Just get it done and take what you've learned on to the next project.