“约定优于配置”与Magento改造尝试四之block、helper和model加载

暂定本章为这个系列最后一章，还是继续沿用模块的别名（alias）概念

    <modules>
        <Mage_Wishlist>
            <version>1.6.0.0</version>
            <alias>wishlist</alias>
        </Mage_Wishlist>
    </modules>

看下Magento一般是怎么定义block、helper和model的别名的

<blocks>
            <wishlist>
                <class>Mage_Wishlist_Block</class>
            </wishlist>
        </blocks>
        <models>
            <wishlist>
                <class>Mage_Wishlist_Model</class>
                ......
            </wishlist>
            ......
        </models>

类似于一样前两章所说，blocks和models的别名都是一样的，当然本章改造目的就是通用别名取代上面这种分别单独配置了。不过这里要先等下，因为我在Mage_Wishlist的config.xml里没有发现对helpers的定义，而Mage_Wishlist的helper类明明都可以正常使用的，为什么呢？

这个系列一开始（“约定优于配置”与Magento）我吐槽了下说Magento是多么的违反“约定优于配置”的范式，这里小小的平反下，Magento还是有地方符合这个范式的。上面讲到为什么没有对helpers进行定义，模块的helper类依然可以正常使用，原因看Mage_Core_Model_Config类的public function getGroupedClassName方法

// Second - if entity is not rewritten then use class prefix to form class name
        if (empty($className)) {
            if (!empty($config)) {
                $className = $config->getClassName();
            }
            if (empty($className)) {
                $modules = $this->getAliasConfig();
                if($modules[$group]){                    
                    $className = $modules[$group].'_'.$groupType;
                }
            }
            if (empty($className)) {
                $className = 'mage_'.$group.'_'.$groupType;                
            }
            if (!empty($class)) {
                $className .= '_'.$class;
            }
            $className = uc_words($className);
        }

有一段$className = 'mage_'.$group.'_'.$groupType;，意思是当没有在config.xml里指定别名时，自动根据$group名去Mage目录下寻找对应的helper类，以Mage::helper('wishlist')->calculate();这种写法为例，这里$group是helper后面括号里的wishlist，这里的$groupType是helper，那么拼接之后的$className就是“mage_wishlist_helper”,就是通过这种方式，系统提供了一种在未明确定义情况下helper类的一个默认加载路径。

这套逻辑不仅仅对helper类适用，对block和model类一样适用，因为getGroupedClassName是一个block、helper和model共用的方法，详见Mage_Core_Model_Config类里的

public function getBlockClassName($blockType){
    ......
}
public function getHelperClassName($helperName){
    ......
}
public function getModelClassName($modelClass){
    ......
}

所以理论上来说，未对这块代码做修改的情况下，就已经可以把原生模块（core/Mage目录下的）的config.xml做一些精简了，比如删掉Mage_Wishlist模块的下面这段配置，并不会对这个模块的正常使用带来任何影响

<blocks>
            <wishlist>
                <class>Mage_Wishlist_Block</class>
            </wishlist>
        </blocks>

当然Magento官方保留这些配置也不是没有道理，上面提到了说这个默认加载方式只对core/Mage目录下的的模块有效，community和local目录下的模块都是不符合标准的，必须显式指定配置，如果自带核心模块都把这些配置省了，那用户做二次开发就没参照物了

Magento是一个扩展性相当好的系统，引入各种第三方插件或者自己二次开发功能模块都是很常见的场景，前面提到原生的“约定”只对core/Mage有效，那么本章要做的修改就是让所有community和local目录下的模块在加载block、helper和model时也可以按照某种约定（就是我所定义的模块的别名）来进行，免去显示配置的xml内容。

修改的方法就是之前提到的public function getGroupedClassName，我加入了下面这样一段代码

            if (empty($className)) {
                $modules = $this->getAliasConfig();
                if($modules[$group]){                    
                    $className = $modules[$group].'_'.$groupType;
                }
            }

详见：https://github.com/walexer/Yli_Coc/blob/master/app/code/local/Mage/Core/Model/Config.php

原理就是用模块的别名（alias）代替显式各自指定的别名，因为核心模块有自己的一套“约定”，我用一个第三方插件模块AW_Blog来说明

定义别名：

    <modules>
        <AW_Blog>
            <version>1.3.16</version><platform>ce</platform>
            <alias>blog</alias>
        </AW_Blog>
    </modules>

可以删除的配置内容

        <helpers>
            <blog>
                <class>AW_Blog_Helper</class>
            </blog>
        </helpers>

<blocks>里面的

            <blog>
                <class>AW_Blog_Block</class>
            </blog>

<models>里面的

<class>AW_Blog_Model</class>

本系列的改造到这里暂时告一段落，相信按照“约定优于配置”的原则，Magento肯定还有地方可以拎出来改一改（毕竟Magento那么的自由），以后有时间的话可以考虑是不是开续集。

下一章会做一下改造前后的性能对比测试，有明显提升的话当然最好，没有明显提升的话就当玩票了，最起码读了不少Magento的底层源码，总是有收获的。