最新消息:Excel无乱码转CSV,由于工作原因很少更新博客和回复大家的评论,非常抱歉。

学习Magento模块开发必看

Magento模块

模块(module)是Magento的核心。站点上的任何 一个动作(action),无论是在前台和还是在后台的每一个操作都是通过模块来实现的。模块是可以视为一个容器,它可包 含下面这几项:设置(settings),数据库模式(database schema), 呈现对象(rendering object),辅助工具类(utility helpers), 数据模型(data models)或动作控制器(action controller)。一个模块可以包含全部的这六项也可以只包含其中的几项,甚至只有一项。所有的模块可以通过app/etc/modules/目录中XML配置系统来进行开关。每个模块 也可以在自己模块目录下的etc子目录中创建一个XML文件来保存自己的配置信息。

由于Magento中的一切都是模块而且模块本身又可以有自己的配置文件和数据库设置,这样就允许开发人员对Magento进行扩展。

模块结构

下面是Catalog模块的目录结构,它包含了模块的所有项目(上面提到的六项):
代码池(Code Pools)

Magento中所有的模块被放在三个代码池中,它们分别是core,local,community。Magento本身所附带的模块全部 放在core代码池中。你自己开发的模块则就安装在local代码池中。至于community代码池则是用来安 装第三方模块,但是这种想法也有可能会过时,因为模块可以安装在lcoal代码池,也可以安装在community代码池,而并不是必须那样划分。
包(Package)

所有的模块都不是直接保存代码 池目录中,而是保存在包目录(代码池的子目录)中。引入包概念的主要目的是类命名的统一和一贯性。所有的Magento模块是保存在core代码池中的Mage包中。所以,所有的Magento类名都以Mage_为前缀。而对我们自己开发的代码我们应该在lcoal代码池中创建一个包,比如以你公司的名字作为包名,这样就可以避免类名的重复的可能性。
模型(Model)

模型可以说是Magento的肌肉。它主要是用来从数据库提取数据到程序中。数据的输出,呈现是通过块(Block)来实现的。也就是说它主要是用来负责数据库操作的。事实上在任何一个编程环境中,模型都是被用来识别 处理数据域的工作,也就是说它在数据组的定义和其它相关数据组之间起到联系的作用。

为了说明前面模型化的理论,我 们举个例子来说明一下:在创建一个购物车系统时,我们有一个Product类。每个产品需要一个 指定一个图片。问题是图片如何模型化?只是简单的给Product类一个$image_url属性?还是创建 一个Image_Gallery类,然后在两个类之间创建一个接口,如getDefaultImage。最终的模型类取决于你决定如何实现数据之间的操作。
块(Block)

块是Magento模板模式背后的大脑。所有的块形成一套嵌套的对象集协调模型和模板文件。每个块对应一个模板文件 —— 模板文件是以.phtml为扩展名的html 和php代码混合的文件。也就是说对于在Magento上的任何一个请求,其实你在处理的是一系列的块对象和相应数量的模板文件。

Magento的模板系统就是php语言本身。它并没有重新实现一 个模板系统,所以renderView()方法也只不过是简单的调用include来包含相关的模板文件。也就是说,如果你想使用某个模板引擎,而不使用单纯的php语言,你可以通过修改Mage_Core_Block_Template类的renderView方法来调用你所 选择的模板系统的呈现函数。

控制器(Controller)

控制器是Magento所有业务逻辑的起点。 业务逻辑是指业务理论中的规则。至于

Magento业务逻辑和域逻辑(数据处理指令)的区分是不太明显的。有的人认为检查必须栏位和可选栏位就是属于 业务逻辑,而有人认为那应该属于域逻辑。Magento中的大多数的逻辑的是在模型中实现的。

控制器类继承了Mage_Core_Controller_Varien_Action基类,而这个基类是Zend框架的Zend_Controller_Action类的修改版本。其中比较重要的方法包括:

l dispatch($action)

l preDispatch();

l postDispatch()

其它的方法只是简单的利用URL将指令传递给系统的其它关键部分。Dispatch()方法启动当前请求的所有业务逻辑,$action的值是根据URL决定的,默认通常是index。Dispatch方法首先调用preDispatch方法,而这个方法则触发下面这几个事件,你可以侦听这几个事件并添加处理代码:

n controller_action_predispatch

n controller_action_predispatch_ModuleName

n controller_action_predispatch_ModuleName_ControllerName_ActionName

dispatch方法只会在preDispatch方法末将当前 请求标记为dispatched时被调用,最终它会调用相应的控制器实例中对应的action方法,看下图:
辅助类(Helper)

