Magento路由分发过程解析（二）：Standard路由对象(转)

标签：

本文主要关注Magento的standard路由对象中的Mage_Core_Controller_Varien_Router_Standard::match()方法，该方法在前端控制器中调用，主要用来检查当前请求的URL地址，并决定匹配的模块，控制器以及方法，并且最后调用控制器分发该方法。

对于在上篇文章前端控制器循环所有的路由器来说，该方法完成了以下任务，

• 路由对象提供match()方法，并检测请求对象，如果匹配，则该路由对象获取该请求。
• 将请求标记为已分发。
• 设置请求对象。

假设没有找到匹配的模块/控制器/方法，该方法则返回false，前端控制器对象中的循环指向下一个路由对象，并调用其match()方法。

下面开始分析match()方法。该方法的参数为请求对象，继承自Zend_Controller_Request_Http。

Mage_Core_Controller_Varien_Router_Standard::_beforeModuleMatch()方法用于检测当前storeID是否为0，在APP模型中，管理员界面被硬编码为storeID为0（const ADMIN_STORE_ID = 0;）。可以对比下standard与admin路由对象中该方法的不同之处。

代码很简单明了，但是我还是不太理解这里的含义，首先admin路由对象是第一个循环，假如匹配了，则之后的代码不在运行。假如没有匹配，在standard路由对象中再次检测是否在管理员界面就没有意义了。先放在这里，回头研究。

先看getFront()方法，路由器对象获取了前端控制器的引用。该方法在路由抽象类中定义。那么，还记得路由器对象是如何获取前端控制器引用的吗？在前端控制器的addRouters()方法中，路由对象通过setFront()获取了前端控制器的引用，如果忘记了，看下第一篇。在某些情况下，路由对象需要询问前端控制器对象系统默认的控制器和方法是什么。默认情况下，分别是index，index，core。

那么fetchDefault()又是神马东西呢？该方法主要是引用前端控制器对象，并设置默认的模块，控制器及方法名。

这两个方法呢，实际上各自都很容易理解，但是一上一下就不是太容易理解了。总之，这里引用了前端控制器，并设置了系统默认的模块，控制器，方法。

接下来，match()方法像请求对象询问请求的路径信息，并根据顺序添加到$p变量中。

在Magento中，不会使用超全局变量去获取路径信息，Magento将其抽象为请求对象，这样可以让我们集中精力处理路由任务，而不是如何去处理路径信息。

如果没有获取到$path变量的话，则使用_getDefaultPath()方法，如下所示，

从该路径可以轻松在后台找到系统配置的位置，

System -> Configuration -> Web -> Default Pages -> Default Web URL

如果没有更改默认值cms的话，上面获取返回的默认路径的$p变量应该有下值，

array(1) { [0]=> string(3) “cms” }

这里也可以说明，为什么Magento会将首页指向Cms模块index控制器的index方法了。

获取模块名（前端命名frontName）

到此，我们已经获取到了路径信息，应该可以从路径中获取模块了。下面这段代码主要负责获取模块名。

将上述代码分开来看，首先看第一段，$request是从前端控制器中传递给路由的请求对象，我们这里尝试询问请求对象来获取模块。那么问题来了，在上面的代码当中，我们已经获取到$p路径信息，为什么不从$p中直接获取模块呢？实际上，在一个普通的请求对象中是不包含模块名这个属性的。不过，绑定Magento系统的一些事件，可能会在第一个路由对象调用其match()方法之前，处理请求对象，并添加模块属性到请求对象当中。这个过程在默认路由促发请求模块产生404页面的时候有所表现，我们会在后面的文章中深入了解这块内容。

接着看中间那段代码，

如果$p中包含模块路径，则使用它。但是，假如在$p中没有获取到模块名，Magento会使用之前代码中提到的，在前端控制器中设置的默认模块。这种情况只发生于下列路径没有设置值的情况下。

System -> Configuration -> Web -> Default Pages -> Default Web URL

然后是最后一段，如果依然没有找到$module，我们需要再进行一次硬编码的判断，在standard标准路由中，这里肯定就会返回false了。如果这里是在admin路由中，则获取到模块为admin。

获取模块全名

