Magento中文开发教程.docx
《Magento中文开发教程.docx》由会员分享，可在线阅读，更多相关《Magento中文开发教程.docx（128页珍藏版）》请在冰点文库上搜索。
Magento中文开发教程
Magento－中文开发教程
前言
本文主要收集自：
精東·博客）
因工作需要2010年春正式走上了Magento的开发之路，早在2007年开发国内某服饰类B2C的时候就有看过Magento，当时感觉就不错。
可惜业务模式上的差异比较大，所以没有直接采用，但很多地方有借鉴Magento。
它真的很奇妙、很好用，是我至今见过的最好开源eCommerce软件。
本套教程基于Magento1.4.0.1版本编写，前七章的原作者是AlanStorm，参考了HailongZhang的翻译，添加了自己的理解，修改而来。
后面的内容大多是本人亲身经验的总结。
难免笔误，欢迎大家指出错误。
深入理解Magento－第一章–Magento强大的配置系统
深入理解Magento－第二章–Magento请求分发与控制器
深入理解Magento－第三章–布局，块和模板
深入理解Magento－第四章–模型和ORM基础
深入理解Magento－第五章–Magento资源配置
深入理解Magento－第六章–高级Magento模型
深入理解Magento－第七章–自定义Magento系统配置
深入理解Magento－第八章–深入自定义Magento系统配置（未完成）
深入理解Magento－第九章–修改、扩展、重写Magento代码
深入理解Magento－第十章–数据操作&数据收集器
在Magento教程中用到的模块
Configviewer
Layoutviewer
HelloworldwithCustomSystemConfig
其他与Magento开发相关的文章
简单的EAV数据查询
清除缓存的几种方法
通过命令行来升级Magento
MAGENTO数据转移
如何使用和设置Cookie&Session
Magento中我的账户访问权限判断
Magento时间/时区问题
重新安装Magento模块
Magnto获取当前店铺和店铺配置的方法
Magento如何重写或新建后台的页面
深入理解Magento–第一章–Magento强大的配置系统
Magento的配置系统就像是Magento的心脏，支撑着Magento的运行。
这套配置系统掌管着几乎所有“module/model/class/template/etc”。
它把整个Magento系统抽象出来，用一个配置文件来描述。
这里的“配置文件”并不是一个物理上存在的文件，而是Magento根据当前的系统状态动态生成的一段XML。
大多数的PHP开发者并不习惯于这样抽象层，因为它增加的编程的复杂性。
但是这样的抽象提供了无与伦比的灵活性，允许你覆盖几乎任何系统的默认行为。
首先，让我们写一个简单的插件来看看这个所谓的“配置文件”长什么样。
虽然我已经提供的现成的代码，但是还是建议你自己建立这个插件，把整个流程走一遍有助于你的理解。
设置插件的目录结构
我们将要创建一个Magento的模块【注：
Magento的插件不叫plug-in，叫module，翻译成模块】。
Magento的模块由php和xml文件组成，目的是扩展或者覆盖系统的行为，比如为订单增加数据模型，更改一个类的方法，或者增加一个全新的功能。
【注：
Magento自带的那些功能也都是基于模块的，比如用户注册，商品展示，结账流程等等。
Magento给我的感觉就是一切皆模块，和Eclipse的插件体系结构有点像】
大多数Magento的系统模块的结构和我们将要构建的插件的结构是一样的。
Magento的系统模块在以下目录
app/code/core/Mage
每一个子目录都是一个单独的模块。
这些模块是由Magento官方开发的。
我们安装完Magento以后，所使用的功能就是来自这些模块。
我们自己创建的模块应该放在如下目录
app/code/local/Packagename
“Packagename”应该是一个唯一的字符串，用来标识你的代码。
通常人们使用公司名字作为Packagename，比如
app/code/local/Microsoft
由于我在做我自己的Magento项目，我将使用我自己的项目名“App”。
然后，我们要创建以下目录结构
app/code/local/App/Configviewer/Block
app/code/local/App/Configviewer/controllers
app/code/local/App/Configviewer/etc
app/code/local/App/Configviewer/Helper
app/code/local/App/Configviewer/Model
app/code/local/App/Configviewer/sql
你的插件并不一定需要包含以上所有的目录，但是为了以后开发方便，我们还是在一开始就把目录创建好。
接下来我们要创建两个文件，一个是config.xml，放在etc目录下面
app/code/local/App/Configviewer/etc/config.xml
文件内容如下
0.1.0
第二个文件需要在如下位置创建
app/etc/modules/App_Configviewer.xml
第二个文件应该遵循如下命名规则“Packagename_Modulename.xml”，文件内容如下
true
local
我们先不管这些文件是干什么的，以后会解释。
建立好这两个文件以后，你的模块的骨架就已经完成了。
Magento已经知道你的模块存在，但是现在你的模块不会做任何事情。
我们来确认一下Magento确实装载了你的模块
清空Magento缓存
在后台管理界面，进入System->Configuration->Advanced
展开“DisableModulesOutput”
确认“App_Configviewer”显示出来了
如果你看到“App_Configviewer”，那么恭喜你，你已经成功创建了你第一个Magento模块！
创建模块逻辑
我们之前创建的模块不会做任何事情，下面我们来为这个模块加入逻辑
1.检查“showConfig”查询字符串是否存在
2.如果“showConfig”存在，那么检查“showConfigFormat”查询字符串是否存在
3.如果“showConfigFormat”存在，那么输出指定格式的配置信息，否则输出默认格式的配置信息
4.终止执行流程
首先更改我们的config.xml文件
xmlversion="1.0"encoding="UTF-8"?
>
0.1.0
singleton
App_Configviewer_Model_Observer
checkForConfigRequest
然后创建如下文件
App/Configviewer/Model/Observer.php
输入以下内容
php
classApp_Configviewer_Model_Observer{
constFLAG_SHOW_CONFIG='showConfig';
constFLAG_SHOW_CONFIG_FORMAT='showConfigFormat';
private$request;
publicfunctioncheckForConfigRequest（$observer）{
$this->request=$observer->getEvent（）->getData（'front'）->getRequest（）;
if（$this->request->{self:
:
FLAG_SHOW_CONFIG}==='true'）{
$this->setHeader（）;
$this->outputConfig（）;
}
}
privatefunctionsetHeader（）{
$format=isset（$this->request->{self:
:
FLAG_SHOW_CONFIG_FORMAT}）?
$this->request->{self:
:
FLAG_SHOW_CONFIG_FORMAT}:
'xml';
switch（$format）{
case'text':
header（"Content-Type:
text/plain"）;
break;
default:
header（"Content-Type:
text/xml"）;
}
}
privatefunctionoutputConfig（）{
die（Mage:
:
app（）->getConfig（）->getNode（）->asXML（））;
}
}
?
>
好了，代码编辑结束。
清空你的Magento缓存，输入如下URL
【注：
根据文中的配置，不难看出任何指向Magento的URL加了“?
showConfig=true”以后，都会输出同样的内容，正常的执行流程会被终止。
】
配置文件分析
打开上述URL，你应该看到一个巨大的XML文件。
这个文件描述了当前Magento系统的状态。
它列出了所有的模块，数据模型，类，事件，监听器等等。
举个例子，如果你搜索如下字符串
Configviewer_Model_Observer
你会发现刚刚你创建的那个类被列出来了。
Magento会解析每个模块的config.xml，并把它们包含在这个全局配置中。
这个配置文件有啥用？
到目前为止，我们所作的事情似乎没什么意义，但是这个配置文件却是理解Magento的关键因素。
你创建的每一个模块都会被加到这个配置文件中，任何时候，你需要调用一个系统功能的时候，Magento都会通过这个配置文件来查询相应的模块和功能。
举个简单的例子，如果你懂MVC的话，你应该和“helperclass”之类概念的打过交道
$helper_salesrule=newMage_SalesRule_Helper（）;
Magento抽象了PHP的类声明方式。
在Magento系统中，上面的代码等同于
$helper_salesrule=Mage:
:
helper（'salesrule'）;
Magento将通过以下逻辑来处理这行代码
在配置文件中查找标签
在里面查找标签
在里面查找标签
实例化从#3找到的类（Mage_SalesRule_Helper）
Magento总是通过配置文件来获得类名，这个逻辑看起来有些复杂，但这样做的优点也很明显，我们可以不需要更改Magento的代码就能更改Magento的核心功能。
【注：
在这个例子中，我们可以通过修改配置文件用我们自己的SalesRule_Helper类来替换原来那个】这种高度抽象的编程方式在php中并不常见，但是它可以让你清晰的扩展或者替换系统的某一部分。
深入理解Magento–第二章–Magento请求分发与控制器
Model-View-Controller（MVC），模型-视图-控制器，源于Smalltalk编程语言和XeroxParc。
现在有很多系统是基于MVC架构的，不同的系统MVC的实现也略有不同，但都体现了MVC的精髓，分离数据，业务逻辑和显示逻辑。
最常见的PHPMVC框架是这样的
URL请求被一个PHP文件拦截，通常称为前端控制器（FrontController）
这个PHP文件分析这个URL，获得一个执行控制器（ActionController）的名字和一个执行方法（ActionMethod）的名字，这个过程通常称为路由（Routing）
实例化#2获得的执行控制器
调用执行控制器的执行方法
执行方法中处理业务逻辑，比如获取数据
执行控制器负责把数据传递给显示逻辑
显示逻辑生成HTML
这个架构相对于传统的“每个php都是一个页面”来讲已经是一个巨大的飞跃，但还是有人抱怨【注：
CodeIgniter就是这样一个MVC框架】
前端控制器仍然以全局的方式运行
基于配置的惯例导致了系统不够模块化
URLRouting不够灵活
控制器往往和视图绑定
更改默认设置往往导致大量的重构
Magento创造了一个更抽象的MVC来解决上述问题。
URL请求被一个PHP拦截
这个PHP文件实例化一个Magento对象
Magento对象实例化前端控制器
前端控制器实例化全局配置中指定的路由对象，可以是多个
路由对象会逐个与请求URL匹配
如果发现匹配，那么可以获得一个执行控制器和一个执行方法的名字
实例化#6获得的执行控制器，并调用相应的执行方法
执行方法中处理业务逻辑，模型数据
控制器实例化布局对象（Layout）
布局对象根据请求的参数，系统配置创建一个块对象（Block）列表，并实例化
布局对象会调用块对象的output方法生成HTML。
这是一个递归的过程，因为块对象可以嵌套块对象
每一个块对象都和一个模板文件（TemplateFile）对应。
块对象包含了显示逻辑，模板文件包含了HTML和PHP输出代码
块对象直接从模型那里获得数据，换句话说，在Magento的MVC架构中，控制器并不直接把数据传给视图
这里很复杂，我们以后会详细解释每一个部分。
我们先关注“前端控制器->路由对象->执行控制器”部分。
HelloWorld示例
我们讲了太多理论，现在让我们来实践一下，通过实践来加深理解。
下面是我们将要做的事情
创建一个HelloWorld模块
为这个模块配置路由
为这个模块创建执行控制器
创建HelloWorld模块
首先，我们要创建一个模块的目录结构，这个我们以前已经做过了，就不再熬述
app/code/local/App/Helloworld/Block
app/code/local/App/Helloworld/controllers
app/code/local/App/Helloworld/etc
app/code/local/App/Helloworld/Helper
app/code/local/App/Helloworld/Model
app/code/local/App/Helloworld/sql
下面是config.xml的内容
PATH:
app/code/local/App/Helloworld/etc/config.xml
xmlversion="1.0"encoding="UTF-8"?
>
0.2.0
然后我们要创建一个系统配置文件来激活这个模块
PATH:
app/etc/modules/App_Helloworld.xml
true
local
>
最后，让我们检查一下模块是不是已经被激活
清空Magento缓存
在管理后台，进入System->Configuration->Advanced
展开“DisableModulesOutput”
确认App_Helloworld显示出来了
配置路由
下面，我们要配置一个路由。
路由是用来把一个URL请求转换成一个执行控制器和方法。
和传统的PHPMVC不同的是，你需要在Magento的全局配置中显式的定义你的路由。
我们继续上面的例子，在config.xml中，添加如下代码
xmlversion="1.0"encoding="UTF-8"?
>
0.1.0
App_Helloworld
helloworld
在这里，我们有很多新名词要解释。
什么是frontend？
frontend标签指向一个Magento区（Area），比如“frontend”就是指网站的前台，“admin”是指网站的后台，“install”是指Magento的安装程序。
【注：
这个有点像磁盘分区，区和区之间是相互独立的，但是都归操作系统能够管理，在这里归Magento管理。
默认的Magento安装没有“install”这个区，frontend区接管了，全局配置中的以下代码可以解释这一点
...
Mage_Install
install
...
】
什么是routers？
PhilKarlton有一句很著名的话“在计算机领域只有两件事是困难的：
缓存和命名”。
Magento引入了很多新概念，无疑存在很多命名问题，这里就是一个例子。
routers标签有时候包含的是路由对象的定义，有时候包含的是路径的定义。
路由对象是进行路由操作的实体，而路径仅仅是路由对象的一个参数。
【注：
如果你仔细看过那个全局配置xml的话，你会发现有两处地方出现routers，一处是“web->routers”，另外一处是“frontend->routers”。
你再仔细看看会发现两处routers包含的内容不一样。
第一处包含的是路由对象的定义，第二处包含的是路径的定义。
】
什么是module？
这个标签的内容应该是一个模块的全名，Packagename_Modulename，在这里是“App_Helloworld”。
Magento用这个名字来定位你的模块文件。
什么是frontname？
当一个router解析一个URL的时候，它是按照如下规则进行的
所以，当我们在frontname标签里定义了“helloworld”以后，Magento会把如下的URL请求交给我们的模块“App_Helloworld”来处理
有些人容易把frontname和前端控制器（FrontController）混淆起来。
它们是两个不同的概念，frontname只跟路由相关，学过Zf的人都知道，其实就是个模块名。
【注：
根据我们前面讲过的Magento的MVC流程，前端控制器是用来实例化所有路由的，而这里的“frontName”只是路由过程中的一个参数】
什么是helloworld？
这个标签的名字应该是模块名字的小写版本。
我们的模块名字是“Helloworld”，所以这里我们用“helloworld”。
你应该也已经注意到我们定义的“frontName”也是和我们的模块相匹配的。
这是一个不成文的规定，但不是强制要求。
事实上，一个模块可以定义多个，也就是可以有多个“frontName”。
为路由创建执行控制器
还记得Magento的MVC流程吗？
路由会把控制权交给执行控制器。
上面我们定义了路由，现在我们来定义我们的执行控制器。
首先创建文件
app/code/local/App/Helloworld/controllers/IndexController.php
模块的控制器应该放在模块的子目录“controllers”（小写c）里面。
这是规定，Magento会在这个目录寻找模块的控制器文件。
我们的第一个控制器包含以下内容
classApp_Helloworld_IndexControllerextendsMage_Core_Controller_Front_Action{
publicfunctionindexAction（）{
echo'HelloWorld!
';
}
}
清空Magento缓存，请求如下URL
如果你看到一个空白页面上面写着“HelloWorld”，那么恭喜你，你已经成功创建了你的第一个Magento控制器！
如何命名执行控制器？
还记得config.xml的标签吗？
App_Helloworld
执行控制的名字的构成如下
以标签的内容开始（App_Helloworld）
紧接一个下划线（App_Helloworld_）
加上我们给控制器取的名字“Index”（App_Helloworld_Index）
最后加上关键词“Controller”（App
升级会员 