Observer:

/* requires AmplifyJS */

};


View:

/* requires AmplifyJS */

//peform view specific initialisation.
var i=0;
if(aTriggers)
{
for(i=0; i<aTriggers.length;i++)
{
eval('this[aTriggers['+i+']['+0+']]' +'=function(){view.prototype.publish("'+aTriggers[i][1]+'")}');
}
}
}
view.init(aTriggers,aEventsToPublish, aEventsToSubscribeTo);
return view;
};


Find the remainder of the code here

Around this pattern, the Controller, the View and the Model are built.
Here you have an example model:


numnber_of_clicks_model = (function (){
var pubsub = amplify;
var _number = 0;
NUMBER_INCREMENTED = 'NUMBER_INCREMENTED';
obj = {
'incrementCounterHandler': function (){++_number; pubsub.publish(NUMBER_INCREMENTED, {'number': _number}) },
'decrementCounterHandler': function (){_number = (_number>0) ? --_number: 0; pubsub.publish(NUMBER_INCREMENTED, {'number': _number}) }
pubsub.subscribe('INCREMENT_COUNTER',obj.incrementCounterHandler);
pubsub.subscribe('DECREMENT_COUNTER',obj.decrementCounterHandler);
return obj; }());


Download it here: https://subversion.assembla.com/svn/pusubmvc/

The files may look big in size, but really, only jquery.js and amplify.js are needed.

They give the example:

var CompoundObject = {

string1: ‘default value’,

childObject:{bool: true, num: 10}

}

var compoundObjectClone = clone(CompoundObject);

// Bad! Changes the value of CompoundObject.childObject.num.

compoundObjectClone.childObject.num = 5;

They propose a solution in the book that entails using a factory method to creates the inner compound property on the cloned object:

CompoundObject.childObject = CompoundObject.createChildObject();

var compoundObjectClone = clone(CompoundObject);

compoundObjectClone.childObject = CompoundObject.createChildObject();

compoundObjectClone.childObject.num = 5;

To solve the same problem Ben Nadel advocates the use of super constructor call from within the sub-class constructor in order to create all the parent object properties in the child object properties. That is, the child has its own copies of the parent’s properties. His solution works fine even if it is kind of indiscriminate when it comes to which and when a parent property should be created at the child level.

I looked into ”Pro Javascript Design Patterns” and at Ben’s solution and came up with two, albeit less simple, solutions to the same problem.

In one of them, the clone function of “Pro Javascript Design Patterns” is modified to create specified properties of the “prototype object” directly on the child object. This way “prototype-chain walking” stop at the child itself and does not ascend to the prototype object.

In another solution, the prototype object itself is defined by an immediately executed function in the scope of which the problematic property is defined as a var. It’s a closure and it cannot be accessed by “dot notation”. We then return an object literal that contains accessor and mutator functions. The accessor checks if the property accessed is on the object or on it’s prototype. If on the prototype, it returns a copy, not a reference. The mutator sets the property directly on the literal object.

Now, for a longer explanation. Here we have the  first attempt at a solution. In it, we use the “clone” function shown in “Pro Javascript Design Patterns” and modify it as such:

function clone(object,instance_members) {

function F() {}

F.prototype = object;

var _f = new F;

_f.prototype = object;

// instance_members specifies those members of the object parameter that are supposed

// to be copied by value instead of by reference.

// We specify instance level member this way. It helps in keeping modifications

// to the similar properties on the prototype to cascade to the copies.

// Members of the object parameter that are not so specified can be thought of

// as shared members.

if(arguments.length>1)

{

if(!(‘[object Array]‘ === Object.prototype.toString.call(instance_members)))

{

throw new Error(“the second argument to clone function must be an array of strings”);

}

for(i=0;i<instance_members.length;i++)

{

_f[instance_members[i]] = deep_copy(object[instance_members[i]]);

}

}

return _f;

}

The modified clone function can be used in this manner:

var CompoundObject = {

string1: ‘default value’,

childObject: {

bool: true,

num: 10

},

getString: function(){

return this.string1;

}

}

var compoundObjectClone = clone(CompoundObject);

//we specify  instance level members in the array parameter

var obj2 = clone(CompoundObject,['childObject']);

// Bad! Changes the value of CompoundObject.childObject.num.

// However it will not affect obj2 created earlier since it’s childObject parameter

// is set at the instance level.

compoundObjectClone.childObject.num = 5;

// obj3 is created from the modified compound object.

var obj3 = clone(CompoundObject);

alert(“compoundObjectClone = “+compoundObjectClone.childObject.num)

alert(“obj2 = “+obj2.childObject.num)

alert(“obj3 = “+obj3.childObject.num)

I came up with another solution using closures and the original clone function of  ”Pro Javascript Design Patterns”:

var CompoundObject = (function()

{

this.string1 = “default string”;

var childObject = {

bool: true,

num: 10

};

return {

getChildObject:  function(){

if(!this.hasOwnProperty(‘childObject’))

{return deep_copy(childObject);}

return this.childObject

},

setChildObject:function(cobj){

this.childObject = cobj;

}

}

})();

In the definition of the object that we want to use as prototype, we define the problematic compound object as a “var” so that it is not visible outside the prototype object’s definition. Moreover we use accessor and mutator methods to manipulate its value.

We can now set the value of the compound object on a child object without changing the prototype property:

var compoundObjectClone = clone(CompoundObject);

var obj2 = clone(CompoundObject);

alert(obj2.getChildObject().num);

var cobj = obj2.getChildObject();

cobj.num=5;

obj2.setChildObject(cobj);

alert(‘obj2.getChildObject().num = ‘+obj2.getChildObject().num);

var obj3 = clone(CompoundObject);

alert(‘obj3.getChildObject().num = ‘+obj3.getChildObject().num);

With this solution, the object used as prototype is responsible for ensuring it’s own integrity.

The deep_copy function used in the code comes from Stephen Chapman

update: I have posted a very simple implementation of MVC here

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.

We will cite Lech MADEYSKI, Michał STOCHMIAŁEK¹ :

• 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.

A typical MVC application can be represented by this diagram²

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.

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 diagram³

This approach to adapte MVC to a web environment was termed the MVC/Model 2 design pattern.

On the Apache Struts website ⁴ 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.⁵

In fact with this pattern there are two communication cycles 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.

Mixed client-side and server-side MVC

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.⁶

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.⁷

Mixed client-side and server-side MVC (2)⁸

• 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 become easier to make.
• With MVC it can be easier to test the core of the application, as encapsulated by the model.

V The problems of MVC²

• 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.
• 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.

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.

III.3 The communication between the View and the Controller

As explained in Steve Burbeck 1992 paper on MVC and Smalltalk:

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 its state has been modified.

———-

Note:

The tight coupling of the view and the controller have pushed some implementers of the MVC pattern in the GUI world to combine the view and the controller into one element called the View, whereas the model is called the Document. Such a pattern is then called the Document View pattern¹

———–

From 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:

The models are represented in the computer as a collection of data together with the methods

necessary 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. 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 us just remember that both patterns have been applied successfully in Smalltalk-80, with the object orientation supporting the MVC pattern.

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 I

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 1979.

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 attributes

of 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. (…)

messages 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 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 Burbeck 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).”