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 目录下的模板文件。这个目录下的所有模板文件在修改你的页面时具有最高的级别。这些文件指定了哪些页面有１，２或３列，也提供类似 dashboard 类似的页面和打印布局的页面。

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

原文：http://yonglailizhi.iteye.com/blog/792775

magento结构解析