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

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)⁸

IV The Benefits of using The MVC Pattern¹

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

———–

II. MVC and Object Orientation

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.

I. 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 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).”

Last Time

At the end of the last discussion on Zend_Config, I mentioned how it would be interesting to leverage the code already existing in Zend_Confing, instead of reinventing the wheel. Our main issue was how to use defined PHP constants in an ini file (or in an xml file).

View a better formatted version of the code in this post here

A Solution

We will extend Zend_Config_Ini with a custom method to find references to defined constants in a configuration object and resolve them. The resulting class should function exactly as Zend_Config_Ini would for “normal” ini files. First we need to know what are the constants already defined at the time Zend_Config_Ini parses our ini file. PHP does this easily
with the get_defined_constants() function (available in PHP 4 >= 4.1.0, PHP 5). Next we need to tell our extending class when it can find and replace defined PHP constants in a configuration object.

Extending Zend_Config_Ini

We will call our new class ConfigPhp (I’m sure you could find a better name):

class ConfigPhp extends Zend_Config_Ini{ //...}

Its constructor shall refer to Zend_Config_Ini constructor.

Tell ConfigPhp When To Parse Defined Constants

We need to tell ConfigPHP when our ini file contains PHP defined constants. The ConfigPhp constructor can be used:

public function __construct($filename, $section, $config = false)
{
if (is_array($config))
{
$this->php_defs = $config["php_defs"];
$this->allow_mods = $config["allow_mods"];
} //...
}

Where $config["php_defs"] is a boolean telling whether or not the ini file contains defined PHP constants.

Using Defined PHP Constants

When our ini file contains defined PHP constants, and we have told ConfigPhp by setting $config["php_defs"] to true, the constants are found in the configuration object and replaced with their real values.

if($this->php_defs)
{
$this->data = $this->toArray();
$this->parsePHPDefs();
}

The parsePHPDefs() method

The parsePHPDefs() is the heart of this extension. It will retrieve the data contained in the Zend_Config_Ini object and for all ocurences of defined PHP constants replaces them with their real value:

protected function parsePHPDefs()
{
$report_error = null;
$this->defined_constants = get_defined_constants(true);
if (is_array($this->defined_constants["user"]))
{
foreach($this->defined_constants["user"] as $key => $value)
{
foreach($this->data as $datakey => $dataval)
{
if($datakey == 'includes')
{
$report_error = ini_get('error_reporting');
error_reporting(0);
foreach($dataval as $inckey => $incval)
{
$pattern = '/(\.)?'.$key.'(\.)?/';
$incval = preg_replace($pattern , $value, $incval);
error_reporting($report_error);
$this->data["includes"][$inckey] = $incval;
$this->__set($inckey,$incval);
}
}

}
}
}
}

The get_defined_constants(true) method will return an array of arrays. Each key in that array refers to the origin of the defined constants in the array it has as value. Thus
$this->defined_constants = get_defined_constants(true);
$this->defined_constants["user"] will refer to the constants we have defined (at a point or another before this code is reached). For each defined constant we search each value in our Zend_Config_Ini object and for each occurence of it replace it with the actual value of the constant. You would notice the line if($datakey == 'includes'). It just that the values I have in my ini file all start by the string “includes.”. It would be easy to parameterized this, and be able to replace arbitrary values in the ini file. In fact I use the Zend_Config_Ini object to set my include_path. I created a method to do so:

function makeIncludePath()
{
foreach($this->data as $datakey => $dataval)
{

if($datakey == 'includes')
{

foreach($dataval as $inckey => $incval)
{
$this->include_path.=$incval. DS.PATH_SEPARATOR;
}
}

}//....}

Advantages

Let’s say you are integrating a third party library to Zend and would like to make some constants defined in the library available to your Zend Application, but you want to use Zend_Config_Ini and … an ini file. This approach would allow you to access the third party library (or application) defined constants within your ini file.

Rationale

The approach itself might seem a bit of an overkill. I mean why use predefined constants in an ini? The point here is that it is possible, and someone out there might need such a feature. I do for once. I would use Zend_Config to help me in setting paths (Include_path) during the bootstrap process. To bootstrap, I need to define a minimal set of PHP constants. For example:

//Forced to have these declarations here as a minimum requirement for bootstrap to happen
if(!defined('DS'))
{
define('DS',DIRECTORY_SEPARATOR);
}
define ('MY_LIBS', dirname(dirname(dirname(__FILE__))).DS.'libs');
define ('MY_APP',dirname(dirname(dirname(__FILE__))).DS.'apps'.DS.'my_app'.DS.'application');
define('MY_ZEND_CORE',dirname(dirname(dirname(__FILE__))).DS.'libs'.DS.'zend'.DS.'library');
if (function_exists('ini_set')) {
ini_set('include_path', ini_get('include_path') . PATH_SEPARATOR . MY_ZEND_CORE .DS . PATH_SEPARATOR . MY_APP . DS);

}
//end bootrap declarations

I keep my applications folders and library folders out of the server’s webroot. So these constants are needed so I don’t have to write long paths every time I refer to a file in my app or in the libraries. The settings in the ini file might need to “knnow” about these constants.

Improvement

I am aware that there is room for improvement. The Zend_Config class itself could be extended instead of the Zend_Config_Ini class, so that Zend_Config_XML benefits from the parsePHPDefs method. I will probably take more time to see what can be improved. Don’t hesitate to give your point of view on the matter. You might not even like this approach, please let me know why.

There is a Zend Framework class to help in configuring your application. You can use it to save and retrieve configuration data. It’s called Zend_Config . For examples on how to use it see http://framework.zend.com/manual/en/zend.config.html.

It allows you to use an ‘.ini’ or an xml file to load your configuration settings. You can then access them as you would of any objects property. Thus if you have this line

include.path = 'a/path/'

in your ini file, after using Zend_Config_Ini, you would access it in this manner

$path = $config->include->path;

The process would be similar if you had used xml instead and Zend_Config_Xml.
While being really handy, this method still presents some challenges. An example seaks louder thhan words:

includes.APP_MODELS_DIR = MY_APP.DS.'models';

where MY_APP and DS are constants defined in my boostrap file, let’s say.
The parse_ini_file() php function, used by Zend_Config_Ini does’nt resolve MY_APP and DS to their proper values. And don’t even try to use such a syntax

includes.APP_MODELS_DIR = <?php MODEL_DIR.DIRECTORY_SEPARATOR."somestring";?>

otherwise you would get an error. I mean it’s quite understandable. The parse_ini_file() function is expecting ini syntax and nothing else.
Since I use constants extensively when defining my paths (app,libs,controllers,vendors paths for example), I ‘ld rather create an ‘include’ object. For example I would have an ‘include.php’ file:

$includes = null;
$includes->MODELS_DIR = MY_APP.DS.'models';
$includes->APP_MODELS_DIR = MY_APP.DS.'models';
$includes->APP_CLASSES_DIR = MY_APP.DS.'classes';
$includes->PLUGINS_DIR = MY_LIBS.DS.'ZendPlugins';
$includes->VIEW_PATH = MY_APP.DS.'views'.DS.'scripts';

where I can use previously defined constants (they are defined in the bootstrap file as a necessity for the bootstrap to happen at all).
Then I write a utility function to parse the object into an ‘include string’ that I append to my include path:



function makeIncludePath($includes)
{
$include_path='';
if($includes)
{
foreach($includes as $inc)
{$include_path.=$inc. DS.PATH_SEPARATOR;}
}
ini_set('include_path', ini_get('include_path') . DS.PATH_SEPARATOR.$include_path);
}

In a suitable place, before the dispatch process has started, I write



require_once 'config_utils.php';
require_once 'includes.php';
makeIncludePath($includes);

I realise that by using my own object I lose the benefit of all the convenient methods defined in Zend_Conf_Ini, but for such a simple job, I might not feel the difference. Yet I am thinking about extending Zend_Conf_Ini with the method discussed above. I might be worth it. Find out more on the subject here:
Using ZEND_Config Part 2

Background

In his article “integrating propel with the Zend Framework” , Ralph Eggert explains how one could integrate propel to his Zend application. It’s interesting to see how an _autoload php function can be used to automatically load needed classes (propel,or Zend classes) and thus avoid having to explicitly include the propel files in every controller that would need access to the model.

From there

One area that the article did not mention was, how does the app know which model will be used? I mean, let’s say a client clicks on the link “controller/action”, do I have to wait for the front controller to dispatch the request to the controller before knowing that it was called? That is, the entity referenced by the request is known explicitly by my application only when the requested action code is about to be executed.
Before going further we have to make some assumption about our application. We will assume that each controller relates to one entity in our model. For example, the “apple” controller is the “apple” model’s controller.

Use case

Let’s say I want to apply business logic that involves one more additional models(or should I say entity in the model?) before the controller’s action is called. Then I would need to know the controller(thus the model) mentinoed in the request URL before the the action is actually dispatched.

Using a Plugin

The Zend Framework plugin system provides a solution to this problem. The solution involves writting a plugin and registering it. The Zend Framework documentation says it better than me:

The controller architecture includes a plugin system that allows user code to be called when certain events occur in the controller process lifetime. The front controller uses a plugin broker as a registry for user plugins, and the plugin broker ensures that event methods are called on each plugin registered with the front controller.

The event I’m looking for is the routeShutdown event. It means that the router is done parsing the request URL and has populated the Request object with the controller name and action name. At this point I can use this code $controllerName = $this->getRequest()->getControllerName(); to get the controller name. From there on, the logic really depends on what you want to achieve and the naming convention of your model classes, among others. In my case, I renamed the ORM generated classes so that they have the same name as the controllers, only that they are camel cased. In fact I use the propel generated model classes as the abstraction layer to the database. The business logic, I will call the model service. This is what is done to the data that propel will give me from the database. Hence I could have controller ‘user’ ,model ‘User’, and model service ‘UserService’ . Here is the code for my plugin:

public function routeStartup(Zend_Controller_Request_Abstract $request)
{
//$this->getResponse()->appendBody("<p>routeStartup() called</p>\n");
}

public function

routeShutdown(Zend_Controller_Request_Abstract $request)
{
$controllerName = $this->getRequest()->getControllerName();
$modelClass = ucwords($controllerName).'.php';
$modelServiceClass = ucwords($controllerName).'Service.php';

if (file_exists('path/to/your/app/propel/generated/files/modelClass'))
{
require_once($modelClass);

}

if (file_exists('path/to/your/app/modelServiceClass'))
{
require_once($modelServiceClass);

}
}

public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
{
//$this->getResponse()->appendBody("dispatchLoopStartup() called\n");
}

public function preDispatch(Zend_Controller_Request_Abstract $request)
{
//$this->getResponse()->appendBody("preDispatch() called\n");
}

public function postDispatch(Zend_Controller_Request_Abstract $request)
{
//$this->getResponse()->appendBody("postDispatch() called\n");
}

public function dispatchLoopShutdown()
{
//$this->getResponse()->appendBody("dispatchLoopShutdown() called\n");
}
}

Visit this link for better formatted listing of this code.