MVC in the Browser

Chapter I: What is MVC? A Very Brief History Of MVC

In a paper published by Trygve Reenskaug in 2007, he explained when and why was the MVC pattern created. Here is what he said:

I made the first implementation and wrote the original MVC reports while Iwas a visiting scientist at Xerox Palo Alto Research Laboratory (PARC) in1978/79. MVC was created as an obvious solution to the general problem ofgiving users control over their information as seen from multiple perspectives.MVC has created a surprising amount of interest."

It is important to note that the pattern in it first days did not carry the name of MVC, but rather the lengthy name of THING-MODEL-VIEW-EDITOR as it was described in a note entitled « THING-MODEL-VIEW-EDITOR -.an Example from a planningsystem » published in May 19791.However, just a few month later, in December 1979, the terms Model,View, and Controller were adopted by Reenskaug in the MODELS - VIEWS – CONTROLLERS note. In this note Trygve Reenskaug discuss the meaning of the M, V and C of MVC. He describes the Model by these words:

« Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. »

He explains that:

A view is a (visual) representation of its model. It would ordinarily highlight certain attributesof the model and suppress others. It is thus acting as a presentation filter.

Finally he states that:

A controller is the link between a user and the system. (...)The controller receives such user output, translates it into the appropriatemessages and pass these messages on to one or more of the views.

After Trygve Reenskaug left Xerox PARC, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library, whose first public release happened in 1983. If fact in their « The Language and

1 http://heim.ifi.uio.no/~trygver/1979/mvc-1/1979-05-MVC.pdf

1

MVC in the Browser

its Implementation », a book on Smalltalk-80, Aele Goldberg (who had discussed the renaming of THING-MODEL-VIEW-EDITOR to Model-View-Controller with Reenskaug ) and David Robson present MVC and its use in Smalltalk.

A description of the MVC pattern as implemented in Smalltalk-80 v2.5 written by Steve Burbeck2 in 1992 (a 1987 version exists) presents it with these words:

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

II. MVC and Object OrientationFrom what we read so far we understand that MVC separates the presentation of data, the handling

of data, and the intepretation of user actions into different layers. One of the stated benefits by Trygve Reenskaug is the fact that data could be presented from mutiple perspectives. This means that, since the presentation (View) and the description of the data (Model) are embodied into different loosely coupled layers or components, the same data can be presented to the user in many different ways. That is, the data is not tied to the way it is being shown to the user. Moreover, let's read this excerpt from Steve Burbeck's text:

The formal separation of these three tasks is an important notion that is particularly suited to Smalltalk-80 where the basic behavior can be embodied in abstract objects: View, Controller, Model and Object. The MVC behavior is then inherited, added to, and modified as necessary to provide a flexible and powerful system.

We see how MVC is well suited to be implemented using object oriented techniques. As a matter of facts, Trygve Reenskaugh in his « Models-Views-Controllers » note writes on models:

2 http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

2

MVC in the Browser

The models are represented in the computer as a collection of data together with the methodsnecessary to process these data.

Now if this is not the description of an object, then what is it? Now if models can be understood as objects in MVC, why not think of Views and Controller as other classes of objects? The fact is that a lot of systems using the MVC pattern also use the object oriented pattern (examples to find). How well do both patterns fit together and how to better use them together? These are the questions that the developper of such systems and frameworks have probably tried to answer. Let's just remember that both patterns have been applied successfully in Smalltalk-80, with the object orientation supporting the MVC pattern.

III. How does MVC work?

When the user interacts with an application designed using the MVC principles, the Model, the View, and the Controller communicate together to give the user the ability to interact with the Model and perceive the expected results.There are many ways in which the Model, the View and the Controller can work together as explained by Trygve Reenskaug in his paper.

III.1 The passive model Here the Model reacts only to the Controller's requests and View's requests (if any). That is the

Model would modify or retrieve data it represents only on the initiative of the Controller or the View. So upon the user's request the controller would transmit the command to the Model and notify the View of a change in the Model's state. The View could then request the changes to the Model or the Controller could trasmit those changes to the View. The Model is thus passive.

III.2 The active model If the data represented by the Model can change as a result of actions from objects other than

its View or Controller, then there must be a way for the Model to notify its View of the change. A communication channel must exist between the Model and its View. In such case, the Model must initiate communication with the View. The Model is said to be active.

3

MVC in the Browser

III.3 The communication between the View and the ControllerAs explained in Steve Burbeck 1992 paper on MVC and Smalltalk3:

Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling. A view's instance variable controller points at its controller, and a controller's instance variable view points at its associated view. And, because both must communicate with their model, each has an instance variable model which points to the model object. So, although the model is limited to sending self changed:, both the view and the controller can send messages directly to each other and to their model.

