Analysis of Zend's MVC mechanism usage (1)_PHP tutorial

代码

这个类是管理front的插件的类。先看一个Front中的方法public function registerPlugin(Zend_Controller_Plugin_Abstract $plugin, $stackIndex = null)

意思是如果你有一个自己的插件要插入使用的话，调用这个函数能把你自己的插件委托给Zend_Controller_Plugin_Broker使用。

如果你有愿望继续跟下去你会看到注册插件做的一件最根本的事情就是把request和response放入到你的插件中去(setRequest和setResponse)。

class Zend_Controller_Plugin_Broker extends Zend_Controller_Plugin_Abstract

这个实现了抽象类Zend_Controller_Plugin_Abstract。
Zend_Controller_Plugin_Abstract是所有插件的抽象类，所有用户自己定义的插件或者Zend已有的插件都要从这个类继承。这里就看到了，前端控制器Front就是使用broker作为用户插件注册。

这个抽象类可以被实现的函数有：

routeStartup: 在路由发送请求前被调用

routeShutdown：在路由完成请求后被调用

dispatchLoopStartup:在进入分发循环（dispatch loop）前被调用

Predispatch：在动作由分发器分发前被调用

postdispatch:在动作由路由器分发后被调用

dispatchLoopShutdown:在进入分发循环（dispatch loop）后被调用

我们还看到了getRequest, getResponse两个方法，我们可以通过他们分别从控制器中获取request对象和response对象

好了，扯远了，回到最开始的代码，Zend_Controller_Front::getInstance实际上来看做的事情就是注册了一个broker插件放到$front中。

下面一行代码

Zend_Layout::startMvc(array('layoutPath' => USVN_LAYOUTS_DIR));

看到Zend/Layout.php中，startMvc做了两件事：首先是调用自己的构造函数来实例化自己（切记带着initMvc参数为true），然后是设置参数。

Zend_Layout的构造函数比较复杂，就跟到里面看看。首先也是设置传递进来的参数$options,我们这个例子中是传递进来Array ( [layoutPath] => /var/www/html/usvn/app/layouts )这个array作为options，构造函数就是调用$this->setOptions($options);

这个setOptions做的事是根据array的每个key，调用$this->set$key($val);也就是说，以上面的例子来说，setOptions调用了setLayoutPath("/var/www/html/usvn/app/layouts")

顺藤摸瓜，setLayoutPath的功能是设置自己类的this->_layout为"/var/www/html/usvn/app/layouts"， 然后设置_enable为true；这两个属性记住，以后会有使用的。

回退到Zend_Layout的构造函数，初始化options之后是调用了_initVarContainer();

这个函数做了这么个事情：

$this->_container = Zend_View_Helper_Placeholder_Registry::getRegistry()->getContainer(__CLASS__);

又出现了Zend_View_Helper_Placeholder_Registry（我翻译为：Zend视图助手注册表）

getRegistry() 将Zend_View_Helper_Placeholder_Registry作为key，Zend_View_Helper_Placeholder_Registry类的实例作为value注册到之前见过的Zend_Registry中。这个类的构造函数就什么事都没有。

getRegistry()返回了Zend_View_Helper_Placeholder_Registry实例，下面调用getContainer(__CLASS__)。 这里的__CLASS__是什么，当前调用的类，自然就是Zend_Layout了。这里是getContainer("Zend_Layout")

进入到getContainer里面，它调用了createContainer("Zend_Layout")。createContainer("Zend_Layout")是在Registry中以Zend_Layout为key，Zend_View_Helper_Placeholder_Container类为value的array。

Zend_View_Helper_Placeholder_Container实现抽象类Zend_View_Helper_Placeholder_Container_Abstract，这个抽象类实际上也是一个ArrayObject，这个在之前的文章有提到过了，是一个和泛型类一样的东东。

好了，这里不跟下去了，回头到Zend_Layout的构造函数

_initVarContainer结束了，下面是调用两个重要的函数：

$this->_setMvcEnabled(true);

$this->_initMvc();

Mvc大家一定很熟悉，我们来看看这里是怎么个MVC的

setMvcEnabled没什么特别，设置标志位this->_mvcEnabled

_initMvc做了两件事，_initPlugin和_initHelper。

先看initPlugin:

获取PluginClass,这里的pluginClass就是Zend_Layout_Controller_Plugin_Layout，可以看到，这里是作为一个插件的形式放进来的。

Then the instance of Zend_Controller_Front was obtained and called:

$front->registerPlugin(

new $pluginClass($this),

99

);

Remember the previous analysis of Zend_Controller_Front? There is a function of registerPlugin, which delegates the plug-in to the front broker for use. Some people will ask what the 99 at the end means? It is the index order of plug-ins. The later the plug-in is, the later the plug-in action will be executed.

Look at _initHelper below:

Get the helperClass, the helperClass here is Zend_Layout_Controller_Action_Helper_Layout

if (!Zend_Controller_Action_HelperBroker::hasHelper('layout')) {

. . .

Zend_Controller_Action_HelperBroker::getStack()->offsetSet(-90, new $helperClass($this));

}

If Action_HelperBroker does not have a layout helper

Execute the offsetSet command below. Pass in -90 and the Zend_Layout_Controller_Action_Helper_Layout instance as parameters.

The same relationship as the plugin, save the Zend_Layout_Controller_Action_Helper_Layout instance as value to this->_helpersByPriority and this->_helpersByNameRef

The -90 in front is the weight, and it is also necessary to ensure that this helper is called last (see the last line for krsort sorting)

Okay, this concludes the analysis of Layout's constructor.