代码改变世界

[转]Magento 结构解析

2013-09-19 01:24  BrokenJar  阅读(231)  评论(0)  编辑  收藏  举报

 

MODULES 模块

　　模块(module) 是Magento的核心. 站点上的任何一个动作(action),无论是在前台还是后台的每一个操作都是通过模块来实现的.模块可以视为一个容器, 它包含下面这几项:

  • 设置(settings)
  • 数据库模式(database schema)
  • 呈现模式(rendering object)
  • 辅助工具类(utility helpers)
  • 数据模型(data models)
  • 动作控制器(action controller)

　　一个模块可以包含全部的这六项也可以只包含其中的几项,甚至只有一项.所有的模块都可以通过app/etc/modules 目录中xml配置系统来进行开关.每个模块也可以在自己模块下的etc子目录中创建一个xml文件来保存自己的配置信息.

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

 

 

CODE POOL 代码池

　　Magento中所有的模块被放在三个代码池中,他们分别是:

  • core
  • local
  • community

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

 

 

PACKAGE 包

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

 

 

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 类的修改版本. 其中比较重要的方法包括:

  • dispatch($action)
  • preDispatch()
  • postDispatch()

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

  • controller_action_predispatch
  • controller_action_predispatch_ModuleName
  • controller_action_predispatch_ModuleName_ControllerName_ActionName

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

 

 

HELPER 辅助类

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

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

  • __(两个下划线)
  • 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 .

 

 

TEMPLATE SYSTEM 模板系统

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

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

 

 

LAYOUT FILE 布局文件

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

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

  • layout
  • default
  • reference
  • block
  • action
  • update

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

 

 

TEMPALTE FILE 模板文件

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

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

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

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