php.MVC教程
ASP,JSP,PHP是WEB开发的三大技术,三种技术优缺点也早就有人分析过了。无非也就是ASP简单易用且有microsoft做靠山,JSP功能强大是因为有java支持,PHP则开源跨平台。在国内,ASP应用范围最广,JSP发展势头最猛,PHP则处于劣势。这可能与公司的支持以及技术的培训有关。
由于公司项目的需要,我这才接触PHP,用过一段时间后两点体会最深刻,一是学习容易,上手极快,内置函数很多,适合快速开发;二是学习资料匮乏,普及不广,很多时候都要去看英文文档。
对于中小型WEB应用来说,PHP有很强的竞争力,LINUX+APACHE+MYSQL+PHP(LAMP)的组合几乎可以胜任绝大多数网站的解决方案,对于大型应用来讲,对于系统架构要求更高,需要有成熟的框架支持,JSP的struts是个不错的框架,国内介绍它的资料也非常多,应用逐渐广泛起来,对应的PHP也有php.MVC,但是我搜遍了网络也没有发现一篇中文文档,这才让我动了翻译用户指南念头,也算是抛砖引玉,希望PHP能够在国内蓬勃发展起来。
php.MVC是PHP Web应用程序的一个开源框架,它实现了模型-视图-控制器(MVC)设计模式——Web应用程序的工业标准,鼓励基于Model2架构的应用程序设计。这种开发模式允许网页或其他显示内容从内部应用程序代码中分离出来,让设计者和程序员更容易地集中于他们各自的专业领域。这个框架提供了一个单独入口点的控制器。这个控制器接受HTTP请求,并根据配置文件分配给相应的动作处理。
模型包含了应用程序的业务逻辑,控制器负责处理请求,并转向到相应的显示组件——将HTML和PHP标签的结合起来的模板文件。处理结果返回给客户端浏览器,或者通过另外的协议比如SMTP。
php.MVC是用PHP来实现Jakarta Struts框架,目前它支持Struts的许多特性,包括申明应用程序的配置参数通过XML解析器。比如在XML配置文件中指定各种业务逻辑组件与对应的显示组件之间的映射。
php.MVC的网站地址http://www.phpmvc.net
php.MVC必须安装在PHP v 4.1.0及以上版本的Web服务器上
Windows(Apache 2.0.51+php-4.3.9-Win32)
1.从http://www.apache.org下载相应的Apache版本。
2.从http://www.php.net下载相应的PHP版本。
3.从http://www.phpmvc.net下载相应的php.MVC版本。
4.建立目录c:\www作为Web服务器目录,c:\webapp作为Web根目录,
你也可以定义自己的目录,以下作相应的修改即可。
5.将Apache安装到c:\www,打开浏览器,在地址栏输入http://localhost测试是否安装成功
注意:如果你的系统上已经安装有其他Web服务器(如IIS 5),且占用了80端口,请先停止该服务器。
6.把PHP压缩包解压到c:\www。
7.将c:\www\php-4.3.9-Win32目录下php.ini-dist拷贝到系统目录如c:\winnt中并更名为php.ini,
将php4ts.dll拷贝到系统目录如c:\winnt\system32中,打开c:\www\Apache Group\Apache2\conf目录下http.conf文件,
在ScriptAlias /cgi-bin/ "c:/www/Apache Group/Apache2/cgi-bin/"下加入
ScriptAlias /php/ "c:/www/php-4.3.9-Win32/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"
并将DocumentRoot "c:\www\Apache Group\Apache2\htdocs"改为DocumentRoot "c:/webapp"
8.把php.MVC压缩包解压到c:\webapp
9.打开c:\webapp\phpmvc目录下Main.php文件,修改如下内容
// Set php.MVC library root directory
$appServerRootDir = 'c:\webapp\phpmvc'; // no trailing slash
// Set the application path
$moduleRootDir = 'c:\webapp\phpmvc'; // no trailing slash
// Set the OS Type [Optional] [UNIX|WINDOWS|MAC] if we have
// trouble detecting the server OS type. Eg: path errors.
$osType = 'WINDOWS';
确认c:\webapp\phpmvc\WEB-INF目录下phpmvc-config.data有可写权限。
打开浏览器,在地址栏输入http://localhost/phpmvc/Main.php?do=stdLogon测试是否安装成功。
10.要查阅更为详细的安装文档,请看http://www.phpmvc.net/docs/installIdx.php?doc=all。
三、php.MVC系列教程之框架介绍:
一、介绍
php.MVC是一个开放源代码的Web应用框架,实现了模型-视图-控制器(MVC)设计模式,鼓励基于Model2架构的应用程序设计。这种开发模式允许网页或其他显示内容从内部应用程序代码中分离出来,让网页设计者和程序员更容易地集中于他们各自的专业领域。
这个框架提供了一个单独入口点的控制器。这个控制器接受HTTP请求,并根据配置文件分配给相应的动作处理。模型则包含了应用程序的业务逻辑。当请求处理完成,控制器调用相应的显示组件——通常用模板文件来实现。处理结果返回给客户端浏览器,或者通过另外的协议比如SMTP。
php.MVC是用PHP来实现Jakarta Struts框架,目前它支持Struts的许多特性,包括通过XML解析器实现XML与对象的映射,从而设置应用程序的配置参数。比如在XML配置文件中指定各种业务逻辑组件与对应的显示组件之间的映射。
图1所示的逻辑图描述了框架的高层结构。
可以看出框架包括三个主要的组件:前端控制器、主控制器和动作分配器。
二、优/缺点
优点:
1. php.MVC是一个开源项目能让你完全接触源代码,使开发者能更深入的了解其内部实现机制。
2. 使用php.MVC可以促进模块化开发,促使开发者和设计者的角色分离,提高代码的重用性和可维护性。
3. php.MVC框架的学习可以借鉴Jakarta Struts的一些知识和经验,如果你有开发Struts的经验,那么就可以快速地用php.MVC来进行开发。
4. MVC模式是Java开发Web应用程序的一个设计标准,使用php.MVC框架还有助于Web开发者理解MVC设计模式。
缺点:
1. php.MVC功能仍在不段变化和完善中,你需要随时关注最新版本。
2. 使用php.MVC需要进行额外的学习过程。
3. 应用php.MVC可以得到清晰的程序结构,但也会增加系统复杂度。
4. 应用php.MVC可以让程序更加有条理,但也会降低程序执行速度。
因此你需要根据项目大小、周期、成本,开发人员素质等众多条件来决定是否应用php.MVC框架。
四、php.MVC系列教程之处理流程:
php.MVC框架由许多类组装而成,但是我们不必了解所有类的详细工作过程也可以使用这个框架,图2显示了我们使用该框架需要了解的一些核心组件。
从图2我们可以看到一个典型的Web浏览器的HTTP请求如何与我们应用程序框架的核心类进行交互,然后如何得到HTTP响应返回到Web浏览器。
现在,让我们以一个实例来了解框架的处理流程。比如要查看公司销售报表,先在浏览器地址栏输入
http://www.myhost.com/mycompany/Main.php?do=salesReport 客户端便发送给php.MVC应用程序一个请求。应用程序框架的控制器处理这个请求,分析查询字符串,取出请求路径关键字。在这个实例中,路径为salesReport。后面我们将看到如何通过XML配置文件来配置必需的应用行为,绑定表单验证,业务逻辑处理和显示组件。
如果我们想严格控制只有通过验证的人才能访问这个报表,则用户必须先输入基本的验证信息,通常是用户名和密码。为了限制只有通过了验证的用户才能访问该报表,这里用了一个被称作ActionForm的类,我们需要继承框架的ActionForm来定义自己的表单验证类,比如SalesActionForm,如下所示:
class SalesActionForm extends ActionForm { ... }.
在SalesActionForm类里我们要检查用户是否可信任的以决定下一步动作。如果用户没有通过验证,我们将重定向到初始页面要求重新输入;如果他通过了验证,控制器会通过Action类来调用业务处理类。
我们通过继承框架Action类来进行自定义,比如SalesAction,如下所示:
class SalesAction extends Action { ... }.
在XML配置文件中我们要定义请求与Action类的对应关系,这样控制器找到相应的Action类,这里调用SalesAction。在SalesAction类里我们能访问业务处理类和数据源。本例中我们从数据库中取得销售数据,制成报表格式。例如:我们创建一些对象,后面在销售报表模板中可以使用这些对象,如下所示:
// Sales report items - per zone (individual object instances):
$item1 = new Item('Northern Zone Sales' , $salesNorth);
$item2 = new Item('Southern Zone Sales' , $salesSouth);
...
当我们完成了销售报表,就要通过控制器指定显示组件显示出来。这是通过一个在XML配置文件中已经配置好的被称作Forward的对象的来完成,如下所示:
return $mapping->findForwardConfig('salesReportSuccess');
Forward对象包含了销售报表模板的路径,比如salesReport.tpl,这也是在配置文件中定义。
然后控制器将请求转向到ActionDispatcher,由它定向到指定的显示组件,在本例中是salesReport.tpl,在模板中通过访问先前定义对象和变量从而得到在SalesAction里准备好的数据。
下面显示我们如何用phpTAL模板系统访问报表数据并生成显示视图,对象$item1我们用类变量$item1->value
...
<!-- // Sales report items - per zone (individual object instances): -->
<table class='salesTable'>
<tr>
<td class='salesItemDesc' tal:content="item1/salesNorth">
Sales report->value will appear here</td>
...
最后将处理结果通过HTTP发送到客户端浏览器,从而也就完成了整个处理过程。
现在让我们来分析一个典型的php.MVC Web应用程序的结构。
图3显示了如何布置一个php.MVC应用程序和其核心类库
php.MVC类库
从上图我们可以看到php.MVC类库被安装在服务器的DEV目录下,这个目录用来放置一些通用类库。为了安全起见,该目录不允许Web用户访问,因此最好不要将该目录建立在Web根目录。如果由于某种原因需要将php.MVC类库安装在Web 根目录,那你必须用.htaccess文件来控制其访问对象。
下面显示的是Apache的.htaccess文件
# options the .htaccess files in directories can override.
# Edit apache/conf/httpd.conf to AllowOverride in .htaccess
# AllowOverride AuthConfig
# Stop the directory list from being shown
Options -Indexes
# Controls who can get stuff from this server.
Order Deny,Allow
Deny from all
Allow from localhost
这将指示Apache服务器
拒绝所有人访问包含有该.htaccess的目录及其子目录,在本例中是php.MVC类库的/WEB-INF目录下包含的文件及子目录。
允许从服务器主机可以访问,这允许使用Web 服务器的开发者能够浏览该类库下的测试目录以及执行单元测试。
php.MVC文件不必做任何修改即可正常使用,为了能够访问到类库文件,我们需要在Web应用程序的Main.php文件中设置php.MVC类库根目录,如下所示:
$appServerRootDir = 'D:/Dev/PHP/phpmvc-base'; // no trailing slash
php.MVC Web应用程序
从图3我们可以看出一个Web应用程序目录SalesReport被放置在Web根目录WWW下。
在SalesReports下的一级目录下我们可以看到几个目录和Main.php文件,art目录用来存放应用图像,style目录用来存放样式表,这两个目录可以通过Web访问,并且可以根据实际需要重新命名,我们能够在模板文件中访问这些资源,如下所示:
<link rel='stylesheet' type='text/css' href="./style/mystyles.css">
接下来是WEB-INF目录,该目录存放应用类和资源。它不能通过Web访问,这是通过.htaccess文件来实现的。开发者可以在该目录下自由创建目录及子目录,但需要在WEB-INF目录下的ModulePaths.php中声明。在WEB-INF目录下,class目录用来存放应用类和资源文件,tpl目录用来存放显示资源,比如网页模板。
在WEB-INF目录下还有.htaccess,ModulePaths.php, phpmvc-config.xml, phpmvc-config_1_1.dtd, phpmvc-config.data and prepend.php files。其中.htaccess文件已经在前面讨论过了。
ModulePaths.php文件用来定义指定应用类及资源的路径,我们可以象下面一样定义:
$appDirs = array();
$appDirs[] = ''; // starting with the sub-application home directory
$appDirs[] = 'WEB-INF';
$appDirs[] = 'WEB-INF/classes';
$appDirs[] = 'WEB-INF/tpl';
phpmvc-config.xml文件是php.MVC应用程序的中心组件,可以通过XML来定义应用程序的行为和属性,在后面将有更为详细的介绍。
phpmvc-config_1_1.dtd文件是phpmvc-config.xml的文档类型定义文件,DTD文件指定了在phpmvc-config.xml文件中可以包含的节点,它是应用程序行为和属性的最终参照。大部分XML编辑器都可以用DTD文件来验证phpmvc-config.xml文件的有效性。
phpmvc-config.data文件包含了应用程序的一些配置数据,这些配置数据是根据phpmvc-config.xml文件的最新信息动态生成的。假如你的应用程序得不到期望结果时,可以在phpmvc-config.xml中增加空格键以修改它,重新运行应用程序时配置数据就会被重新生成。
prepend.php文件常用来包含应用文件,前面,我们已经包含了应用类和模板文件,我们可以用它来包含其他类和资源文件,如下:
include_once 'Locale.php';
include_once 'PropertyMessageResources.php';
Main.php就是php.MVC应用程序的那个单一入口点,它被放置在应用程序根目录。所有的请求都需要通过它来完成。
从上面我们可以看出,Main.php文件中必须定义php.MVC类库的路径
$appServerRootDir = 'D:/Dev/PHP/phpmvc-base'; // no trailing slash
接下来我们将指定应用程序路径
$moduleRootDir = 'C:/WWW/SalesReports'; // no trailing slash
我们也可以设置应用程序的ActionDispatcher路径。每个php.MVC应用程序通常都要自定义一个
ActionDispatcher来处理指定的请求,我们需要定义ActionDispatcher变量,如下所示:
$actionDispatcher = 'ReportActionDispatcher';
$osType变量用于指定php.MVC所在主机的操作系统类型,通常框架能够自动检测出来并以此来设置应用路径,但是如果你的应用程序运行出现路径错误,请手工设置该变量。如下所示:
$osType = 'UNIX';
正常情况下,包含在Main.php中的其它参数可以不做修改。
图4显示了从开发者的角度来看php.MVC示例程序中主要类和资源,以及它们之间的关系。
在上图左上角是ActionForm类,我们通过继承它来处理HTML表单验证和与之相关的功能。示例中通过继承ActionForm定义了一个基类AbstractBaseForm,它包含一些通用的逻辑,可以为更多的应用程序ActionForm类所引用,比如SalesReportForm类就具体实现了AbstractBaseForm类。
在上图上方是Action类,通常用来处理通过ActionForm类完成了初始化验证的请求。我们再次看到了继承Action定义的基类AbstractBaseAction,SalesReportAction类继承AbstractBaseAction用来处理请求,在SalesReportAction类中我们能调用业务逻辑类ReportBusinessClass,访问数据库和其他资源。
在上图下方是ActionDispatcher类,负责为Action请求准备显示资源如网页模板。通常,我们需要继承框架ActionDispatcher类来定义自己的Dispatcher,比如示例中的ReportActionDispatcher。
在后面我们将有更为详细的介绍
前面我们讲解了php.MVC的结构以及流程,接下来,我们将重点介绍以下的核心组件:
- XML配置文件是php.MVC应用程序的“配电盘”,为HTTP请求绑定组件。
- Controller由一些框架类组成,负责为HTTP请求找到正确的Form和Action类以及显示资源,在
- phpmvc-config.xml文件中定义。
- ActionForm类通常用来处理Web表单验证。
- Action类可以访问业务处理类,能让我们把精力放在应用程序业务流上。
- ActionDispatcher类操纵显示资源的处理。
XML应用程序配置系统
phpmvc-config.xml文件是php.MVC应用程序主要的配置组件,每个php.MVC应用程序都有自己的phpmvc-config.xml文件,通常位于WEB-INF目录下。一旦这个文件被修改,Controller就会调用XML解析器解析该文件,将XML节点转化为配置对象,这些配置对象缓存在phpmvc-config.data文件中,通常它也是放在与phpmvc-config.xml相同的目录。在后面的请求中,Controller将会调入缓存的phpmvc-config.data文件,保存处理时间。
在图5我们看到了配置文件与应用程序组件是如何联系起来的,我们为action节点定义了一个path属性为salesReport,这个标识就是Action的访问路径如:http://www.myhost.com/mycompany/Main.php?do=salesReport.
在action节点中name属性为salesReportForm,这就告诉Controller我们要用一个名为salesReportForm的form-bean来处理表单验证,我们能看到名为salesReportForm的form-bean在action-mappings节点上面的form-bean内定义了,其中validate属性为true表示控制器会调用form-bean的validate(...)方法。
在action节点和与其联系的form-bean节点中,都有type属性。我们用这个属性定义form-bean和action各自对应的类。比如action节点就定义了Action类为SalesReportAction,form-bean节点的ActionForm类为SalesReportForm。
接下来我们还需要在action节点中定义forward节点组来指定框架显示组件的URI,其中name属性为forward节点定义一个标识,path属性定义了与这个action相关联的资源或模板。示例中第一个forward节点定义为salesReportSuccess,资源路径为salesReport.tpl,第二个定义为salesReportFailure,资源路径为salesReportIndex.tpl,在我们的类里我们能用这些forward节点指定显示资源的位置。在这个实例中,假如报表成功生成,我们用salesReportSuccess对象和它所定义的salesReport.tpl来处理请求,如果报表生成失败,我们用salesReportFailure对象和salesReportIndex.tpl来处理,一般是返回到初始页。
phpmvc-config.xml文件可以用一般的文本编辑器就可以修改,或者用专用XML编辑器。专用XML编辑器可以使用phpmvc-config_1_1.dtd来验证该配置文件的有效性,DTD文件定义在XML文件可是使用的元素,属性以及数值。关于这方面的知识可以查阅XML的相关资料。
下面是示例phpmvc-config.xml文件:
XML Configurations and Bindings: phpmvc-config.xml |
---|
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE phpmvc-config PUBLIC "-//PHPMVC//DTD PHPMVC Configuration 1.0//EN" "./phpmvc-config_1_1.dtd"> <phpmvc-config> <form-beans> <form-bean name="salesReportForm" type="SalesReportForm"/> </form-beans> <action-mappings> <action path = "salesReport" type = "SalesReportAction" name = "salesReportForm" scope = "request" validate = "true"> <forward name="salesReportSuccess" path="salesReport.tpl"/> <forward name="salesReportFailure" path="salesReportIndex.tpl"/> </action> </action-mappings> </phpmvc-config> |
控制器(Controller)由一些类组成,根据预先定义的配置选项处理用户请求。一个典型的用户请求如下:
http://www.myhost.com/mycompany/Main.php?do=salesReport.
php.MVC 控制器由两部分组成:前端控制器和控制器。当请求到来时,前端控制器负责安装应用程序,控制器则根据phpmvc-config.xml的配置属性处理请求。
用户请求被Main.php文件接收,这里,将设置一些初始化参数。前端控制器将执行以下任务:
- 定义应用程序路径:这将指定php.MVC类库以及Web应用程序的路径,如下:
$appServerRootDir = 'C:/WWW/phpmvc-base';
$moduleRootDir = 'C:/WWW/mycompany'; - 定义应用程序的ActionDispatcher:我们通常需要扩展框架ActionDispatcher来定义自己的Dispatcher类:
$actionDispatcher = 'MyActionDispatcher'; - 初始化应用程序类路径:为了将类和资源装入,前端控制器将导入预先定义的全局路径以及应用程序路径。我们可以在/WEB-INF/ModulePaths.php中设置路径,如下:
$appDirs = array();
...
$appDirs = 'WEB-INF/report_tpl';
$appDirs = 'WEB-INF/report_classes'; - 包含应用程序类:前端控制器将导入它所需要的类文件,我们也可以用/WEB-INF/prepend.php文件来有选择性地导入一些特殊的应用程序类文件。如下:
include_once './WEB-INF/mytools/MyTools.php'; - 配置应用程序:前端控制器将为应用程序设置配置信息,比如我们先前定义的ActionDispatcher。
- 初始化控制器:前端控制器现在将创建一个应用服务器实例(ActionServer)。
- 导入配置信息:前端控制器现在将导入应用程序配置信息,假如phpmvc-config.xml从最后一次请求后被修改了,phpmvc-config.xml文件将被重新处理并将数据缓存到/WEB-INF/phpmvc-config.data中。
- 初始化HTTP请求:前端控制器现在将设置HTTP请求并添加请求属性。
- 调用应用程序控制器:前端控制器现在已经完成了准备工作,将会把处理权交给控制器。
控制器接收从前端控制器传来的请求,根据配置属性执行一系列操作。
处理action路径:控制器将根据请求路径识别出关键字,选择一个action映射。比如请求路径为:
http://www.myhost.com/mycompany/Main.php?do=salesReport, action路径就为salesReport。
- 处理现场:根据需要为当前用户选择一个Locale
- 处理内容格式:根据需要设置内容格式,默认为text/html。
- 处理不缓存:根据需要设置不缓存头信息,默认为:
"Pragma", "No-cache"
"Cache-Control", "no-cache"
"Expires", 1 - 处理预处理任务:可以在自定义的ActionServer子类中覆盖这个方法,执行一些指定的预处理任务。
- 处理Action映射:控制器将根据请求识别action映射,根据phpmvc-config.xml的相应节点生成action映射对象(ActionConfig),比如:<action path = "salesReport" .../>。
- 处理角色:检查能执行这个action的所有必须的认证。
- 处理ActionForm:控制器将根据action映射找到相关联的ActionForm,form-bean就是由action的name属性指定,比如:
<action ... name = "salesReportForm" .../>。 - 处理Populate:根据请求参数设置ActionForm实例的属性。
- 验证ActionForm:根据action的validate属性值如:<action validate = "true" .../>,决定是否调用ActionForm的validate()方法。如果validate()返回False(验证失败),控制器将用action中input属性所指定的显示资源(模板)显示错误,比如:
<action path = "salesReport"
...
validate = "true"
input = reportsIndex.tpl>
假如validate()返回True(验证通过),则将继续处理。处理Forward:控制器检查forward映射的URI是否正常,如果是,继续处理。 - 处理Include:控制器检查include映射的URI是否正常,如果是,继续处理。
- 处理Action创建:控制器将创建或获取Action实例来处理这个请求,这是用action的type属性来定义的,比如:
<action path = "salesReport"
type = "SalesReportAction"
... - 处理Action执行:控制器现在将调用Action类的execute()方法,比如SalesReportAction->execute(...)。在该方法内,我们将调用业务处理逻辑类。
- 处理Action链:控制器将检查是否还有另外一个Action需要处理,在应用程序配置文件中,我们通过ActionChain能定义一系列Action,为了定义ActionChain,需要为action节点的forward元素添加一个nextActionPath属性,比如:
<action path = "salesReport"
type = "SalesReportAction"
...
<forward
name = "salesReportSuccess"
path = "salesReport.tpl"
nextActionPath = "salesReport2"/>
... - forward元素的path属性是必须项,假如这个特殊的Action没有输出,我们可以设置path = ""。
- 处理Action Forward:控制器将转发或重定向到指定的资源,一个forward请求在当前处理器中被处理。RequestProcessor只是把控制权交给ActionDispatcher,那里包含了指定的URI模板。比如:
<forward
name="forward_path
path="forwardRequest"
redirect="false"/> - 重定向请求实际是发送给客户端浏览器一个标头响应,然后重定向到一个新的URL。在发送重定向标头信息时当前的处理将立即终止。
<!-- This server -->
<forward
name="redirect_path
path="/MyApp/Main.php?do=newRequest"
redirect="true"/><!-- This server, or a remote server -->
<forward
name="redirect_path
path="http://www.myhost.com/MyApp/Main.php?do=newRequest"
redirect="true"/>
假如没有其他的Action需要处理,控制器处理结束。