magento模块创建前必须知道的知识.docVIP

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 preDi