magento模块.doc

Magento模块 2009-07-13 16:09 模块（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方法，而这个方法则触发下面这几个事件，你可以侦听这几个事件 并添加处理代