这里我们已经获取到了模块名(前端命名frontName），实际上，如果仔细了解Magento配置文件的话，我们会发现，在路径中$p[0]显示的实际上是配置文件里frontName节点的值。frontName一般情况下可以默认使用模块名称，但是它并不一定就是模块名。所以现在需要获取模块全名，例如上面获取到的frontName是catalog，这里全名就是Mage_Catalog。当然，这只适用于frontName与模块名相同的情况下。

于是就有了下面这段代码中的getModuleByFrontName()方法，即通过前端命名获取模块名。

好的，非常简单的一个方法，那么问题是_modules属性是什么？从哪里被赋值的？$_modules属性是路由对象的一个属性，声明为数组，默认为空。数组键为前端命名frontName，数组值为相对应的模块全名（可能包含多个，以数组组织）。在前端控制器中遍历路由对象的时候，在实例化路由对象之后，立刻调用了该路由对象的collectRoutes()方法，在该方法的最后，调用了addModule()方法，$_modules属性就是在这里被赋值的。

那么我们现在暂时先离开match()方法内部，跳到collectRoutes()方法看下这个方法对于路由对象的作用。

Collecting the Routes

collectRoutes($configArea, $useRouterName)方法从代码上来分析，主要用来给$_modules和$_routes属性赋值。首先，根据传入的参数，$configArea，frontend或admin，遍历config.xml配置文件中的/routers节点，如下代码，

通过Mage::getConfig()->getNode()方法，$routerConfigNode获取到了config.xml配置文件中所有模块的路由信息，这里有必要复习下模块配置文件里对于路由配置的相关代码。

这是一个典型的模块路由配置的代码，在系统运行时，全局config.xml文件会集合所有模块的配置文件，并根据节点进行整理。那么Mage::getConfig()->getNode()方法根据参数($configArea.’/routers’)即可判断是读取admin还是frontend下的routers节点内的路由配置文件了。如果获取到了该值，通过children()读取该节点下的所有路由配置信息，并赋值给$routers。

在相应的路由对象中，获取到各自的路由配置信息之后，需要将其赋值给该路由对象的$_modules及$_routes属性，这部分主要由以下代码完成，

这里，将对应路由对象的路由配置信息读取完毕之后，全部赋予$modules数组。最后，通过addModule()方法，将路由对象对应的所有模块和路由信息分别添加到属性$_modules和$_routes中。一定要将这两个属性好好记住。

继续Mage_Core_Controller_Varien_Router_Standard::match()方法

了解上述内容之后，我们继续上面说到的那段代码，如果没有找到匹配的模块，尝试最后一次进行模块匹配。如下代码。如果依然没有找到，则返回false，前端控制器中的路由器迭代进入下一个路由对象。

获取控制器

一切正常的话，我们已经获取到了候选的模块，接下来该获取控制器进行分发了。Magento会循环候选模块的数组（通常情况下只有一个，例如array(‘Mage_Catalog’))。

在该循环中，第一件事情便是通过设置路由配置信息来操作请求对象。看下getRouteByFrontName()方法，该方法通过$_routes属性获取到路由配置信息的路由节点名称。

需要复习下的是，路由配置信息名是config.xml文件中<routers>的直接子节点。获取路由配置信息名之后，一起来看下请求对象中的setRouteName()方法。

可以看到，除了给请求对象的$_route属性赋值以外，Magento还通过前端控制器中的getRouterByRoute()方法，获取当前路由对象，并根据路由配置信息名获取前端命名赋值给请求对象的$_module属性。

那么这里的$_module指的是什么呢？通过编辑器查看setModuleName()方法可以发现，该方法实际上是在请求对象的父类Zend_Controller_Request_Abstract中定义的。也就是说，这个$_module是Zend框架的模块名，而不是Magento中定义的模块名。

继续match()方法寻找控制器的代码，如下，

这段代码似曾相识吧？和上面查询模块名的代码十分相似。首先，向请求对象查询控制器（如果说在其它地方设置了自定义控制器的话）。如果没有，在$p中查找。假如在这里也没有获取到控制器，则通过前端控制器获取默认的控制器，默认情况下，为core模块的index控制器。

接下来，相似的代码，用来获取控制器方法，

去除复杂部分，总结下上述获取模块，控制器，控制器方法的一个相同模式，

• 首先询问请求对象
• 接着询问$p数组变量
• 最后询问前端控制器默认设置

验证并获取类及相关文件

到这里，我们已经获取到了控制器及方法名。接下来，在当前模块内查找是否存在和控制其与方法名相对应的控制器类文件。如下代码，

通过该方法的名字可以很容易了解它的作用，该方法根据参数（模块和控制器），生成类文件名及类名，并验证该类文件中是否真实定义了这个类。一起来看下它的定义，

在该方法内部，通过另外三个方法，首先获取并验证控制器文件名；

接着，通过getControllerClassName()方法获取完整类名；

最后，通过上面两个方法获取的结果，最后一次验证是否该类已经被定义，并存在于该类文件中。

经过这三步验证之后，我们确定了该控制器类文件存在，并且该控制器类已经定义。If you’re ever wondered why controllers aren’t auto-loaded classes, wonder no more.

We’ll leave the specifics of all this as an exercise for the reader. The main take away here is that this method contains the name of the controller file and class that Magento will be looking for, and I’ve found this is the best place for a few temporary strategic var_dumps when debugging routing problems.

好了，跳出validateControllerClassName()方法，继续下面一段代码。如果没有获取到控制器类名的话，则循环下一个模块，继续查找。

当然，如果一切都没问题的话，则实例化该控制器类，通过如下代码，

最后，查看在该类中是否存在上面获取到的方法，通过如下代码，如果一切顺利的话将标志$found设置为true，跳出循环。

路由分发的最后时刻

看到这里，加上第一篇，实际上一周时间已经结束了，但是很幸运，路由的最难的这一部分已经攻了下来。废话少说，看下面这段。在standard路由当中，这段代码是不会执行的，因为_noRouteShouldBeApplied()方法在该类中被硬编码返回false。这段代码会在admin路由中讲解。

接下来，分发之前，给请求对象设置模块名（使用前端命名值)，控制其名，方法名，以及最后真正匹配的$realModule。然后，从$p中获取其它传递的参数。最后的最后，进行路由分发操作。终于完成啦！！！

Magento路由分发过程解析（二）：Standard路由对象(转)

标签：

原文地址：http://www.cnblogs.com/zhorigtu/p/4231409.html