暂定本章为这个系列最后一章，还是继续沿用模块的别名（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的底层源代码，总是有收获的。