“约定优于配置”与Magento改造尝试四之block、helper和model加载
来源:互联网 发布:方象餐饮软件 编辑:程序博客网 时间:2024/04/27 17:20
暂定本章为这个系列最后一章,还是继续沿用模块的别名(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的底层源码,总是有收获的。
- “约定优于配置”与Magento改造尝试四之block、helper和model加载
- “约定优于配置”与Magento改造尝试一之语言包加载
- “约定优于配置”与Magento改造尝试二之布局xml文件加载
- “约定优于配置”与Magento改造尝试三之routerName加载
- “约定优于配置”与Magento
- “约定优于配置”与Magento总结
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- SpringMVC介绍之约定优于配置
- Maven之(八)约定优于配置
- SpringMVC介绍之约定优于配置
- JAVA编码规范之约定优于配置
- Maven之(八)约定优于配置
- CABasicAnimation 简单的用法
- ZOJ 3881 From the ABC conjecture
- mybatis如何配置使用多个数据源(environment)
- iOS判断是否静音状态
- JUI编辑器的使用
- “约定优于配置”与Magento改造尝试四之block、helper和model加载
- 正则表达式收集
- JavaScript调试问题
- Hadoop2.4.1(QJM HA)+HBASE0.98 双MASTER问题分析
- linux环境下搭建radius服务器和客户端
- CSS学习笔记6-文本属性
- [转]超强、超详细Redis数据库入门教程
- 使用VLC和live555MediaServer搭建RTSP服务器
- android初学之android.content.res.Resources$NotFoundException: String resource ID #0x3e8异常