Magento中的辅助类是用来将那些辅助接口从内核类中提取抽象出来的途径。我们通常既有在块类中,也有在模型 类中调用辅助类的接口,所以这些接口的返回值是不太可靠的,而且你几乎不会去继承某个辅助类,因为你可以直接添加一个辅助类来添加新的辅助接口。

不过你会感兴趣的辅助类的两个 重要的接口是:

l __(两个下划线)

l htmlEscape

双下划线方法是翻译接口。它几 乎被所有的对象封装使用,也就是说你几乎可以在代码中的任何地方调用这个方法来翻译一个字符串。htmlEscape只是简单封装了htmlspecialchars函 数,不过它也可以接收一个数组并对数组中的每个元素应用htmlspecialchars函 数。
配置文件(config files)

模块的配置文件是保存在模块目 录下的etc子目录中。每个模块可以有三个配置文件,它们全是XML文件。其中config.xml是直接影响你模块的行为,其它的两个文件system.xml和convert.xml会自动为你在 后台配置页面创建设置表单。

所有模块的配置文件最后会被组 合到一起。这就意味着你可以在某个模块相应的XML标签中设置配置来重写或覆盖任何模块的相应配置,这也正是Magento重写的本质。

为了某种需要,你可以创建一个 类,再创建一个config.xml文件,在其中相同的位置指定你的类名,这样你就可以你将你的类安装到系统中。

这也是你为什么会看见在系统中 到处都有类似getModel(‘catalog/product’)的调用,而不是简单的像这样的调用:new Catalog_Model_Product();。

每个类对标签,名称的使用给了 你一个强大的方式使你可以重写系统中的任何一个部分。

注:类名中使用标签假定的上下 文件可能是Block,Model,Helper。
模板系统

Magento中的模板系统是很有争议的。有些用户对于使用PHP作为模板系统很有意见。但是使用PHP作为模板系统并没有使用模板系统简单或功能变得不够强大,至少从长远看来不是。在笔者看来这是最灵 活最高级的模板系统。

一个完整的页面是通过一组嵌套 的模板文件来实现(理论上讲应该是一组嵌套的块对象)。系统中不会有“组件”的概念,也就是说你不会有“Form”,“Button”类或对象。模板文件和 块对象是通过一组xml文件控制的,这有利于开发人员开发插件,但是似乎这对设计人员(即使是那些熟悉php的程序员)来讲有点难度。
布局文件(Layout file)

布局文件控制了页面的最终结 构。所有的布局文件保存在当前主题的layout目录下。所有布局文件的名称都和相应的模块名一样,只不过它们都使用小写,而模块名使用所谓的骆驼 式命名法。其中最重要的布局文件是page.xml文件

page.xml文件指定了默认的页面结构。从其它的xml文件的修改是来自default标签下的设置。下列是布局文件中常用的标签:

l layout

l default

l reference

l block

l action

l update
你也可能看到类似下面这样的标 签,这些在Magento中被layout handle,它们的 作用和default标签一样,但是只会在某些特定的请求时起作用。这些标签遵循一个模式,即和模块名,控制器名,和action名相关联。如果一个标签只有两个部分,以下划线分开,比如cms_page,那么这个标签下的所有设置会应用到这个模块下的对应控制器下的所有请求。
模板文件

关于模板文件没有太多介绍的, 它们只是简单的在html文件中嵌套php代码的文件,以.phtml为扩展名。这些文件中使用了php语法的模板特性,你会看到PHP的另一个使用冒号的循环结构,还有endwhile,endfor,endif。

模板文件的目录结构模仿对应模 块的目录结构,但是这并不是必须的。笔者发现,在开发自己的模块时,不按Magento的 习惯来命名模板文 件并将它们保存在一个目录下会简单的多。你可以将文件名中的斜杠替换成下划线,这样就相当于模仿了你模块的文件名。如果你需要重写一组文件,不管是哪里的 文件,不管是几个文件,要想直接看到到底重写了哪些文件,最好就是将它们重写并保存在一个目录下。

有一些重要的模板文件你需要熟 悉,就是在page目录下的模板文件。这个目录下的所有模板文件在修改你的页面时具有最高的级别。这些文件指定了哪些 页面有1,2或3列,也提供类似dashboard类似的页面和打印布局的页面。

尽管你可以在你自己的主题的page目录中添加最高级别的模板文件,但是只有default界面中default主题中page目录下的模板文件可以通过后台管理界面来选择。比如说你想要一个有四个列的页面结构,所以你就创建了4-column.phtml,但是你是不能通过后台管理界面来选择这个模板文件。但是你可以在布局文件中重新(重写)定义页面结 构为4-column.phtml。所以这只不过是用户界面上的限制。

来源:http://blog.aim-china.com/?p=110

Magento模块

