代码

分析

首先看下Zend_Controller_Front::getInstance是调用单例模式，实例化了它的内部属性_plugins，实例化了一个Zend_Controller_Plugin_Broker类。

这个类是管理front的插件的类。先看一个Front中的方法public function registerPlugin(Zend_Controller_Plugin_Abstract plugin,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。

这里有一系列的文章很不错http://blog.csdn.net/mengxiangbaidu/article/details/7228777

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，构造函数就是调用options,我们这个例子中是传递进来Array([layoutPath]=>/var/www/html/usvn/app/layouts)这个array作为options，构造函数就是调用this->setOptions($options);

这个setOptions做的事是根据array的每个key，调用this−>setthis−>setkey($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，可以看到，这里是作为一个插件的形式放进来的。

接着又获取了Zend_Controller_Front的实例，调用：

$front->registerPlugin(

new pluginClass(pluginClass(this),

99

);

记得前面对Zend_Controller_Front的分析不？里面有registerPlugin的函数，是将插件委托给front的broker来用。有人就会问后面的99是什么意思？是插件的索引顺序，越后面的插件越后执行插件的动作。

下面再看_initHelper：

获取helperClass，这里的helperClass就是Zend_Layout_Controller_Action_Helper_Layout

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

。。。

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

}

如果Action_HelperBroker没有layout的helper的话

就执行下面的offsetSet命令。将-90和Zend_Layout_Controller_Action_Helper_Layout实例作为参数传入。

和plugin同样的关系，将Zend_Layout_Controller_Action_Helper_Layout实例作为value存入到this->_helpersByPriority和this->_helpersByNameRef去了

前面的-90是权重，也是要保证这个helper是最后调用（看最后一行是krsort排序）

好了，Layout的构造函数就这样分析结束了。