In this excerpt 'self changed' is the message that the active model sends to its views to tell them that it's state has been modified.

IV The Benefits of using The MVC Pattern4

* Different views and controllers can be substituted to provide alternate user interfaces for the same model.

* Multiple simultaneous views of the same model

* The change propagation mechanism insures that all views simultaneously reflect the current state of the model.

* Changes affecting just the user interface of the application logic become easier to make.

* With MVC it can be easier to test the core of the application, as encapsulated by the model.

IV The problems of MVC5

• There's increased complexity as an apllication may use other patterns at the same time as MVC.

• The view and the controller are closely coupled wich makes modification to one affect the other.

3 http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html 4 ibid

5 Model View Controller explication page of the phpWACT framework, http://www.phpwact.org/pattern/model_view_controller

4

MVC in the Browser

• Changes to the model interface will necessitate changes to the controller and the view.

• When the model is active frequent changes to model can result in excessive updates of the corresponding views.

5

MVC in the Browser

Chapter 2: MVC and The Web

The MVC pattern was originally applied in a desktop application environment where the application resides on the computer with wich the user is interacting.While interacting with a web application, the user is sending requests to a distant server through his browser (the client). The server possess the necessary ressources to respond to the user's request. The user receives the server's response on its browser window. Thus when developers wan to apply the MVC pattern to a web application, they have to take into consideration the client/server environment in which the application operates.

I The particularities of web apllicationsWe will cite Lech MADEYSKI, Michał STOCHMIAŁEK6

:

· The HTTP protocol, the technological foundation of web applications, is stateless. Each command is executed independently, without any knowledge of the commands that came before it. Web application’s responsibility is to keep the state between requests.· Conversation between user and application can be initiated only by the user.· Control flow of web applications is driven by user requests. It usually consists of complex sequence of interactions between the user and server.

Since HTTP forces the application to be driven by user request driven, it seems that the active model pattern cannot be applied in a web environement. However such limitations are now history with the development of Comet7 which allow the server to push data towards the web client (ie the view).

II Implementing MVC in a Web Environment:II.1 Why use MVC in a Web Application?

The advantages of using MVC in a web application environment are the same as the ones we enumerated in the section on MVC. To those advantages we can add the separation of the applicatin in Views, Model and Controllers allow for different team to develop the components and increases maintainability and extensibilty.

6 ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS, Lech MADEYSKI, Michał STOCHMIAŁEK, Wroclaw University of Technology, Poland.

7 http://en.wikipedia.org/wiki/Comet_(programming)

6

MVC in the Browser

II.2 Some technical considerations8:Information Security: Because the Model is responsible for maintaining the data integrity, it should reside on the server so that the user may not temper with it. Information Integrity: Moreover, by staying on the server the Model access is centralised so that changes to it will not leave it in an incoherent state. For example if every user get its own version of the model and can create, update or destroy data in the Model, how do we synchronize all the different versions of the model resulting?User/Application Interaction: There must be a way for the Controller to receive events that represent user activity. Futhermore, the View must be able to display information to the user.

II.3 Some solutionsA typical mVC application can be represented by this diagram9:

There exist different solutions to using MVC in a web application. For example server side MVC or MVC/Model 2 will host the Controller, the View and the Model on the server.II.3.1 Server side MVC or MVC/Model 2

The simplest way to use MVC in a web application is to put the Controller , the View and the Model on the server. The user request will be transmitted by the web client as a request to the server that will pass it to the controller. The controller will interpret the user request as a command to the model ( CRUD operations). The controller will make the result of the operation available to the view. The view can then send a response to the web client for display. Here the client will be considered We can represent the process by the following diagram10

8 Web MVC, http://osteele.com/archives/2004/08/web-mvc ,Oliver Steele, 20049 ibid10 Understanding JavaServer Pages Model 2 architecture, Exploring the MVC design pattern, Govind Seshadri,

7

MVC in the Browser

This approach to adapte MVC to a web environment was termed the MVC/Model 2 design pattern. On the Apache Struts website 11 we can read:

In the MVC/Model 2 design pattern, application flow is mediated by a central Controller. The Controller delegates requests - in our case, HTTP requests - to an appropriate handler. The handlers are tied to a Model, and each handler acts as an adapter between the request and the Model. The Model represents, or encapsulates, an application's business logic or state. Control is usually then forwarded back through the Controller to the appropriate View. The forwarding can be determined by consulting a set of mappings, usually loaded from a database or configuration file.12