模块(module)是Magento的核心。站点上的任何 一个动作(action),无论是在前台和还是在后台的每一个操作都是通过模块来实现的。模块是可以视为一个容器,它可包 含下面这几项:设置(settings),数据库模式(database schema), 呈现对象(rendering object),辅助工具类(utility helpers), 数据模型(data models)或动作控制器(action controller)。一个模块可以包含全部的这六项也可以只包含其中的几项,甚至只有一项。所有的模块可以通过app/etc/modules/目录中XML配置系统来进行开关。每个模块 也可以在自己模块目录下的etc子目录中创建一个XML文件来保存自己的配置信息。

由于Magento中的一切都是模块而且模块本身又可以有自己的配置文件和数据库设置,这样就允许开发人员对Magento进行扩展。

模块结构

下面是Catalog模块的目录结构,它包含了模块的所有项目(上面提到的六项):


代码池(Code Pools)

Magento中所有的模块被放在三个代码池中,它们分别是corelocalcommunityMagento本身所附带的模块全部 放在core代码池中。你自己开发的模块则就安装在local代码池中。至于community代码池则是用来安 装第三方模块,但是这种想法也有可能会过时,因为模块可以安装在lcoal代码池,也可以安装在community代码池,而并不是必须那样划分。


(Package)

所有的模块都不是直接保存代码 池目录中,而是保存在包目录(代码池的子目录)中。引入包概念的主要目的是类命名的统一和一贯性。所有的Magento模块是保存在core代码池中的Mage包中。所以,所有的Magento类名都以Mage_为前缀。而对我们自己开发的代码我们应该在lcoal代码池中创建一个包,比如以你公司的名字作为包名,这样就可以避免类名的重复的可能性。


模型(Model)

模型可以说是Magento的肌肉。它主要是用来从数据库提取数据到程序中。数据的输出,呈现是通过块(Block)来实现的。也就是说它主要是用来负责数据库操作的。事实上在任何一个编程环境中,模型都是被用来识别 处理数据域的工作,也就是说它在数据组的定义和其它相关数据组之间起到联系的作用。

为了说明前面模型化的理论,我 们举个例子来说明一下:在创建一个购物车系统时,我们有一个Product类。每个产品需要一个 指定一个图片。问题是图片如何模型化?只是简单的给Product类一个$image_url属性?还是创建 一个Image_Gallery类,然后在两个类之间创建一个接口,如getDefaultImage。最终的模型类取决于你决定如何实现数据之间的操作。


(Block)

块是Magento模板模式背后的大脑。所有的块形成一套嵌套的对象集协调模型和模板文件。每个块对应一个模板文件—— 模板文件是以.phtml为扩展名的html php代码混合的文件。也就是说对于在Magento上的任何一个请求,其实你在处理的是一系列的块对象和相应数量的模板文件。

Magento的模板系统就是php语言本身。它并没有重新实现一 个模板系统,所以renderView()方法也只不过是简单的调用include来包含相关的模板文件。也就是说,如果你想使用某个模板引擎,而不使用单纯的php语言,你可以通过修改Mage_Core_Block_Template类的renderView方法来调用你所 选择的模板系统的呈现函数。

控制器(Controller)

控制器是Magento所有业务逻辑的起点。 业务逻辑是指业务理论中的规则。至于

Magento业务逻辑和域逻辑(数据处理指令)的区分是不太明显的。有的人认为检查必须栏位和可选栏位就是属于 业务逻辑,而有人认为那应该属于域逻辑。Magento中的大多数的逻辑的是在模型中实现的。

控制器类继承了Mage_Core_Controller_Varien_Action基类,而这个基类是Zend框架的Zend_Controller_Action类的修改版本。其中比较重要的方法包括:

ldispatch($action)

lpreDispatch();

lpostDispatch()

其它的方法只是简单的利用URL将指令传递给系统的其它关键部分。Dispatch()方法启动当前请求的所有业务逻辑,$action的值是根据URL决定的,默认通常是indexDispatch方法首先调用preDispatch方法,而这个方法则触发下面这几个事件,你可以侦听这几个事件并添加处理代码:

ncontroller_action_predispatch

ncontroller_action_predispatch_ModuleName

ncontroller_action_predispatch_ModuleName_ControllerName_ActionName

dispatch方法只会在preDispatch方法末将当前 请求标记为dispatched时被调用,最终它会调用相应的控制器实例中对应的action方法,看下图:


辅助类(Helper)

Magento中的辅助类是用来将那些辅助接口从内核类中提取抽象出来的途径。我们通常既有在块类中,也有在模型 类中调用辅助类的接口,所以这些接口的返回值是不太可靠的,而且你几乎不会去继承某个辅助类,因为你可以直接添加一个辅助类来添加新的辅助接口。

