Model View Controller Login for Flash

This is a Flash example of the MVC (Model-View-Controller) design pattern, the most common design pattern. It is completely XML-based, and any changes in text can be done by just changing the XML file. Before we go into more details test the Login movie below.

The important part of this is to create independent scripts for projects and to separate what is going on behind a movie from the view of the movie. A common design pattern is the Model-View-Controller design pattern as shown in the figure below.

MVC schema


In our movie we have a Document class and all what is happening here is to call the individual parts as shown here . What we actually see in the movie is represented by the Viewer. We can have more than one viewer. For the login we have two viewers, the LoginView class (press to see the code) , which encodes the textinput fields and the buttons and the AlertView class (press to see the code) , which encodes an Alertbox, which pops up in case of errors. If you look at both classes you will see that they communicate with the Controller but also the Model class. The LoginView class communicates with the controller by dispatching events using a custom Event class. This causes uncoupling of the views and the controllers. The Model class is loading the data file and the data are needed to populate textfields etc. We call all the datafile data from the viewer class and by this way leave the Model class independent. The viewers have eventlisteners and receive notice from the Model class about any changes. The independence of the classes makes it possible that we can easily create another Viewer class and use the same Controller - Model classes. Part of the Viewer is the AbstractClass , which is a superclass and contains functions for the Viewers, which have to be overridden.


Any action from the viewer classes goes to the Controller, which has its own interface. Simply orders received from the viewers are directed to the Model class, where they are processed.


All strings end up in the Model class. The XML file is loaded into the Model class and is now available for the viewers. The XML file contains all the text for the Label components and Button components as well as URLs for scripts and sites. Looking at the Model class we see several constants for eventhandlers. These trigger events in the viewers whenever there is a change, for example when an alert is triggered or a response comes back from the server. The heart of the Model class is the update function, which dispatches the various events. The Model class has also its own interface, the IModel class. And this concludes the explanation.

Leave any comment here.