In fact with this pattern there are two communication cycle between the different components of the MVC triad that may arise:• The « User → Controller → View → User » cycle in which the User interaction with the

application is sent to the Controller as HTTP request. The Controller chooses the View to show to the User based on the request parameters.Finally it updates the View and returns it as a response to the User.

• The « User → Controller → Model → View → User » cycle in which the User interaction with the application is sent to the Controller as HTTP request. The Controller access the Model and updates it. It chooses the View to show to the User based on the request parameters.Finally it updates the View to reflect the Model change and returns it as a response to the User.

JavaWorld.com, 12/29/99

11 Apache Struts, http://struts.apache.org/, is a framework for creating enterprise-ready Java web applications12 http://struts.apache.org/primer.html#mvc

8

MVC in the Browser

II.3.1.1 The Controller in MVC/Model 2In MVC/Model 2 the controller follows the Front Controller design pattern. In the Front

Controller design pattern, the controller is a component that centralizes all the application's request processing and view selection mechanism.13 The front controller is the only entry point to the application.The controller will receive HTTP requests map them to the appropriate model operation and then calls the model method. Finally the controller will choose the view to display depending to the user action and the model operation results.14

II.3.1.2 The View in MVC/Model 2

Here the View component role is to put together the results from the model operation, given to him by the controller, together with any static ressources comprising the view, into a response. It returns control to the Controller which serve the response to the web client.

II.3.1.3 The Model in MVC/Model 2In MVC/Model 2, the model cannot , for reason inherent HTTP, notify the view of its change of

state. The view is updated when a response is returned to the web client as a result of a user request.

---------Note:As stated earlier, methods exist now, using AJAX, to let the server, thus any component on the server, push data towards a web client.---------

II.3.1.4 The state in MVC/Model2We remember that HTTP is stateless, this means that between requests, there is no way to

remember user data or even to know which user is issuing which request. Thus in MVC/Model 2, there has to be a way to make HTTP « stateful ». User data can be kept using a Session component that will assign a session id to each user so that it may be recognised in subsequent requests. The Session Component exists at the application level, while HTTP operates at the transport level. It helps in differentiating the dialog between the web client and the application from other dialogs between other web clients and the same application.

13 Designing Enterprise Applications with the J2EETM Platform, Second Edition

14 ibid

9

MVC in the Browser

II.3.1.5 Shortcomings of MVC/Model 2

• It is not possible to update part of the view only. The MVC application as a result of each user request will entirely replace the view from which the request originated by a new one.15

• If there's a high level of interaction between the application and the user, this will result in increased HTTP requests, representing the events, being transmitted to the Controller.

• These two drawbacks cause a high bandwidth consumption and also will introduce high interaction latency (the time between a user request and the application response).

• This pattern puts a heavy load on the server processing power because it is the server's responsability to serve pages, to validate user submitted date, to generate UI's.16

Needless to say, such draw back could adversely affect user experience thus satisfaction.17

II.3.1.6 When to use MVC/Model 2MVC/Model 2 is to be used when the web application will only show information to the user

with low levels of user/application interaction.

II.3.2 Mixed client-side and server-side MVCThe issues of MVC/Model 2 not supporting high user/application interactivity, increasing

bandwidth comsumption and being unable to update only part of the view get an answer through the mixed approach consisting in moving part of the View and the Controller to the client. This is generally done using client side scripting languages as Javascript or VB script. The mix of client-side scripting language and HTML is commonly called DHTML for Dynamic HTML.The client processing power is used to carry on user data validation or view change that do not require accessing the server side Controller and/or Model.18

15 Web MVC, http://osteele.com/archives/2004/08/web-mvc ,Oliver Steele, 200416 MVC Web design patterns and Rich Internet Applications, Morales-Chaparro, R.; Linaje, M.; Preciado, J. C.; Sánchez-Figueroa F.

QUERCUS Software Engineering Group, Escuela Politécnica. Universidad de Extremadura17 ibid18 ibid

10

MVC in the Browser

With this solution there are three communication cycles between the different components of the apllication:• The « User → Controller (Client) → View (Client) →User » cycle:

In this case the user action is intercepted by the client-side Controller which decides that only the client-side View( the UI) is affected by the User's action. The client-side Controller will update the client-side View that will make the modifications visible to the User.

• The « User Controller (Client) Controller(Server) View (Server) View (Client) User→ → → → → » cycle:Here the User action is intercepted by the client-side Controller which decides to send them as HTTP request to the server-side Controller. The server-side Controller will update the server-side View and send it to the client-side View. For example, this communication cycle can be used when a User wants to change the application presentation (layout).