不过你会感兴趣的辅助类的两个 重要的接口是:

l__(两个下划线)

lhtmlEscape

双下划线方法是翻译接口。它几 乎被所有的对象封装使用,也就是说你几乎可以在代码中的任何地方调用这个方法来翻译一个字符串。htmlEscape只是简单封装了htmlspecialchars函 数,不过它也可以接收一个数组并对数组中的每个元素应用htmlspecialchars函 数。


配置文件(config files)

模块的配置文件是保存在模块目 录下的etc子目录中。每个模块可以有三个配置文件,它们全是XML文件。其中config.xml是直接影响你模块的行为,其它的两个文件system.xmlconvert.xml会自动为你在 后台配置页面创建设置表单。

所有模块的配置文件最后会被组 合到一起。这就意味着你可以在某个模块相应的XML标签中设置配置来重写或覆盖任何模块的相应配置,这也正是Magento重写的本质。

为了某种需要,你可以创建一个 类,再创建一个config.xml文件,在其中相同的位置指定你的类名,这样你就可以你将你的类安装到系统中。

这也是你为什么会看见在系统中 到处都有类似getModel(‘catalog/product’)的调用,而不是简单的像这样的调用:new Catalog_Model_Product();

每个类对标签,名称的使用给了 你一个强大的方式使你可以重写系统中的任何一个部分。

注:类名中使用标签假定的上下 文件可能是BlockModelHelper


模板系统

Magento中的模板系统是很有争议的。有些用户对于使用PHP作为模板系统很有意见。但是使用PHP作为模板系统并没有使用模板系统简单或功能变得不够强大,至少从长远看来不是。在笔者看来这是最灵 活最高级的模板系统。

一个完整的页面是通过一组嵌套 的模板文件来实现(理论上讲应该是一组嵌套的块对象)。系统中不会有“组件”的概念,也就是说你不会有“Form”,“Button”类或对象。模板文件和 块对象是通过一组xml文件控制的,这有利于开发人员开发插件,但是似乎这对设计人员(即使是那些熟悉php的程序员)来讲有点难度。


布局文件(Layout file)

布局文件控制了页面的最终结 构。所有的布局文件保存在当前主题的layout目录下。所有布局文件的名称都和相应的模块名一样,只不过它们都使用小写,而模块名使用所谓的骆驼 式命名法。其中最重要的布局文件是page.xml文件

page.xml文件指定了默认的页面结构。从其它的xml文件的修改是来自default标签下的设置。下列是布局文件中常用的标签:

llayout

ldefault

lreference

lblock

laction

lupdate


你也可能看到类似下面这样的标 签,这些在Magento中被layout handle,它们的 作用和default标签一样,但是只会在某些特定的请求时起作用。这些标签遵循一个模式,即和模块名,控制器名,和action名相关联。如果一个标签只有两个部分,以下划线分开,比如cms_page,那么这个标签下的所有设置会应用到这个模块下的对应控制器下的所有请求。


模板文件

关于模板文件没有太多介绍的, 它们只是简单的在html文件中嵌套php代码的文件,以.phtml为扩展名。这些文件中使用了php语法的模板特性,你会看到PHP的另一个使用冒号的循环结构,还有endwhile,endfor,endif

模板文件的目录结构模仿对应模 块的目录结构,但是这并不是必须的。笔者发现,在开发自己的模块时,不按Magento的 习惯来命名模板文 件并将它们保存在一个目录下会简单的多。你可以将文件名中的斜杠替换成下划线,这样就相当于模仿了你模块的文件名。如果你需要重写一组文件,不管是哪里的 文件,不管是几个文件,要想直接看到到底重写了哪些文件,最好就是将它们重写并保存在一个目录下。

有一些重要的模板文件你需要熟 悉,就是在page目录下的模板文件。这个目录下的所有模板文件在修改你的页面时具有最高的级别。这些文件指定了哪些 页面有1,2或3列,也提供类似dashboard类似的页面和打印布局的页面。

尽管你可以在你自己的主题的page目录中添加最高级别的模板文件,但是只有default界面中default主题中page目录下的模板文件可以通过后台管理界面来选择。比如说你想要一个有四个列的页面结构,所以你就创建了4-column.phtml,但是你是不能通过后台管理界面来选择这个模板文件。但是你可以在布局文件中重新(重写)定义页面结 构为4-column.phtml。所以这只不过是用户界面上的限制。

转载请注明:嗨酷哥,有你更酷! » 学习Magento模块开发必看

与本文相关文章

发表我的评论

取消评论
表情 插代码

Hi,您需要填写昵称和邮箱!

  • 必填项
  • 必填项