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