• The « User Controller (Client) Controller(Server) Model View (Server) View(Client) → → → → → → User » cycle:Is similar to the precedent. The difference here is that the server-side controller decides that the Model should be updated and updates the server-side View that will be sent to the client-side View and finally displayed to the User.19

II.3.2.1 The controller in mixed client-side/server-side MVC Here the controller exists accross the usual client/server division. There's a controller on the

server-side and one on the client-side. The client-side controller will perform tasks related to user data validation and client-side view update.It is responsible for deciding whether or not a user action should be forwarded to the server-side controller. The client-side controller and the server-side controller will communicate using HTTP.The server side controller functions as the controller of the MVC/Model 2 pattern.

II.3.2.2 The View in mixed client-side/server-side MVC

19 MVC Web design patterns and Rich Internet Applications, Morales-Chaparro, R.; Linaje, M.; Preciado, J. C.; Sánchez-Figueroa F. QUERCUS Software Engineering Group, Escuela Politécnica. Universidad de Extremadura

11

MVC in the Browser

The View is split in a client-side View and a server-side View. The client-side View can be updated by the client-side Controller when the user action does not involve sending HTTP request to the server-side Controller. It can be updated by the server-side View if the client-side Controller has decided to sent a HTTP request to the server-side Controller as a result of the user action.

The server-side View functions pratically as the MVC/Model 2 View.II.3.2.3 The Shortcomings of mixed client-side/server-side MVC20

• Browser compatibility: the Object model of different browsers may be different. This forces the developer to take the browsers version into account when trying to apply this pattern. The application will have to integrate browser detection and supply vendor specific versions of the client-side Controller and View.

With the mixed client-side/server-side MVC approach, we gain some interactivity, yet it is not enough as the necessity to refresh entire page when the Model is accessed does not disappear.A solution could be to move part of the Model to the client.

II.3.3 Mixed client-side and server-side MVC (2)21

When part of the Model is moved to the client, parts of the Controller also have to be moved to the client-side. With this approach the client-side Model contains a copy of the data the user wants to access. It is the client-side Model responsability to communicate with the server-side Controller when the server-side Model needs to be updated or accessed.

The drawbacks of this method are almost the same as the first version of the mixed client-side/servre-side MVC we presented. There are still compatibility issues with the different browsers.

Moreover, the browsers must support Asynchronous Javascript and XML(AJAX).However, as more and more browsers support AJAX and that Javascript and AJAX libraries are

20 MVC Web design patterns and Rich Internet Applications, Morales-Chaparro, R.; Linaje, M.; Preciado, J. C.; Sánchez-Figueroa F. QUERCUS Software Engineering Group, Escuela Politécnica. Universidad de Extremadura

21 ibid

12

MVC in the Browser

developed that abstract the underlying browsers particularities, such a solution is already becoming more attractive.

13

MVC in the Browser

Chapter 3: A Javascript Implenetation Of MVCIntroduction:We've seen that the MVC pattern will partitioned an aplication into a Model, a View and a Controller in an attempt to separate data logic(Model), user interface logic (View) and the communication logic between the data and its presentation (Controller).When trying to implement the MVC pattern for an application we have to take into account that there may be many different types of data to model. The modelisation of each data type can qualify as a model. Consequently, the presentation of each of the data types can be seen as a view. If a controller is a communication channel between a model and a view then there may be the need for more than one controller. For example, one controller for each model.From these considerations we can draw the following diagram as a general picture of our Javascript MVC implementation:

MVC js implementation

14

MVC in the Browser

Since we may have many models, views and controlllers, it is advantageous to have a manager object for models, one for views and another for controllers. Each such manager will be a Singleton.Moreover, in order to decouple the managers, we added an « Event manager » whose job it is to manage the communication between managers on behalf of each model-view-controller triad(mvc). This « Event manager » will allow us to implement a publisher/subscriber pattern between each element of an mvc.

In the remainder of this chapter we will gather more details as to the implementation of each « module » alluded to in the previous diagram.

III.1 The Event Manager Three different actions can be performed on our Event Manager (EM) by our Model Manager(MM), View Manager(VM) and Controller Manager(CM):• Register an event;• Publish an event;• Subscribe to an event;• Unregister an event;One action can be performed by our EM on MM,VM and CM:• Notify of an eventEM allows for an EM,VM and CM to constitute an mvc triad by use of event registration, publication, subscription and notification.

