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方法，而这个方法则触发下面这几个事件，你可以侦听这几个事件 并添加处理代码：n controller_action_predispatchn controller_action_predispatch_ModuleNamen controller_action_predispatch_ModuleName_ControllerName_ActionNamedispatch方法只会在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 layoutl defaultl referencel blockl actionl update 你也可能看到类似下面这样的标签，这些在Magento中被layout handle，它们的作用和default标签一样，但是只会在某些特定的请求时起作用。这些标签遵循一个模式，即和模块名，控制器名，和action名 相关联。如果一个标签只有两个部分，以下划线分开，比如cms_page，那么这个标签下的所有设置会应用到这个模块下的对应控制器下的所有请求。模板文件关于模板文件没有太多介绍的，它们只是简单的在html文件中嵌套php代码的文件，以.phtml为扩展名。这些文件中使用了php语法的模板特性，你会看到PHP的另一个使用冒号的循环结构，还有endwhile,endfor,endif。模板文件的目录结构模仿对应模块的目录结构，但是这并不是必须的。笔者发现，在开发自己的模块时，不按Magento的习惯来命名模板文件并将它们 保存在一个目录下会简单的多。你可以将文件名中的斜杠替换成下划线，这样就相当于模仿了你模块的文件名。如果你需要重写一组文件，不管是哪里的文件，不管 是几个文件，要想直接看到到底重写了哪些文件，最好就是将它们重写并保存在一个目录下。有一些重要的模板文件你需要熟悉，就是在page目录下的模板文件。这个目录下的所有模板文件在修改你的页面时具有最高的级别。这些文件指定了哪些页面有，或列，也提供类似dashboard类似的页面和打印布局的页面。尽管你可以在你自己的主题的page目录中添加最高级别的模板文件，但是只有default界面中default主题中page目录下的模板文件可 以通过后台管理界面来选择。比如说你想要一个有四个列的页面结构，所以你就创建了4-column.phtml，但是你是不能通过后台管理界面来选择这个 模板文件。但是你可以在布局文件中重新（重写）定义页面结构为4-column.phtml。所以这只不过是用户界面上的限制。我写的第一个Magento扩展星期二, 07/28/2009 - 12:55 foolsky Magento扩展开发的概念相对统一，名称叫Module. 从访问入口看，Magento扩展一般有两种展现形式： 1. 作为一个完整的页面，从浏览器地址栏访问新增的模块。 2. 作为页面的一个片段，插接到现已存在的网页上。 下面的例子描述的第一种方式扩展出来的模块。 案例假设公司名称为Cartz, 现在要为该公司编写一个旅馆预订的模块。 步骤 I: 建立模块目录及文件结构骨架。 目录结构 【Magento】 app - etc/ - modules/ Cartz_Hotel.xml - code/ - local/ - Cartz/ - Hotel/ - controllers MyController.php - etc config.xml步骤 II: Cartz_Hotel.xml true local 0.1.0 该文件的目的是让Magento系统载入该模块。标签为true表示使该模块生效。注意标签是命名约定，从而约束了你的代码应该放在app/code/Cartz/Hotel目录下。步骤 III: MyController.php ?php class Cartz_Hotel_MyController extends Mage_Core_Controller_Front_Action public function helloAction() echo My First Module; 类名构成： 前缀(Cartz_Hotel)加上文件的名字(IndexController)，然后要求扩展基类 Mage_Core_Controller_Front_Action。稍后我们要看看如何调用indexAction方法来输出“My First Module”.步骤 IV: config.xml 0.1.0 standard Cartz_Hotel hotel frontend/routers/用来设置使该模块从前端显示的入口。frontName稍后将出现在 url中假设Magento在本机安装的访问首页是http:/localhost/magento/index.php, 那么在浏览器地址栏中输入http:/localhost/magento/index.php/hotel/my/hello 将在页面输入My First Module从而得出Magento模块url访问的命名规范http:/ / 在扩展的模块中使用模型(Model) 星期二, 07/28/2009 - 12:57 foolsky 我们不得不承认，Magento的架构相当复杂，但是足够灵活，为了理解本文，你必须阅读本博客上的系列文章I. 所以这里假设你已经建立好了Cartz_Hotel的模块目录结构 I. 在et