magento机制

magento的请求周期(request cycle)

 

magento对某个URL的请求是如何被翻译成到某个特定模块的执行呢？我们来看一下下面的这个URL：

http://example.com/magento/(index.php)/customer/account/index/

以反斜杠为分隔符，URL分成以下这几部分：

http://example.com   域名

magento                   URL前缀

(index.php)               不一定会有这个部分。当你使用apache的rewrite功能时可以省略掉index.php

customer                   模块名

account                     前台控制器名

index                         action名，通常默认为index

要追踪一个对magento请求的执行过程并非易事，原因在于以下两点：
1、使用了router
2、使用了dispatch机制

首先是由默认的前端控制器接受请求，它会将请求的参数和内部的router列表进行匹配，如果匹配成功，那么就会将请求交给另一个新的前端控制器（由请求参数和router匹配所得到的模块中的创建）。通常最后的（MVC类型）控制器是一个"Front Action"对象，它里面定义了一系列的有关业务逻辑的method(方法)。这个对象最后会根据请求的参数来决定调用哪 一个action method来处理请求，在处理完后将请求标识为"dispatched"。

 

 

认识magento的module(模块)

module是magento最重要的部分。在magento站点中的任何一个操作，无论是在前台还是后台都是通过模块来实现的。在magento中一个模块是由下列这几项的的一项或多项组成：配置文件，数据库相关的sql文件，呈现对象(rendering objects)，辅助类(helper class)，数据模型类和动作控制器类(action controller)。

magento中的模块是放在什么位置，我们开发的模块又应该放在什么地方？magento引入了代码池(code pool)和包(package)两个概念。细心的你可以已经发现app/code下有三个目录，这是magento提供的代码池。其中所有magento自带的模块被放到core当中，而local则用来保存我们自己开发的模块，community则用来存放我们集成到magento中的第三方插件代码，不过这个文件夹有可能在后来的版本中淘汰掉。你可能已经发现magento的模块不是直接放在代码池core目录下，而是放在core代码池目录下的Mage目录中。magento将代码池下的目录称作包，目的不仅仅是将相关的模块用包分组，更重要的是通过将某个包下面的所有模块的类的类名都使用包名为前缀（如Mage包下的所有模块的类名前缀是Mage_）规范来达到类似名字空间的作用，使开发人员免去类名重复的困扰。

参看下面的目录结构和相关的代码中定义的类名：
- App/   
|- code/     
| |- community/
| |- core/
| | |- Mage/
| | |- Zend/
| |- local/
|- design/
|- etc/

下面是magento中的catalog模块的目录结构：
- Mage/            包名
|- Catalog/       模块名
| |- Block/         呈现对象(rendering objects)
| |- Helper/       辅助类(helper class)
| |- Model/        数据模型类。负责数据操作
| |- controllers/ 动作控制器类(action controller)
| |- etc/             配置文件
| |- sql/              数据库相关的sql文件

 

blocks： blocks是一组用来协调模板文件和模型的对象，每个block对应一个模板文件（模板文件是指以.phtml为扩展名的文件，其实就是一个普通的在html中嵌入php代码的文件）。每一次的magento请求实际上是处理一系列的block对象和相应的模板文件。所有的block类继承Mage_Core_Block_Template类(它继承Mage_Core_Block_Abstract类)，它的主要方法是toHtml()，它通过调用renderView()来将模板文件翻译成html代码。magento默认不使用任何的模板引擎，而是直接使用php。所有renderView()事实上只是简单的调用include包含模板文件而以，如果你想使用其它的模板引擎，你可以通过修改Mage_Core_Block_Template类的renderView()方法来实现。

 

controllers: controller是所有业务逻辑的起点。每个controller类都继承Mage_Core_Controller_Varien_Action类，它实际只是zend的Zend_Controller_Action类的简单修改版本，包括下面三个主要的方法：

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

helper: 重要的是__(两个下划线)和htmlEscape方法。__用来翻译字符串，几乎可以在任何一个对象内调用。

配置文件： 模块的配置文件存放在该模块目录下的etc目录下。通常会有三个配置文件，其中config.xml是会直接影响到模块的动作。还有两个system.xml和convert.xml会自动生成供你在使用管理后台的form表单。

在magento中的一切都可视为模块。甚至magento本身也是在zend框架下开发出的一个模块。模块本身可以有配置文件和数据库设置，这样开发人员就可以对magento进一步扩展。