For example, let's say we have a simple voting application. It consists of two divs, each representing the number of 'yes' and 'no', and two buttons: one for voting 'yes' , the other for voting 'no'. Let's divide the user interface thus described into two views:• The view v1 repersents the div displaying the number of 'yes' and the 'yes' vote button.• The view v2 represents the div displaying the number of 'no' and the 'no' vote button.The view v1 registers , through its VM, a « YES_BUTTON_CLICKED » event with the EM. The view v2 registers , through its VM, a « NO_BUTTON_CLICKED » event with the EM.The view v1, which displays the number of 'yes' votes subscribes to the « INC_Y_VOTES» event of the model representing the number of votes.The view v2, which displays the number of 'no' votes subscribes to the « INC_NO_VOTES » event of the model representing the number of votes.Now let's have a controller c1 interested in the «YES_BUTTON_CLICKED» event subscribe, through

15

MVC in the Browser

its CM and the EM, to that event. The controller c1 registers , through its VM, a « VOTED_YES » event with the EM.Now let's have a controller c2 interested in the «NO_BUTTON_CLICKED» event subscribe, through its CM and the EM, to that event. The conbtroller c2 registers , through its VM, a « VOTED_NO» event with the EM.Furthermore, let a model m that represents both the number of 'yes' votes and the number of 'no' votes, subscribe to the « VOTED_YES » and « VOTED_NO » events through its MM and the EM.The model m registers a «INC_Y_VOTES» and a « INC_NO_VOTES» events with the EM through its MM.We now have the basic wiring for the voting application to function following our Jvascript implementation of the MVC pattern.If a user clicks on the 'yes' vote button here is what will happen:

16

MVC in the Browser

a. VM publishes YES_BUTTON_CLICKED on behalf of v1.b. EM notifies c1 of YES_BUTTON_CLICKED through CM.c. CM publishes VOTED_YES on behal of c1.d. EM notifies m of VOTED_YES through MM.e. MM publishes INC_Y_VOTES on behalf of m.f. EM notifies v1 of INC_Y_VOTES through VM.

This communication scheme between the different element of the mvc triad seems convoluted. Especially for the result obtained. Yet, with this arrangement, we can have more than one controller subscribe to a view event and the view can change, to some extent, without the controller needing modification. The same thing is true for the relations controller-model and model-view.

III.1.1 The Event Manager MethodsEM has five public methods:• register();• publish();• subscribe();• unregister();• unsubsribe();

III.1.1.1 The EM.register() Method:EM.register will have the follwoing signature: register(Manager im, String eventName) This method will allow a Manager (MM,VM,CM) to register one of its managed element's event as publishable. A managed element would be an element of an mvc triad.

III.1.1.2 The EM.publish() Method:EM. publish has the follwoing signature: publish(Manager im, String eventName) This method will allow a Manager (MM,VM,CM) to publish one of its managed element's event on behalf of that element. We specify the IManager object to route event notification towards the appropriate Manager.

17

MVC in the Browser

III.1.1.3 The EM.subscribe() Method:EM. subscribe has the follwoing signature: subscribe(Manager m_subscriber, Manager m_publisher , String eventName) This method will allow m_subscriber (MM,VM,CM) to subscribe one of its managed element's to an event published by m_publisher on behalf of that element. We specify the Manager object to route event notification towards the appropriate Manager.

III.1.1.4 The EM.unregister() Method:EM.unregister will have the follwoing signature: unregister(Manager im, String eventName) This method will allow a Manager (MM,VM,CM) to unregister one of its managed element's event as publishable.

III.1.1.5 The EM.unsubscribe() Method:EM. unsubscribe has the follwoing signature: unsubscribe(Manager im_unsubscriber, Manager im_publisher , String eventName) This method will allow m_subscriber (MM,VM,CM) to unsubscribe one of its managed element's to an event published by m_publisher on behalf of that element.

We can see from the methods signature that we pushed the complexity involved in the following type of questions:• which element is registering an event;• which element is subscribing to which element's event;back to the Manager implementation. It seems better to have the respective Managers manage the individual mvc triad elements' communication cycles.

III.2 Manager The Manager class will be the parent class of the MM,VM and CM. Its design follows, more or less, the Proxy pattern. That is, the IManager will register and publishes messages on behalf of its managed objects. It will pass notification messages from the EM to its managed objects. It will also create managed objects.

(add UML here)

III.2.1 The Manager Methods

18

MVC in the Browser

The main methods of Manager are:• createManaged();• remove();• notify();

III.2.1.1 The Manager.createManaged() Method:signature: createManaged(Object options)

III.2.1.2 The Manager.remove() Method:signature: remove(Managed md)

III.2.1.3 The Manager.notify() Method:signature: notify(String eventName, Object payload)

19