第 1 章 symfony 介绍 symfony 能做什么？使用 symfony 需要掌握哪些知识？这一章会解答这些问题。 symfony 简介 开发框架可以自动化地完成一些特定的开发模式来简化应用程序开发过程。 开 发框架还使程序代码结构更好，通过开发框架开发人员可以写出更好、更易读的、 更容易维护的代码。总之，开发框架简化了编程，因为它把复杂的操作封装成了 简单的语句。 symfony 是一个完整的 web 应用开发框架，它为加速开发提供了几个关键功能。 首先，它把 web 应用的业务规则，服务逻辑还有表现页面分割开来。它为减少开 发复杂 web 应用提供了大量的工具和类。另外，它把一些常用的任务变成了自动 化的方式从而使开发人员能够完全专注于每个程序的独特的地方。这 三 个 优点综 合起来就意味着每次开发新的 web 应用的时候不用重新发明轮子了！ symfony 完全由 PHP 5 编写。它经过了广泛的测试并被用于很多实际的项目中， 一些高访问量的电子商务网站正在使用 symfony。symfony 与包括 MySQL、 PostgreSQL、Oracle 还有 Microsoft SQL Server 在内的大多数数据库系统兼容。 symfony 能够在*nix 与 Windows 平台上运行。我们现在来看一下 symfony 具体有 哪些功能。 symfony 的功能 symfony 是为了满足下面的需求而开发的： · 在大多数平台上都能够很容易安装 (保证能运行在标准*nix 和 Windows 平台) · 不依赖某种特定的数据库 · 多数情况下容易使用，并且有足够的弹性来实现更复杂的功能 · 遵循惯例重于配置原则--开发人员只需要配置与惯例不同的部分 · 能够适应大多数 web 最佳实践与设计模式 · 可供企业使用--能够适应现有的 IT（information technology）策略与 体系，并且很稳定适合长期项目 · 非常易读的代码、带有 phpDocumentor 注释，维护轻松 · 易于扩展，允许与非 symfony 的库进行整合 自动化 Web 项目功能 symfony 能够自动化 web 开发的大部分要素： · 内建的国际化层能够实现数据与界面翻译，还有内容本地化。 · 表现部分由于使用了模板和布局，不懂任何框架知识的网页设计师也可以 掌握。辅助函数封装了大量的代码从而减少了表现部分的代码。 · 表单支持自动验证和重新提交，这 确保了数据库里的数据的质量，用 户体 验也更好。 · 输出转义能够保护程序不受到利用错误数据的攻击。 · 缓存管理功能减少了网络带宽和服务器负载消耗。 · 使用验证与证书功能能很容易地实现受限制区域还有用户权限管理。 · 路由与漂亮的 URL 使网页的网址容易被搜索引擎接受。 · 内建的 e-mail 与 API 管理使 web 程序超越传统的浏览器交互。 · 方便的数据列表提供了自动的分页、排序还有筛选功能。 · Factories, plug-ins, 还有 mixins 提供了高层次的扩展性。 · 容易使用的 Ajax 交互，以一行代码(辅助函数 helper)去封装跨浏览器支 持的 Javascript 开发环境与工具 symfony 可以完全的定制以满足有自己代码规范与项目管理规则的企业。 它自 带了一些开发环境还有多种工具来实现自动化软件工程任务： · 代码生成工具非常适合于原形设计与一键式后台管理。 · 内建的单元测试与功能测试框架为测试驱动的开发提供了完美的工具。 · 测试工具条能够把当前页面的所有开发者需要的信息显示出来从而加快 调试速度。 · 能够实现两台服务器之间自动化部署的命令行工具。 · 能够有效地即时更新配置。 · 日志功能让管理员能够掌握程序的一举一动。 谁开发了 symfony？为什么要开发 symfony? symfony 的第一个版本由项目发起者同时也是本书的合著者 Fabien Potencier 于 2005 年 10 月发布。Fabien 是 Sensio (http://www.sensio.com/) 的 CEO， Sensio 是一个法国对 web 开发有创新见解的知名网络机构。 早在 2003 年，Fabien 研究了当时的 PHP 开源开发工具，发现没有一个能够满足 上面的这些需求。PHP 5 发布的时候，他发现现有的工具已经都很成熟，很难整 合到一个全功能的框架里。随后他花了 1 年的时间开发了 symfony 的核心，这个 核心基于 Mojavi MVC（Model-View-Controller）框架，Propel ORM （object-relational mapping），还有 Ruby on Rails 的模板辅助方法。 Fabien 最初是为了 Sensio 的项目开发了 symfony，因为一个高效的开发框架能 大大加快开发效率。它使得开发更直观，开发的程序更健壮更容易维护。这个框 架最初在一个女性内衣的零售商的电子商务网站的项目中应用并取得了成功，随 后被用到了其他的项目中。 在成功地将 symfony 运用于几个项目之后，Fabien 决定用开源的协议来发布 symfony。他之所以这么做是为了把自己的工作成果捐献给社区，并且收集用户 的意见来改进框架，展示 Sensio 的经验，另外这样做本身也是一种乐趣。 NOTE 为什么是"symfony"而不是"FooBarFramework"呢？因为 Fabien 想要一个 简单的名字，包含代表 Sensio 的"s"还有代表 framework 的"f"，并且容易记忆， 不跟其他的开发工具名字相似。另外，他不喜欢大写字母。尽管不是标准的英语， "symfony"成为了 Fabien 的选择，并且 symfony 也是这个项目的名称。另外一个 项目名称是"baguette"。 要成为一个成功的开源项目，symfony 需要大量的英文文档，这样能使更多的开 发者使用 symfony。Fabien 请 Sensio 的职员 François Zaninotto(本书的作者) 深入源代码来写电子版的手册。写作花了不少时间，但是当项目公开的时候，它 优秀的文档吸引了不少开发者。其余的就什么也不用说了。 symfony 社区 当 symfony 的网站(http://www.symfony-project.com/)推出后，全世界许许多 多的开发者下载、安装、阅读了在线文档，随后去开发了他们的第一个 symfony 的程序，社区开始热闹起来。 当时 web 应用程序开发框架正在变得流行，开发者们对全功能的 PHP 开发框架的 需求很高。symfony 由于代码质量还有文档的数量成为一个引人注目的解决方 案，这也是它相对于其他框架的优势。很快就有志愿者参与进来，提出修改或增 强的意见，校对文档，并参与到其他一些必要的工作中来。 我们欢迎所有愿意参与的人加入 symfony 开发，我们提供公开的源代码仓库还有 ticket 系统。目前 symfony 的代码主干主要还是 Fabien 在维护，这保证了代码 的质量。 目前，symfony 的论坛，邮件列表，还有 IRC 频道为整个社区提供了很优秀的支 持，平均每个问题会有 4 个回复之多。每天都有人安装 symfony，wiki 与代码片 断部分汇集了大量的用户提交的文档。每个星期平均会出现 5 个新的 symfony 项目，这个数字还在不断地增加。 symfony 社区是这个框架的第三个力量，我们希望读了本书后你能加入到这个社 区中来。 symfony 适合我吗? 不论你是 PHP 5 专家或 Web 应用程序开发的新手，你都能用 symfony。决定是否 使用 symfony 的主要因素是项目的大小。 如果你想开发一个只有 5 到 10 个网页的简单网站，少量的数据库访问，并且不 需要保证速度或者提供文档，那么你只要用 PHP 就够了。这种情况下使用 web 开发框架并没有太大的价值，而且面向对象或者 MVC 模型会使开发速度变慢。另 外，symfony 在只能以 CGI 模式下运行 PHP 的虚拟主机环境下并不能很有效率的 运作。 另一方面，如果你要开发一个更复杂的有更多业务逻辑的 web 应用程序，那么单 独使用 PHP 是不够的。如果你打算以后维护或扩展你的应用程序，那么你的代码 需要是简洁，易读和高效的。如果你打算在用户界面中方便的使用最新的技术(例 如 Ajax)，你不能只是写几百行 Javascript 代码。如果你想愉快而且快速的开 发，那么单独使用 PHP 可能会令你失望。上面这些，就是 symfony 适合你的原因。 当然，如果你是一个专业的 web 开发人员，你已经知道了 web 应用框架的所有优 点，并且你需要一个成熟的，具有详细文档和一个大的社区支持的 web 应用框架。 那么不要再犹豫，symfony 就是你的解决方案。 TIP 如果你想看比较直观的演示，建议去 symfony 的网站上的 screencast。看 了以后你会发现使用 symfony 开发是多么快速而愉快。 基本概念 在开始学习 symfony 之前，有几个概念需要理解。如果你已经知道 OOP、ORM、 RAD、DRY、KISS、TDD、YAML 还有 PEAR 你可以跳过本节。 PHP 5 symfony 本身是由 PHP 5 (http://www.php.net/) 开发的，symfony 专注于利用 PHP 5 制作网络应用程序。所以，想要彻底地了解 symfony 框架必须要对 PHP 5 有十分深刻的理解。 建议熟悉 PHP 4 但刚刚接触或者不熟悉 PHP 5 的开发者专注于 PHP 5 语言的新的 面向对象模型部分。 面向对象程序设计 (OOP) 我们在本章不去详细解释面向对象程序设计(OOP)，因为这个话题足够写一本书 了。由于 symfony 大量运用了 PHP 5 中 的 面 向 对 象 机制，面向对象程序设计(OOP) 是学习 symfony 的先决条件。 维基百科这样解释 OOP： 面向对象程序设计(OOP)可以被视作一种在程序中包含各种独立而又互相调用的 单位和对象的思想,这与传统的思想刚好相反：传统的面向过程程序设计主张将 程序看作一系列函数的集合，或者直接就是一系列对电脑下达的指令。 PHP 5 实现了面向对象中的类、对象、方法、继承等。如果你对这些概念不熟悉， 建议阅读相关的 PHP 文档，网址如下 http://www.php.net/manual/zh/language.oop5.basic.php。 魔术方法（Magic Methods） PHP 对象的一个优势是可以使用魔术方法。 这些方法可以不需要修改外部代码 而重写一个类的默认行为。这使得 PHP 语法有更少的冗余性和更具有扩展性。这 些 方 法 很 好识别，他们都是以双下划线(__)开始的。 例如， 当显示一个对象的时候， PHP 会暗中去寻找是否开发者定义过 __toString()方法: $myObject = new myClass(); echo $myObject; // Will look for a magic method echo $myObject->__toString(); symfony 使用了魔术方法， 所以你必须完全了解这些概念。 这些在 PHP 文档中 有描述(http://www.php.net/manual/zh/language.oop5.magic.php)。 PHP 扩展与应用程序库(PEAR) PEAR 是"一个 PHP 可重用代码的框架和发布系统"。PEAR 可以下载、安装、升级 及删除 PHP 脚本。使用 PEAR 包的时候，不用为了脚本的位置或者怎么找到他们 而担心，扩展命令行接口(CLI)也很容易使用。 PEAR 是一个由社区推动的 PHP 项目，官方发布的 PHP 中就包含了 PEAR。 TIP PEAR 网站, http://pear.php.net/, 有 PEAR 文档与分类的 PEAR 包下载。 PEAR 是最专业的安装 PHP 库的方法。建议使用 PEAR 来管理一个由多个项目共用 的 symfony 框架。symfony 的插件(plug-ins)是一种有特殊设置的 PEAR 包。 symfony 本身也可以通过 PEAR 安装。 使用 symfony 并不需要懂 PEAR 命令的语法。你只要知道 PEAR 的用途还有确定它 已经安装好就行了。你可以通过在你的电脑的命令行(CLI)下输入下面的命令来 检查 PEAR 是否安装： > pear info pear 这个命令会返回安装在你的电脑上的 PEAR 的版本。 symfony 项目有自己的 PEAR 仓库(或频道)。仓库功能只有 PEAR 1.4.0 以上版本 才支持，所以如果你的版本比较老就需要升级。升级 PEAR，只要在命令行输入 下面的命令就可以了： > pear upgrade PEAR 对象关系映射(ORM) 数据库是关系型数据库。 PHP5 和 symfony 是面向对象的。 为了用面向对象的 方法访问数据库， 必须用一个接口来表示对象之间的逻辑关系。 这个接口就叫 作对象关系映射（object-relational mapping）或者 ORM。 ORM 是由能够访问数据和存放业务规则的对象组成。 对象/关系抽象层的其中一个优点是可以不用直接去访问数据库。 它会使用经过 优化的模型对象来访问当前的数据库。 这就意味着在项目中期换一套数据库将是很简单的事情。想象一下当你必须为程 序写一个原型的时候，客户并不能确定哪种数据库最适合他们。 你可以先使用 SQLite 来开发程序， 当客户决定使用 MySQL, PostgreSQL 或者 Oracle 的时候， 我们只要在配置文件中稍作修改就可以正常工作了。 抽象层封装了数据逻辑。 其他程序并不需要了解 SQL 的查询语句，却依旧能轻 松的访问数据库。 那些数据库开发专家也很清楚的知道该做些什么。 使用对象而非记录， 用类而非表，还有其他益处： 你能为你的表增加一些新的 存取方法。 例如， 你有一个名叫 Client 的表，有两个字段，分别是 FisrstName 和 LastName， 你也许想直接获得一个完整的姓名。 在面向对象中， 为一个 Client 类添加一个访问方法，就像这样： public function getName() { return $this->getFirstName().' '.$this->getLastName(); } 所有重复数据访问功能和数据的业务逻辑都可以在对象中维护。 例如，有一个 用来生成对象的 ShoppingCart 类。 我们在结帐时想获得一个总价， 你可以加 一个 getTotal() 方法，就像这样： public function getTotal() { $total = 0; foreach ($this->getItems() as $item) { $total += $item->getPrice() * $item->getQuantity(); } return $total; } 就这好了，想象一下要写多长的 SQL 语句才能完成同样的事情！ Propel，另一个开源项目，是 当前最好的基于 PHP5 的对象/关系抽象层。 symfony 框架无缝集成了 Propel， 所以本书大多数的数据处理描述都使用了 Propel 的 语法。 本书将描述如何使用 Propel 对象， 但是更详细的资料可以参考 Propel 的网站(http://propel.phpdb.org/trac/)。 快速应用程序开发 (RAD) 开发网页程序是一件单调乏味的，慢速的事情。 按照常规软件开发生存周期(类 似于 Rational 统一过程里设想的），要等到有完整的需求， 绘制大量的 UML 图， 产生了大量的正式文档之前准备阶段的文档才能开始开发。 这是由于一般 的开发速度，缺少通用性的程序语言（在能正式看到程序可用之前不知道要多少 次的建立，编译，重运行）， 最主要的就是客户不会经常改变他们的主意。 今天，商业节奏更快了，客户总是倾向于在制作项目中经常改变他们的需求。 当 然， 他们期望开发组能接受他们的需求并且快速更改应用程序的架构。 幸运的 是， 使用脚本语言就像 Perl 和 PHP 会更容易的去实现这些，例如快速应用程序 开发（RAD）和敏捷程序开发。 尽快去建立一个工作原型以便客户可以审阅并且提出问题是一个好方法。如此周 而复始，在较短的开发周期发布新的功能。 有很多东西需要开发者考虑。 开发者不需要去想在未来如何实现一个新功能。 用最简单的方法去实现需要的功能。 这就是 KISS 原则的一个很好体现： Keep It Simple, Stupid. 当需求变化或者功能增加的时候， 有时需要重写代码。 这就叫做重构， 这经 常发生在网页应用程序开发中。代码会根据需要改变存放位置。把 重 复的地方合 并到一个地方，这就是 Don't Repeat Yourself (DRY)原则。 当程序改变后要确保依旧能够运行， 这需要一系列的自动测试来完成。 如果写 得好的话， 单元测试将是在重构代码后检查的一个好的方法。 一些开发方法学 （development methodologies ）甚至于规定在编写代码前先写测试--这就使称 之为测试驱动开发(TDD)。 NOTE 关于敏捷开发还有其它一些原则和好习惯。 其中一个最有效率的方法叫做 极限编程（Extreme Programming）（简称 XP），极限编程的教材会教你如何去 快速而有效的去开发一个程序。 推荐从 Kent Beck(Addison-Wesley)的极限编 程系列开始学习。 symfony 非常适合进行 RAD。事实上，制作这个框架的网络公司就使用 RAD 原则 进行他们的项目。这 意味着学习使用 symfony 不是去学习新语言，而是去学习如 何正确的反应和判断从而更有效率的开发应用程序。 symfony 项目的网站有一个步骤详细的教程，完整的介绍了如何快速进行开发。 它叫做 askeet(http://www.symfony-project.com/askeet)，推荐想了解敏捷开 发的朋友阅读这个教程。 YAML 来自 YAML 官方网站 (http://www.yaml.org/) 的定义： YAML 是一种直观的能 够被电脑识别的数据序列化格式，并且它容易被人类阅读，容易与脚本语言交互 的。换种说法，YAML 是一种非常简单的类似于 XML 的数据描述语言，语法比 XML 简单很多。他在描述可以被转化成数组或者 hash 的数据是非常有用，例如： $house = array( 'family' => array( 'name' => 'Doe', 'parents' => array('John', 'Jane'), 'children' => array('Paul', 'Mark', 'Simone') ), 'address' => array( 'number' => 34, 'street' => 'Main Street', 'city' => 'Nowheretown', 'zipcode' => '12345' ) ); 解析这个 YAML 将会自动创建下面的 PHP 数组： house: family: name: Doe parents: - John - Jane children: - Paul - Mark - Simone address: number: 34 street: Main Street city: Nowheretown zipcode: 12345 在 YAML 里面，结构通过缩进来表示，连续的项目通过减号"-"来表示，map 结构 里面的键/值（key/value）对用冒号":"来分隔。YAML 也有用来描述好几行相同 结构的数据的缩写语法，数组用'[]'包括起来，hash 用'{}'来包括。因此，前 面的这个 YAML 可以缩写成这样： house: family: { name: Doe, parents: [John, Jane], children: [Paul, Mark, Simone] } address: { number: 34, street: Main Street, city: Nowheretown, zipcode: 12345 } YAML 是"Yet Another Markup Language(另一种标记语言)"的缩写，读 音 "yamel", 或者"雅梅尔"。这 种 格 式 大 约 是 2001 年出现的，目前为止已经有多种语言的 YAML 解析器。 TIP YAML 格式的详细规格可以在 YAML 官方网站 http://www.yaml.org/找到。 如你所见，写 YAML 要比 XML 快得多(不需要关闭标签或者引号)，并且比'.ini' 文件功能更强(ini 文件不支持层次)。所以 symfony 选择 YAML 作为配置信息的 首选格式。在本书你会看到很多 YAML 文件，不过它很直观你用不着更深入地研 究 YAML。 总结 symfony 是一个 PHP 5 web 应用程序开发框架。他在 PHP 语言的基础上增加了一 个新层，为加速开发复杂的 web 应用程序提供了工具。本书全面介绍 symfony 的使用，你只需要熟悉并且理解现代编程的基本概念 -- 面向对象程序设计 (OOP)、对象关系映射(ORM)还有快速程序开发(RAD)。唯一需要的技术背景是 PHP 5 的知识。 第 2 章 探索 symfony 代码 用 symfony 开发的程序乍看起来有些吓人。它包含很多目录和脚本，有 PHP 类， HTML 甚至两者的混合，程序里面有些类很难找到定义的地方，目录深达 6 层。 不过一旦你了解了这些背后的原因，就会突然发现这其实是很自然的，symfony 程序的结构就应该是这样。读完本章你的这种害怕的想法就会消失。 MVC 模式 symfony 基于 MVC 架构这个经典的 Web 设计模式，MVC 架构包含三层： · 模型(model)代表程序操作的信息--业务逻辑。 · 视图(view)将模型用网页的形式展现出来从而与用户进行交互。 · 控制器(controller)通过调用合适的模型或者视图来回应用户的动作。 图 2-1 解释了 MVC 模式。 MVC 架构把业务逻辑(模型)与展示(视图)分开，从而大大提高了可维护性。例如， 如果你的程序需要能同时在标准 web 浏览器与手持设备上面运行，你只需要一个 新的视图(view)，而无需改变原来的控制器(controller)与模型(model)。控制 器(controller)把请求(request)的协议(HTTP，命令行模式，邮件等)与模型和 视图分开来。模型抽象化逻辑与数据，从而独立于视图与动作(action)，例如， 程序使用的数据库类型。 图 2-1 - MVC 模式 MVC 层次 为了帮助你理解 MVC 的好处，让我们看看如何将一个基本的 PHP 程序转换成一个 MVC 架构的程序。这里我们用一个显示 blog 文章的程序作例子。 单一文件（平面的）编程 从数据库里面显示数据的一般写法跟例 2-1 类似 例 2-1 - 单一文件脚本 List of Posts
这样的代码写起来很快，执行也快，但是几乎没法维护。下面是这种代码的主要 问题： · 没有错误检查(如果数据库连接失败怎么办？) · HTML 与 PHP 代码混合在一起，甚至是在 PHP 代码里输出 HTML 标签。 · 只能适用于 MySQL 数据库。 分离显示 例 2-1 中的'echo'与'printf'使代码难以阅读。如果要修改 HTML 代码来改进外 观的话就需要改动 PHP 代码。因此代码应该分割成两部分。首先，把纯粹的包含 了所有业务逻辑的 PHP 代码放在一个控制器(controller)脚本里，见例 2-2。 例 2-2 - index.php 控制器(controller)部分 HTML 代码，包括一些类似模板的 PHP 语法，存放在一个显示脚本里，见例 2-3。 例 2-3 - view.php 显示部分 List of Posts
按照经验来说视图是否足够干净取决于它是否仅包括最少的 PHP 代码，使 得 没 有 PHP 知识 HTML 设计师能够理解。视图里最常用的语句是 echo, if/endif, foreach/endforeach。另外，不应用 PHP 代码输出 HTML 标签。 所有的逻辑都移到了控制器(controller)脚本，并且仅包含纯 PHP 代码，没有 HTML。事实上，你可以想象同样的控制器可以有完全不同的表现，例如 PDF 文件 或者 XML 结构。 分离数据处理 大部分控制器(controller)脚本代码专注于数据处理。但是假如你需要另一个显 示文章列表的控制器，例如输出 blog 文章的 RSS 种子的控制器呢？如果你想把 所有的数据库查询放在一个地方，避免代码重复呢？如果你决定改变数据模型因 为'post'表名改成了'weblog_post'呢？如果你想把数据库从 MySQL 换成 PostgreSQL 呢？为了让上面这些假设成为现实，你需要把数据处理代码从控制 器里面去掉并把它们放在另外的脚本里面，我们称之为模型，如例 2-4 所示。 例 2-4 - model.php 模型部分 修改过的控制器如例 2-5 所示。 例 2-5 - index.php 修改过的控制器 这样控制器的可读性变强了。它唯一的任务是从模型中取得数据然后传给视图。 在更复杂的程序里，控制器还要处理请求、用户 session、身份验证等。控制器 中使用了直观地函数名使得我们不用注释就能读懂。 模型脚本将专注于数据访问的内容组织在一起。所有与数据层无关的参数(例如 请求参数)必须由控制器提供而不能直接被模型访问到。模型函数可以方便的在 另一个控制器里面重用。 MVC 以外的分离方式 MVC 架构的原理是把代码根据类型分成三层。数据逻辑代码放在模型里，表现代 码放在视图里，应用逻辑代码放在控制器里。 还有其它的设计模式甚至可以使编写代码变得更加容易。模型，视图，控制器层 还可以进一步细分。 数据库抽象 模型层可以分成数据访问层与数据库抽象层。这 样 ，数据访问函数不使用与数据 库有关的查询语句，由其它的函数执行。如果换数据库系统，只需要修改数据库 抽象层。 例 2-6 是 MySQL 的数据库抽象层的例子，随后的例 2-7 是一个简单的数据访问层。 例 2-6 - 模型的数据库抽象层部分 可以看到数据访问层的部分没有数据库引擎有关的函数，从而不依赖于特定的数 据库。另外，建立数据库抽象层的函数可以在很多其它的模型函数中重用。 NOTE 例 2-6 与例 2-7 的例子并不十分让人满意，要完成一个完整的数据库抽象 层还有很多事情要做(通过数据库无关的查询生成器抽象 SQL 代码，把所有的函 数放到一个类，等等)。但是这本书的目的不是手把手教你怎么写一个数据库抽 象层，在第 8 章里你会看到 symfony 本身是如何把这些抽象做好的。 视图元素 视图层也可以通过分离代码来优化。应用程序中的网页往往会包含一些固定的元 素：页头，图形版面设计，页脚以及全局导航。只有网页的中间部分变化。所以 我们把视图分成布局(layout)与模板。布局(layout)一般是整个程序通用的，或 者一组页面公用。模 板只负责把控制器的变量显示出来。我们需要一些逻辑使这 些零件(components)和在一起能够起作用，这就是视图逻辑。根据这些原则，例 2-3 的视图部分可以分成 3 部分，如例 2-8,2-9,2-10 所示。 例 2-8 - mytemplate.php 视图的模板部分
例 2-9 - 视图的视图逻辑部分 例 2-10 - 视图的布局部分 <?php echo $title ?> 动作与前端控制器 在上一个例子里，控制器(controller)并没有作太多事情，但是在真正的 web 应用程序里面，控制器要做很多事情。这些事情中的一些重要部分对于所有的控 制器都要做。这些事情包括处理请求、安全处理、载入应用程序配置信息，以及 一些杂事。所以控制器经常被分成整个应用程序唯一的前端控制器和只负责某个 特定页面的动作。 前端控制器的一个很大的好处就是整个应用程序唯一的入口。如果你决定关闭应 用程序，你只要修改前端控制器脚本。如果一个应用程序没有前端控制器，那就 要单独的关掉每一个控制器。 面向对象 所有前面的例子都是面向过程的。现代编程语言的面向对象特性能简化编程，因 为 对 象 可以封装逻辑，继承，以及提供干净的命名规则。 在非面向对象的语言里面实现 MVC 架构会引起命名空间及代码重复的问题，代码 会比较难以阅读。 开发者通过面向对象的方式可以通过视图对象，控制器对象，模 型 对 象 把之前例 子里面的函数转换成方法。这是 MVC 架构必须的。 TIP 如果你想更详细的了解面向对象环境中的 web 应用程序设计模式，请阅读 《Patterns of Enterprise Application Architecture》(作者:Martin Fowler, 出版 Addison-Wesley, ISBN: 0-32112-742-0)。这本书里面的代码用 Java 或者 C#写的，PHP 开发者也可以读一读。 symfony 的 MVC 实现方式 暂停一下，先来看看一个显示 blog 文章列表的页面，有多少部分组成？如图 2-2 所示，由下面的部分组成： · 模型层 o 数据库抽象 o 数据访问 · 视图层 o 视图 o 模板 o 布局 · 控制器层 o 前端控制器 o 动作 7 个脚本--每次修改一个页面需要打开这么多文件！可是，symfony 做了些简化。 虽然使用最好的 MVC 架构，但是 symfony 的方式使得开发程序更加快速容易。 首先，前端控制器是应用程序里所有动作共用的。可以有多个控制器与多个布局， 但是只需要一个前端控制器。前端控制器是纯 MVC 逻辑组件，你不必自己写一个， 因为 symfony 会为你生成一个。 另外一个好消息是模型层的类也是根据数据结构自动生成的。这是由 Propel 库 完成的，它有类的构架与代码生成功能。如果 Propel 找到外键或者日期字段， 它会生成特殊的存取方法，这使得数据处理非常容易。另外，数据库抽象也是完 全看不见的，它是由另外一个 Creole 组件处理的。所以如果你决定更换数据库 引擎，你不必重写代码。你只要修改配置参数就可以了。 最后一件事情，视图逻辑可以很容易的转换成一个配置文件，不需要编写程序。 图 2-2 - symfony 工作流程 这就是说在 symfony 里面显示文章的例子需要 3 个文件，如例 2-11，2-12，2-13 所示。 例 2-11 - list 动作, myproject/apps/myapp/modules/weblog/actions/actions.class.php posts = PostPeer::doSelect(new Criteria()); } } ?> 例 2-12 - list 模板, myproject/apps/myapp/modules/weblog/templates/listSuccess.php
例 2-13 - list 视图, myproject/apps/myapp/modules/weblog/config/view.yml listSuccess: metas: { title: List of Posts } 另外，你需要定义一个布局，如例 2-14，但是它可以多次重用。 例 2-14 - 布局 myproject/apps/myapp/templates/layout.php getRaw('sf_content') ?> 这些就是全部的了。你只需要这些代码来显示与例 2-1 完全一样的页面。余下的 事情(使所有的组成部分共同工作)由 symfony 来处理。如果你计算行数，会发现 用MVC架构的symfony 来实现显示文章列表花的时间和编写的代码不比写一个普 通脚本要多。不过，这样做的巨大好处是，代码组织得十分清楚，可重用，灵活 性还有更多的乐趣。作为奖励，你会得到 XHTML 兼容性，调试能力，简单的配置， 数据库抽象，智能 URL 定向，多种环境，还有很多开发工具。 symfony 核心类 在本书里你会经常碰到 symfony 的 MVC 核心的几个类： · sfController 控制器类。它解析请求并交给动作处理。 · sfRequest 保存所有的请求元素(参数，cookie，请求的头 等)。 · sfResponse 包含回应的头和内容。它的内容最终会转化为 HTML 传给用 户。 · context singleton (由 sfContext::getInstance()取得) 保存所有核心 对象还有当前的配置的引用，它可以从任何地方访问到。 在第 6 章你会了解到更多这些对象的信息。 如你所见，所有的 symfon 类都有一个 sf 前缀，很多 symfony 模板中的核心变量 也是这样。这 样 可以避免与你的类名与变量名重复，并使框架核心类更像是一家 人，更好辨认。 NOTE 在 symfony 的编码规范中，开头字母大写的驼峰字(UpperCamelCase)是变 量名与类名的标准。只有两个例外：核心 symfony 类以小写的 sf 开头,模板里面 的变量使用小写下划线的方式。 代码组织 现在你了解了 symfony 应用程序的各个组成部分，你可能会想知道它们是怎么组 织的。symfon 按照项目组织代码，项目文件放在标准的树结构里。 项目结构: 应用程序、模块与动作 一个 symfony 项目由一个域名下的服务与操作组成，它们共享同样的对象模型。 在一个项目里，操作按照逻辑划分成不同的应用程序。同一个项目里面的不同应 用程序相互独立。大多数情况，一个项目会包含两个应用程序:一个是前台，一 个后台，它们共享同一个数据库。不过一个项目也可以包含很多小网站，每一个 站点是一个不同的应用程序。注意应用程序间的链接必须用绝对形式。 每个应用程序由一个或更多模块组成。模 块 就 是功能相近的一个页面或者一组页 面。例如，模块 home ,articles, help, shoppingCart, account 等。 模块包含动作，也就是说一个模块可以包含多个动作。例如，shoppingCart 模 块也许会有 add,show 与 update 等动作。一般来说，动作的名字是动词。动作就 好像一般的 web 应用程序的页面一样，尽管两个动作可能显示同样的页面(例如， 在给文章留言后还会把文章显示出来)。 TIP 如果你认为这么做对于一个刚开始的项目来说层次太多了，你可以很方便的 把所有的动作集中到一个模块里，这 样文件结构就简单了。当应用程序越来越复 杂，你就需要把这些动作分开放到不同的模块。本书第 1 章提到，通过重写代码 来改善结构与可读性(同样保留功能)被称为重构，当你应用 RAD 原则的时候经常 需要这么做。 图 2-3 是一个 blog 项目的代码组织结构图，按照项目/应用程序/模块/动作来 划分。 但注意项目的实际文件结构可能会与图里面的不一样。 图 2-3 - 代码组织结构例子 目录结构 所有的 web 项目都有这些内容: · 一个数据库，例如 MySQL 或者 PostgreSQL · 静态文件(HTML, 图片， JavaScript 文件，样式表等) · 网站管理员与用户上传的文件 · PHP 类与函数库 · 外部库(第三方脚本) · 批处理文件 (用于命令行或者 cron 的脚本) · 日志文件 (应用程序或者服务器的留下的脚印) · 配置文件 symfony 用一种合理的目录结构组织所有这些内容，这种树形结与 symfony 的架 构(MVC 模式与应用程序/项目/模块分组)相符合。这个目录结构是在项目，应用 程序，模块初始化的时候自动生成的。当然，为了满足客户的需求你可以完全自 定义这个结构。 根目录结构 下面是一个 symfony 项目根目录下的文件： apps/ frontend/ backend/ batch/ cache/ config/ data/ sql/ doc/ lib/ model/ log/ plugins/ test/ unit/ functional/ web/ css/ images/ js/ uploads/ 表 2-1 介绍了这些目录的内容。 表 2-1 - 根目录 目录 描述 apps/ 包含此项目内所有应用程序(一般情况, frontend 与 backend 分别代 表前台与后台)。 batch/ 包含命令行下运行的 PHP 脚本或者定期执行的脚本。 cache/ 包含了配置文件的缓存，如果你开了动作和模板，还有这两个部分的 缓存。缓存机制(详见第 12 章)把这些信息存在文件里面加快响应 web 请求的速度。每个应用程序都会有一个子目录，包含了预处理的 PHP 与 HTML 文件。 config/ 存放项目的配置信息。 data/ 这里可以存放项目的数据文件，例如数据库 schema，包含了建立数据 表的 SQL 文件，或者一个 SQLite 数据库文件。 doc/ 存放项目文档，包括你自己的文档和 PHPdoc 生成的文档。 lib/ 主要用来存放外部类或者库。这 里 的 内 容整个项目都能访问到。model/ 子目录存放项目的对象模型(详见第 8 章)。 log/ 存放 symfony 生成的应用程序的日志文件。也可以放 web 服务器的日 志文件，数据库日志文件，或者项目的任何地方的日志文件。symfony 自动为项目的每一个应用程序的每一个环境生成一个日志文件(日志 文件详见第 16 章)。 plugins/ 存放安装在项目里的插件(插件详见第 17 章)。 test/ 包含 PHP 写的与 symfony 测试框架兼容的单元与功能测试(详见第 15 章)。 项目初始化的时候，symfony 会自动建立一些基本的测试。 web/ web 服务器的根目录。所有从因特网能够直接访问的文件都在这个目录 里。 应用程序目录结构 所有应用程序的目录结构都是一样的： apps/ [应用程序名]/ config/ i18n/ lib/ modules/ templates/ layout.php error.php error.txt 表 2-2 介绍了应用程序的子目录。 表 2-2 - 应用程序的子目录 目录 描述 config/ 包含一些 YAML 格式的配置文件。大部分应用程序的配置信息都在这 里，symfony 框架自己的默认配置除外。 注意需要的话默认值可以 修改。详见第 5 章。 i18n/ 包含应用程序的国际化文件--大部分的界面翻译文件(详见第 13 章)。如果你用数据库存放翻译信息可以忽略这个目录。 lib/ 包含应用程序用到的类与库。 modules/ 存放应用程序的所有功能模块。 templates/ 包含应用程序的全局模板--所有模块公用的模板。默认情况，这个 目录会有一个 layout.php 文件，这是模块默认的主布局模板。 NOTE 新应用程序的 i18n/, lib/, 与 modules/ 目录是空的。 一个应用程序的类的方法或属性不能被同一个项目的其他应用程序访问到。另 外，同一项目的两个应用程序之间的超链接必须用绝对形式。开 始 把 项目分成不 同的应用程序的时候，这个限制就存在了。 模块目录结构 每个应用程序包括一个或更多的模块。在 modules 目录中每个模块都有它自己的 子目录，这个目录的名字是模块初始化的时候确定的。 下面是一个典型的模块目录结构： apps/ [应用程序名]/ modules/ [模块名]/ actions/ actions.class.php config/ lib/ templates/ indexSuccess.php validate/ 表 2-3 介绍了模块子目录结构。 表 2-3 - 模块子目录 目录 描述 actions/ 一般只有一个文件 actions.class.php，这个文件里面包含了模块的 所有动作。模块的不同动作也可以分开写在不同的文件里。 config/ 可以存放模块的配置信息。 lib/ 存放模块的类与库。 templates/ 存放模块里所有动作的模板。模块初始化的时候，会建立一个默认 模板 indexSuccess.php。 validate/ 用户存放表单验证配置信息(详见第 10 章)。 NOTE 新模块的 config/, lib/, 与 validate/ 目录是空的。 web 目录结构 web 目录的限制很少，这里存放的是互联网可以访问得到的文件。模板的默认行 为还有 helper 里包含了几个基本的命名规则。下面是一个 web 目录的结构的例 子： web/ css/ images/ js/ uploads/ 表 2-4 介绍了 web 目录的内容。 表 2-4 - 典型的 web 目录的子目录 目录 描述 css/ 存放.css 结尾的样式表文件。 images/ 存放.jpg、.png 与.gif 扩展名的图片文件。 目录 描述 js/ 存放.js 扩展名的 JavaScript 文件。 uploads/ 只能存放用户上传的文件。虽然这个目录通常会存放图片我们还是把 这个目录与图片目录分开，这样同步开发服务器与正式服务器的时候 不会影响上传的文件。 NOTE 虽然强烈建议维持默认的目录结构，但是你还是可以进行修改，例如一个 项目要运行在不同的目录结构与命名规则的服务器上。修改目录结构详见第 19 章。 常用工具 有些技巧在 symfony 里面很常用，在项目中你会经常碰到他们。这 包括参数存储 器，常量，还有类自动加载。 参数存储器 很多 symfony 类都包含一个参数存储器。参数存储器用简便的方式封装了获取方 法与设置方法。例如，sfResponse 类包含了一个可以通过执行 getParameterHolder()方法获得参数存储器。每一个参数存储器都用同样的方式 存取数据，如例 2-15 所示。 例 2-15 - 使用 sfResponse 参数存储器 $response->getParameterHolder()->set('foo', 'bar'); echo $response->getParameterHolder()->get('foo'); => 'bar' 大部分类通过使用参数存储器的 proxy 方法来减少 get/set 操作的代码量。下面 是 sfResponse 对象的例子，例 2-16 可以达到例 2-15 同样效果。 例 2-16 - 使用参数存储器的 proxy 方法 $response->setParameter('foo', 'bar'); echo $response->getParameter('foo'); => 'bar' 参数存储器的 getter 方法可以有第二个参数作为默认值。这样在取值失败的时 候比较简洁。见例 2-17。 例 2-17 - 使用参数存储器的 get 方法的默认值 // 'foobar' 参数没有定义, 所以 getter 返回空值 echo $response->getParameter('foobar'); => null // 利用条件判断给一个默认值 if ($response->hasParameter('foobar')) { echo $response->getParameter('foobar'); } else { echo 'default'; } => default // 但是使用第二个默认值参数要快的多 echo $response->getParameter('foobar', 'default'); => default 参数存储器还支持命名空间。如果你给设置方法或者获取方法指定第三个参数， 这个参数代表命名空间，那么这个参数就只会在这个命名空间里定义或者取值。 见例 2-18 例 2-18 - sfResponse 参数存储器的命名空间 $response->setParameter('foo', 'bar1'); $response->setParameter('foo', 'bar2', 'my/name/space'); echo $response->getParameter('foo'); => 'bar1' echo $response->getParameter('foo', null, 'my/name/space'); => 'bar2' 当然，你还可以给你自己的类增加参数存储器来获得这些好处。例 2-19 告诉我 们如何定义一个有参数存储器的类。 例 2-19 - 给类增加参数存储器 class MyClass { protected $parameter_holder = null; public function initialize ($parameters = array()) { $this->parameter_holder = new sfParameterHolder(); $this->parameter_holder->add($parameters); } public function getParameterHolder() { return $this->parameter_holder; } } 常量 symfony 里的常量少得出奇。这是因为 PHP 的一大缺点：常量定义后就不能改变 了。所以 symfony 使用自己的配置对象，称作 sfConfig，用来取代常量。它提 供了在任何地方存取参数的静态方法。例 2-20 演示了 sfConfig 类的方法。 例 2-20 - 使用 sfConfig 类方法取代常量 // PHP 常量 define('SF_FOO', 'bar'); echo SF_FOO; // symfony 使用 sfConfig 对象 sfConfig::set('sf_foo', 'bar'); echo sfConfig::get('sf_foo'); sfConfig 方法支持默认值，并且 sfConfig::set()方法可以多次调用来设置同一 个参数的值。第 5 章详细讨论了 sfConfig 方法。 类自动载入 一般来说，当你在 PHP 中要用一个类来创建一个对象的时候，你需要首先包含这 个类的定义。 include 'classes/MyClass.php'; $myObject = new MyClass(); 但是大的项目包含了很深的目录结构，包含所有这些文件还有路径很浪费时间。 由于有__autoload()函数(或者 spl_autoload_register()函数)，symfony 使得 我们不需要写包含语句，你可以直接这么写： $myObject = new MyClass(); symfony 会在项目的 lib 目录里的所有 php 文件里寻找 MyClass 的定义。如果找 到，就自动包含它。 所以你可以把所有的类放在 lib 目录，你再也不必包含他们。所以 symfony 项目 通常没有 include 或者 require 语句。 NOTE 为了提高效率，第一次 symfony 自动在一个目录列表(在配置文件里面定义) 里寻找。然后 symfony 把这些目录里的所有类和文件的关联存放在一个 PHP 数组 里。这样，以后的自动载入就不需要扫描整个目录了。所以你每次在项目里面增 加一个类都需要通过 symfony clear-cache 命令清空 symfony 缓存。缓存详见第 12 章，自动载入配置文件详见第 19 章。 总结 使用 MVC 框架迫使你按照框架的规定把代码分开。显示的代码归到视图里，数据 处理的代码归到模型，请求处理逻辑归到控制器。这 对 MVC 模式的应用程序很有 用，也是一个约束。 symfony 是一个 PHP5 写的 MVC 框架。它的结构充分发挥了 MVC 模式的好处，但 也非常容易使用。这要感谢他的全面性与可配置性。 现在你已经了解了 symfony 背后的原理，差不多该是开发你的第一个应用程序的 时候了。但是在这之前，你需要在你的开发服务器上安装一套 symfony 并运行起 来。 第 3 章 运行 symfony 如上章所述，symfony 是由许多 PHP 文件组成的框架。 symfony 的项目需要使 用这些文件，所以安装 symfony 其实就是让项目中可以使用这些文件。 symfony 是基于 PHP5 的框架。所以用以下命令确认你安装了正确的 PHP 版本： > php -v PHP 5.2.0 (cli) (built: Nov 2 2006 11:57:36) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies 如果版本号大于 5.0，你就可以开始安装了，安装过程将在此章节介绍。 安装沙盒(Sandbox) 如果你只是想要快速安装，试用一下 symfony，你应该使用沙盒。 沙盒里有一个空的 symfony 项目,这个项目包括基本的配置，一个默认的应用程 序，还有 symfony 所需要的库(symfony、pake、lime、Creole、Propel 和 Phing)。 它可以独立运行，不需要特别的服务器配置。 沙盒可以从 http://www.symfony-project.com/get/sf_sandbox.tgz 下载。解 压缩到 web 服务器的根目录中 (通常是 web/ 或者 www/)。 为了统一性， 本 章将假设你把它解压到 sf_sandbox 目录下。 NOTE 把所有的文件放在 web 根目录下对于测试没有什么问题，不 过在正式服务器上这么作是一个坏习惯。这样会把所有程序的内 部文件暴露给最终用户。 执行 symfony 命令来测试安装是否成功。 在 sf_sandbox/目录下，输入以下命 令： Linux 系统下： > ./symfony -V Windows 系统下： > symfony -V 你会看到沙盒的版本号： symfony version 1.0.0 现在请确认你的 web 服务器可以从下面的地址来访问沙盒： http://localhost/sf_sandbox/web/frontend_dev.php/ 如果你看到一个类似图 3-1 一样的成功页面，这就意味着安装已经完成。 如 果没看到， 将会有一个错误信息告诉你如何去修改配置文件。 你也可以参考 下面的"安装问题"章节。 图 3-1 - 沙盒的祝贺页面 沙盒是用来给你在自己的电脑上面练习的，并不适合开发复杂的应用程序。不 过，沙盒里的 symfony 的功能是完整的，与通过 PEAR 安装的没有差别。 要卸载沙盒，只要把 web/目录下的 sf_sandbox/删除即可。 安装 symfony 库 开发程序的时候， 你也许会安装 symfony 两次： 一次是你的开发环境，另外 一次是在服务器上(除非服务器上已经安装过 symfony)。对于每台服务器而 言，为了避免重复你也许会把所有的 symfony 文件放在一个地方，不管你开发 几个程序。 因为 symfony 框架更新的很快，一个新的稳定版本可能在你安装后的几天内就 发布了。 所以你需要认真考虑 symfony 框架更新的问题，这也是另外一个所有 的项目应该共用同一个 symfony 的理由。 当要在真正程序开发中安装库的时候,你有 2 个选择： · 对大多数人而言推荐用 PEAR 安装方式。 他很容易共享和升级，安装过 程直接了当。 · Subversion (SVN) 安装模式通常是高级 PHP 程序开发者使用的， 可以 获得最新的补丁，增加自己开发的功能，发布 symfony 的项目。 symfony 集成了一些其他的包： · pake 是一个命令行工具。 · lime 是单元测试工具。 · Creole 是数据库抽象引擎。类似于 PHP 数据对象 (PDO)，他提供了程序 代码与 SQL 数据库代码之间的一个接口，以便切换到其他数据库。 · Propel 是 ORM 工具。它提供持续对象与查询服务。 · Phing 是 Propel 的命令行接口。 Pake 和 lime 是 symfony 小组开发的。Creole、Propel 和 Phing 是由其他小组 开发并置于 GNU Lesser Public General License (LGPL)协议下。所有这些包 都绑定在 symfony 中。 Pear 方式安装 symfony symfony 的 PEAR 包包含了 symfony 库。它也包含一个将 symfony 命令加入你的 命令行的脚本。 安装第一步是把 symfony 频道加入 PEAR，执行以下命令： > pear channel-discover pear.symfony-project.com 用以下命令查看这个频道中的可用库列表： > pear remote-list -c symfony 现在可以安装稳定版本的 symfony 了。 执行以下命令： > pear install symfony/symfony downloading symfony-1.0.0.tgz ... Starting to download symfony-1.0.0.tgz (1,283,270 bytes) ................................................................. ................................................................. .............done: 1,283,270 bytes install ok: channel://pear.symfony-project.com/symfony-1.0.0 symfony 文件和命令行工具已经安装好了。在命令行执行 symfony 来确认安装 是否成功， 查看版本号： > symfony -V symfony version 1.0.0 TIP 如果要安装最新的 beta 版本， 用命令 pear install symfony/symfony-beta 来安装。 Beta 版本通常是不稳定的，不 推荐在生产环境中用。 symfony 库安装在以下的目录中： · $php_dir/symfony/ 存放主要库文件。 · $data_dir/symfony/ 存放 symfony 程序的结构；默认的模块；配置文 件，i18n 数据，和其他。 · $doc_dir/symfony/ 存放文档。 · $test_dir/symfony/ 存放单元测试。 _dir 结尾的变量是 PEAR 配置的一部分，可以用以下命令查看它的值： > pear config-show 从 SVN 库中获得 对于生产服务器， 或者不能从 PEAR 安装的时候， 你可以直接从 symfony 的 subversion 库里通过捡出最新版的 symfony： > mkdir /path/to/symfony > cd /path/to/symfony > svn checkout http://svn.symfony-project.com/tags/RELEASE_1_0_0/ . 命令 symfony，只有在用 PEAR 安装时候才有效，实际上是调用了 /path/to/symfony/data/bin/symfony 脚本。 所以 SVN 安装模式需就用下面的 命令查看版本： > php /path/to/symfony/data/bin/symfony -V symfony version 1.0.0 如果选择用 SVN 安装方式，你也许已经有了一个 symfony 项目。你需要在你的 项目中更改两个变量使其可以找到 symfony 文件： mkdir ~/myproject > cd ~/myproject > symfony init-project myproject SVN 安装方式，用以下命令建立项目： > mkdir ~/myproject > cd ~/myproject > php /path/to/symfony/data/bin/symfony init-project myproject symfony 命令只能在项目的根目录下使用(前面提到的例子 myproject/)，因为 用这个命令所作的事情都是基于项目的。 symfony 会建立一个下面这样的目录结构： apps/ batch/ cache/ config/ data/ doc/ lib/ log/ plugins/ test/ web/ TIP init-project 在项目根目录中增加一个 symfony 脚本。这个 PHP 脚本和用 PEAR 安装的 symfony 命令做的一样，所以没有原生 命令行(SVN 安装方式)支持的话你可以用 php symfony 来替代 symfony。 建立一个应用程序 项目现在还没法用，因为他还至少需要一个应用程序。用 symfony init-app 命 令传送一个应用程序的名字作为一个参数去初始化它： > symfony init-app myapp 这将在项目根的 apps/目录下建立一个叫 myapp/的目录，它包含了一个默认的 应用程序配置和一系列的子目录： apps/ myapp/ config/ i18n/ lib/ modules/ templates/ 在项目 web 目录里还会建立这个应用程序的两个默认环境对应的前端控制器的 PHP 文件： web/ index.php myapp_dev.php index.php 是新建应用程序的生产环境前端控制器。 因为当你在项目中创建了 第一个应用程序的时候，symfony 建立一个叫 index.php 的文件来代替 myapp.php (如果你现在增加一个新的应用程序 mynewapp， 新的生产环境前台 会是 mynewapp.php)。 要在开发环境中呼叫前端控制器 myapp_dev.php 来运行 你的应用程序，你会在第 5 章了解更多关于环境的知识。 配置 Web 服务器 web/目录下的这些脚本是应用程序的入口。 Web 服务器要先配置才能在 Internet 中被访问。在开发服务器中，与专业主机服务解决方案一样，也需要 访问 Apache 配置文件去设置一个虚拟主机。 在一个共享的服务器中，你也许 只能修改.htaccess 文件。 设置虚拟主机 例 3-1 是一个 Apache 配置的示例，可以了解如何在 httpd.conf 中添加新的虚 拟主机。 例 3-1 - Apache 配置示例，apache/conf/httpd.conf ServerName myapp.example.com DocumentRoot "/home/steve/myproject/web" DirectoryIndex index.php Alias /sf /$sf_symfony_data_dir/web/sf AllowOverride All Allow from All AllowOverride All Allow from All 在例 3-1 配置中，需要用真实的路径替换掉/path/to/symfony/data。 例如， 在*nix 中用 PEAR 安装的话，你要输入类似这样的配置行： Alias /sf /usr/local/lib/php/data/symfony/web/sf NOTE 给 web/sf/设置别名并非是强制的。 这可以让 Apache 找到 网页 debug 工具条所用的图片，样式表和 JavaScript 文件， 管 理界面生成器， symfony 的默认页面还有 Ajax 支持。另外一个 设置别名的方法是建立一个符号连接(symlink)或者把 /path/to/symfony/data/web/sf/复制到 myproject/web/sf/中。 重启 Apache。 你新建立的应用程序现在能用以下的 URL 来访问： http://localhost/myapp_dev.php/ 你可以看到一个类似先前图 3-1 的成功页面。 SIDEBAR URL 重写 symfony 用 URL 重写来显示"漂亮的 URL"--有意义的地址对搜索引 擎更友好并且对使用者隐藏了所有的数据。你会在第 9 章学习更 多这方面的知识--路由(routing)。 如果你的 Apache 编译的时候没有选择 mod_rewrite 模块，检查 httpd.conf 中是否包含了 mod_rewrite 动态共享对象(DSO)。 AddModule mod_rewrite.c LoadModule rewrite_module modules/mod_rewrite.so 对于 Internet 信息服务(IIS)，你需要安装和运行 isapi/rewrite。 symfony 在线手册有关于 IIS 安装的详细指 导。 配置一个共享服务器 在共享服务器上配置一个应用程序有一些麻烦，因为服务器通常有你无法改变 的特殊目录结构。 CAUTION 直接在共享服务器上测试和开发并不是一个好的做法。 一个原因是因为这会让应用程序在未完成的时候可以被访问到， 泄露其内部信息将会带来很大的安全隐患。另一个原因是,共享主 机的性能往往不能满足开启调试工具时快速浏览应用程序的需 要。因此你不应在共享服务器上开始你的开发，而应该在本地建 立你的应用程序，完成后再移植到共享服务其上。第 16 章将告诉 你移植技术和工具。 我们假设你的共享服务器需要把网页目录命名为 www/来取代 web/，并且不允许 你修改 httpd.conf 而只允许你修改在网页目录中的.htaccess 文件。 在一个 symfony 项目中，每一个目录路径都是可配置的。第 19 章将带给你更多 的信息，但是与此同时，你可以把 web 目录改为 www 目录，并且修改应用程序 的配置，就如例 3-2 所示。这些将在应用程序的 config.php 文件底部加上。 例 3-2 - 在 apps/myapp/config/config.php 修改默认目录结构设定 $sf_root_dir = sfConfig::get('sf_root_dir'); sfConfig::add(array( 'sf_web_dir_name' => $sf_web_dir_name = 'www', 'sf_web_dir' => $sf_root_dir.DIRECTORY_SEPARATOR.$sf_web_dir_name, 'sf_upload_dir' => $sf_root_dir.DIRECTORY_SEPARATOR.$sf_web_dir_name.DIRECTORY_SEPARATOR .sfConfig::get('sf_upload_dir_name'), )); 项目的网页根目录默认包含了一个 .htaccess 文件。 就如例 3-3 所示。适当 的修改它以配合你的共享服务器的需求。 例 3-3 - 默认的 .htaccess 配置，当前在 myproject/www/.htaccess Options +FollowSymLinks +ExecCGI RewriteEngine On # we skip all files with .something RewriteCond %{REQUEST_URI} \..+$ RewriteCond %{REQUEST_URI} !\.html$ RewriteRule .* - [L] # we check if the .html version is here (caching) RewriteRule ^$ index.html [QSA] RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{REQUEST_FILENAME} !-f # no, so we redirect to our front web controller RewriteRule ^(.*)$ index.php [QSA,L] # big crash from our front web controller ErrorDocument 500 " > svn propedit svn:ignore log > svn propedit svn:ignore cache 现在只要把 myproject/子目录的所有文件都添加到 SVN 中，SVN 会在提交的时 候忽略掉列表中的文件： * 保存，退出。完成了。 总结 如果在本地服务器上想测试或者尝试一下 symfony，最好安装一个已经预配置 好环境的沙盒。 如果是真正的开发或者在生产服务器上，最好使用 PEAR 安装或者用 SVN 捡出。 这样做会安装 symfony 的库，还需要初始化一个项目和应用程序。应用程序设 置的最后一步是服务器配置，这有很多种做法。symfony 能完美地在虚拟主机 下运行，这也是推荐的解决方案。 如果在安装中遇到问题， 你能从 symnfony 网站上找到许多教程、回答、FAQ。 如果需要，你可以把问题提交到 symfony 社区，这样会很快得到答案。 当项目初始化好后， 开始版本控制流程是一个好习惯。 现在你已经准备好使用 symfony 了，是时候去建立一个基础的网页程序了。 第 4 章 建立页面的基础知识 很奇怪，每次学习新语言或者框架的第一个例子都是在屏幕上显示"Hello, world!"。目前为止所有利用人工智能来实现交谈的尝试的结果都很差，所以电 脑能问候整个世界这种想法实在有些古怪。但是 symfony 并不比其他程序笨，证 据是，你可以用 symfony 创建一个说"Hello, <你的名字>"的页面。 本章会告诉你如何创建一个模块，也就是一组页面的集合体。你还将了解到如何 建立一个页面，由于 MVC，页面由一个动作和一个模板构成。链接和表单是 web 交互的基础，你将在这一章了解如何在模板里增加他们，如何用动作处理他们。 建立模块框架 在第二章中我们介绍过，symfony 把页面组织成模块。建立页面之前，你必须先 建立一个模块，也就是一个 symfony 能识别的目录结构的一个空壳。 symfony 命令行工具能自动建立模块。你只需要用 symfony 命令行工具执行 init-module 任务并传应用程序名与模块名这两个参数给它就可以了。在前一章 里，你建立了 myapp 应用程序。如果要在这个应用程序里增加一个 mymodule 模 块，只需要在命令行下输入下面的命令： > cd ~/myproject > symfony init-module myapp mymodule >> dir+ ~/myproject/apps/myapp/modules/mymodule >> dir+ ~/myproject/apps/myapp/modules/mymodule/actions >> file+ ~/myproject/apps/myapp/modules/mymodule/actions/actions.class.php >> dir+ ~/myproject/apps/myapp/modules/mymodule/config >> dir+ ~/myproject/apps/myapp/modules/mymodule/lib >> dir+ ~/myproject/apps/myapp/modules/mymodule/templates >> file+ ~/myproject/apps/myapp/modules/mymodule/templates/indexSuccess.php >> dir+ ~/myproject/apps/myapp/modules/mymodule/validate >> file+ ~/myproject/test/functional/myapp/mymoduleActionsTest.php >> tokens ~/myproject/test/functional/myapp/mymoduleActionsTest.php >> tokens ~/myproject/apps/myapp/modules/mymodule/actions/actions.class.php >> tokens ~/myproject/apps/myapp/modules/mymodule/templates/indexSuccess.php 除了 actions/, config/, lib/, templates/, 与 validate/目录，这条命令只 建立了三个文件。test/目录里的文件与单元测试有关，在第 15 章之前你都不用 管它。actions.class.php(见例 4-1)做了一个到默认模块的成功页面的跳转。 templates/indexSuccess.php 文件是空的。 例 4-1 - 默认的自动生成的动作 actions/actions.class.php forward('default', 'module'); } } NOTE 如果你看一下实际的 actions.class.php 文件，你会注意到除了上面的这 几行之外还有其他的内容，包括一些注释。这是因为 symfony 推荐使用 PHP 注释 来为你的项目生成文档，所以每个类文件都与 phpDocumentor 工具 (http://www.phpdoc.org/)兼容。 symfony 为每一个新模块建立一个 index 动作。它是由一个 execueIndex 的方法 与一个叫 indexSuccess.php 的模板组成的。execute 前缀与 Success 后缀的含 义会在第 6 章与第 7 章中分别解释。现在你可以认为这是一种命名习惯。在浏览 器中输入下面的网址就可以看到这个页面(图 4-1)： http://localhost/myapp_dev.php/mymodule/index 本章不会用到这个默认的 index 动作,所以你可以把 executeIndex()方法从 actions.clas.hpp 文件中去掉，并把 indexSuccess.php 文件从 templates/目录 中删除。 NOTE 除了命令行，symfony 还提供了其他的建立模块的方法。其中之一是你自 己来建立这些文件与目录。很多时候，模 块 中 的动作和模板用来处理一个表里面 的数据。由于建立、获取、更新与删除所需的代码往往是一样的，symfony 提供 一种称之为脚手架(scaffolding)的机制来自动生成一个模块。这种技术详见第 14 章。 图 4-1 - 自动生成的默认 index 页 增加一个页面 symfony 里面，页面背后的逻辑放在动作里面，表现放在模板里。不需要逻辑的 页面也需要一个空的动作。 增加一个动作 我们需要一个通过 myAction 动作来访问"Hello, world!"的页面。要建立这个页 面，只要在 mymyduleActions 类里面增加一个 executeMyAction 方法，如例 4-2。 例 4-2 - 增加一个动作就是给动作类增加一个执行方法 Hello, world! 如果需要在模板里执行一些 PHP 代码，你应该避免使用通常的 PHP 语法(如例 4-4)。相反，你应该在模板里面使用特殊的 PHP 语法，如例 4-5 所示，这样不是 PHP 程序员的人也能理解。这样不仅最终生成的代码的缩进格式正确，而且可以 让你把复杂的代码放在动作里面，因为只有控制语句(if,foreach,while 等)有 特殊语法。 例 4-4 - 通常的 PHP 语法，对于动作没问题，对于模板就很糟糕
List of Posts
| Date | Title | %s | \n", $row['date']); printf("\t\t%s | \n", $row['title']); echo "\t\n"; } ?>
|---|
List of Posts
| Date | Title |
|---|---|
List of Posts
| Date | Title |
|---|---|
List of Posts
| Date | Title |
|---|---|
| getDate() ?> | getTitle() ?> |
Application error
symfony applicationfailed to start properly" 现在可以访问你的应用程序了。你可以通过这个 URL 访问 symfony 成功页面： http://www.example.com/myapp_dev.php/ SIDEBAR 其他服务器配置 symfony 和其他服务器配置兼容。例如，你可以用 alias 代替虚 拟主机来访问 symfony 程序。 你也能在 IIS 上运行 symfony 程 序。关于配置有很多技巧， 本书并不准备解释所有的技巧。 想要找到具体的服务器配置指南，可以参考 symfony 的 wiki (http://www.symfony-project.com/trac/wiki)，这里有详尽的 指导。 安装问题 这些通常会有错误说明，甚至会提供网络上针对此问题的资源连接。如果在安 装中遇到问题，尽量把错误或例外显示在 shell 或者浏览器上。 常见问题 如果你还是无法运行 symfony，检查以下几点： · 一些 PHP 环境同时包含了 PHP4 和 PHP5 的命令。 因此，在命令行用 php5 替代 php， 也就是说试着用 php5 symfony 代替 symfony。你也许 在.htaccess 配置中需要增加 SetEnv PHP_VER 5 参数，或者把 web/目录 中的.php 换成.php5。在 PHP4 命令行下试着访问 symfony 就会有类似下 面的提示： Parse error, unexpected ',', expecting '(' in .../symfony.php on line 19. · 在 php.ini 中的内存限制，至少需要设置为 16M。 通常的症状就是通过 PEAR 方式安装 symfony 的时候出现的错误信息。 Allowed memory size of 8388608 bytes exhausted · 必须在 php.ini 中把 zend.ze1_compatibility_mode 参数设置为 off。 否则通过浏览器去访问脚本的话会出现"implicit cloning"错误： Strict Standards: Implicit cloning object of class 'sfTimer'because of 'zend.ze1_compatibility_mode' · 在你的项目中位于 Web 服务器上的 log/和 cache/目录必须是可写的。如 果在没有正确设定的时候访问 symfony 程序会出现以下提示： sfCacheException [message] Unable to write cache file"/usr/myproject/cache/frontend/prod/config/config_config_handl ers.yml.php" · 系统的路径需要包含 php 命令的路径，你的 php.ini 的包含路径必须包 括 PEAR 的路径（如果你使用 PEAR)。 · 有时，服务器上会有多个 php.ini 文件(例如，如果你使用 WAMP 包)。 可以用 phpinfo()函数去了解程序所用的 php.ini 文件所在的确切位 置。 NOTE 虽然不是强制性的，但是这里强烈推荐，为了运行得更顺 畅，在 php.ini 中设置 magic_quotes_gpc 和 register_globals 参数为 off。 symfony 资源 你可以在这些地方找到一些已经发现的问题的答案： · symfony 安装论坛 (http://www.symfony-project.com/forum/) 这里有 各种平台，环境配置，主机上安装 symfony 的问题讨论。 · 用户邮件列表档案(http://groups.google.fr/group/symfony-users) 也可以搜索。你也许会找到一些人遇到同样的问题。 · symfony wiki (http://www.symfony- project.com/trac/wiki#Installingsymfony) 有由 symfony 用户提供的 详细安装教程。 如果没有找到答案，试着把问题放到 symfony 社区。你可以在论坛，邮件列表 甚至在#symfony IRC 频道得到大家的回应。 源代码版本控制 设置程序完成后，推荐进行版本控制。 版本控制能跟踪对代码的所有修改，可 以回退到以前的版本，更容易地给程序打补丁和更有效地进行团队合作开发。 symfony 生来就支持 CVS，虽然更推荐使用 Subversion (http://subversion.tigris.org/)。下面的例子展示了 Subversion 的命令， 我们假设你已经有 Subversion 服务器并且希望在项目中建立一个新的版本库。 Windows 使用者推荐用叫做 TortoiseSVN (http://tortoisesvn.tigris.org/) 的 Subversion 客户端。在 Subversion 文档中可以找到关于版本控制命令的更 多信息。 下面的例子假设系统环境参数中已经定义了 $SVNREP_DIR。 如果还没有定义， 你要以实际存放位置代替 $SVNREP_DIR。 让我们在 myproject 项目中建立一个新的版本库： > svnadmin create $SVNREP_DIR/myproject 建立 trunk、 tags 和 branches 作为版本库的基础结构(layout)用以下命令： > svn mkdir -m "layout creation" file:///$SVNREP_DIR/myproject/trunk file:///$SVNREP_DIR/myproject/tags file:///$SVNREP_DIR/myproject/branches 这会是你的第一个版本。现在你需要把项目中除 cache/ 和 log/ 目录之外所 有的文件导入版本库： > cd ~/myproject > rm -rf cache/* > rm -rf log/* > svn import -m "initial import" . file:///$SVNREP_DIR/myproject/trunk 输入以下命令检查已经提交的文件： > svn ls file:///$SVNREP_DIR/myproject/trunk/ 看上去没问题。现在 SVN 库包含了你所有的项目文件的参考版本（还有历 史）。这意味着~myproject/目录需要与 SVN 库关联。要实现关联，首先修改 myproject/目录的名字（如果一切正常你很快就可以删了它了）然后在一个新 目录里签出 SVN 库里的文件： > cd ~ > mv myproject myproject.origin > svn co file:///$SVNREP_DIR/myproject/trunk myproject > ls myproject 现在你可以改写~/myproject/下的文件并提交到版本库中去。 myproject.origin/目录已经没用了，别忘了把它删除掉。 还有一件事情需要配置。 如果你提交当前工作目录到版本库中， 也许包含了 一些无用的文件，例如项目中的 cache 和 log 目录。所以必须为这个项目设置 一个 SVN 忽略列表。当然，你还需要重新设置 cache/ 和 log/目录的权限： > cd ~/myproject > chmod 777 cache > chmod 777 log > svn propedit svn:ignore log > svn propedit svn:ignore cache SVN 默认的文字编辑器会启动。如果没有，在 Subversion 中设置你想用的文字 编辑器： > export SVN_EDITOR=Hello, world!
".time().""; } ?> 例 4-5 - 另类 PHP 语法，适合于模板Hello, world!
TIP 一般来说模板语法的可读性是否够强是看这个文件是否不包含 PHP 的 echo 语句或者"{}"。大多数时候，开始的在同一行。 从动作传递信息给模板 动作要做的事情是所有的复杂计算，取出数据，测试，为模板设定显示或者测试 用的变量。symfony 让动作类的属性(动作里的可以通过$this->variableName 访问)能够直接在模板里面的全局命名空间里面访问得到(通过$variableName)。 例 4-6 与 4-7 演示如何从动作传递信息给模板。 例 4-6 - 设定动作的一个属性，把它传给模板 hour = $today['hours']; } } 例 4-7 - 模板能直接访问动作的属性Hello, world!
= 18): ?>Or should I say good evening? It's already .
NOTE 有几个数据可以直接在模板中访问而不需要在动作里面设置。每个模板都 可以执行$sf_contex,$sf_request,$sf_params 还有$sf_user 对象的方法。它 们 包 含 当前上下文、请求、请求参数还有 session 的信息。不久你就能学会怎么有 效的利用它们。 从用户表单取得数据 表单是从用户取得信息的好方法。用 HTML 写表单的元素有时会很麻烦，特别是 你想要XHTML兼容时。你可以按照平常的方式在 symfony 模板里面使用表单元素， 如例 4-8 所示，不过 symfony 提供了一些辅助函数来简化这个任务。 例 4-8 - 模板可以包含普通的 HTML 代码Hello, world!
= 18): ?>Or should I say good evening? It's already .
辅助函数是 symfony 定义的用在模板里的函数。它输出 HTML 代码从而节省你写 HTML 代码的时间。使用 symfony 辅助函数，你可以用例 4-9 的代码达到与例 4-8 同样的结果。 例 4-9 - 用辅助函数比写 HTML 标签更快更容易Hello, world!
= 18): ?>Or should I say good evening? It's already .
SIDEBAR 辅助函数是来帮助你的。 如果，你认为在例 4-9 的例子里，辅助函数的版本没有写 HTML 快，看看这个例 子： $card_list = array( > 'VISA' => 'Visa', > 'MAST' => 'MasterCard', > 'AMEX' => 'American Express', > 'DISC' => 'Discover'); > echo select_tag('cc_type', options_for_select($card_list, 'AMEX')); > ?> 上面的代码的 HTML 输出如下： 在模板里使用辅助函数使编写代码的速度提高，代码更清晰，更简洁。唯一的代 价是需要花时间学习他们，学习过程将一直持续到本书完结，到你在你习惯的编 辑器中用快捷键写的时候。所以如果不会用 symfony 的辅助函数，你仍然可以继 续使用 HTML 标签，不过这很浪费也很枯燥。 注意我们不推荐专业 web 开发者使用短开始标签( I never say my name 为了避免这样的麻烦，请使用 link_to()辅助函数来建立所有的链接到应用程序 内部的动作的超链接。例 4-11 演示了如何使用超链接辅助函数。 例 4-11 - link_to() 辅助函数Hello, world!
= 18): ?>Or should I say good evening? It's already .
上面的代码生成的 HTML 与前一个例子完全一样，但是如果修改路由规则，所有 的模板会根据规则重新格式 URL。 link_to()辅助函数，与很多辅助函数类似，接受另一个特殊的参数，这个参数 用来传递 HTML 标签属性。例 4-12 是一个 option 属性的例子还有生成的 HTML。 option 参数可以是一个数组或者一个简单的由几个 key=value 与空格组成的字 符串。 例 4-12 - 大多数辅助函数有 Option 参数 // 用数组作 option 参数 'special_link', 'confirm' => 'Are you sure?', 'absolute' => true )) ?> // 用字符串作 option 参数 // 结果一样 => I never say my name 任何使用 symfony 辅助函数输出 HTML 标签的时候，都可以在 option 参数中加入 额外的属性(例如例 4-12 中的 class 属性)。你甚至可以用 HTML 4.0 的"快速而 肮脏(quick-and-dirty)"的方式(不写双引号)，symfony 会用漂亮的 XHTML 方式 输出。这是用辅助函数比写 HTML 快的又一个原因。 NOTE 由于需要额外的解析与转换，字符串形式比数组要慢。 与其它辅助函数类似，链接辅助函数有好几种形式与参数。第 9 章将向你详细介 绍这些内容。 从请求中取得信息 无论用户通过表单(通常是 POST 请求)还是通过 URL(GET 请求) 取得信息，你都 可以在动作中通过 sfActions 对象的 getRequestParameter()方法取得相关的数 据。例 4-13 演示了如何在 actionAction 中取得 name 参数的值。 例 4-13 - 在动作中取得请求参数的值 name = $this->getRequestParameter('name'); } } 如果数据操作很简单，你甚至不必用动作来取得参数值。模板可以直接通过 $sf_params 的 get()方法来取得参数的值，类似于动作中的 getRequestParameter()方法。 如果 executeAnotherAction() 方法是空的, 例 4-14 中的这种方法也可以从 anotherActionSuccess.php 模板中取到 name 参数的值。 例 4-14 - 直接从模板中取得参数的值Hello, get('name') ?>!
NOTE 为什么不直接使用$_POST,$_GET, 或 $_REQUEST 变量呢？因为如果你的 URL 的格式会变化(例如 http://localhost/articles/europe/france/finance.html ，没有?或者=)，这 样 这些 PHP 变量就不管用了，只有路由系统能够取得请求参数。还 有 你 可能需要 输入过滤器来防止恶意代码注入，只有保持所有的参数使用一个干净的参数存储 器的时候才能实现。 $sf_params 对象的作用仅仅是数组的替代品。例如，如果你想判断一个请求参 数是否存在，你可以只用$sf_params->has()方法而不必用 get()方法取得实际 的值，如例 4-15。 例 4-15 - 在模板中判断一个参数是否存在 has('name')): ?>Hello, get('name') ?>!
Hello, John Doe!
你可能已经猜到这用一行代码就可以完成。与 symfony 里面的大多数 getter 方 法一样，动作里的 getRequestParameter()还有模板里的$sf_params->get()方 法(实际上两者调用的是同一个对象的同一个方法)可以有第二个参数：默认值， 在参数不存在的时候起作用。Hello, get('name', 'John Doe') ?>!
总结 在 symfony 里面，页面由一个动作(actions/actions.class.php 文件里的一个 方法，以 execute 开头)还有一个模板(templates/目录里的一个文件，通常以 Success.php 结尾)组成。功能有关联的页面组成模块。写模板有辅助函数帮忙， 辅助函数是 symfony 提供的返回 HTML 代码的函数。并且你需要把 URL 考虑成回 应的一部分，URL 也可以根据需要重新安排格式，所以你需要避免绕过超链接辅 助方法直接写动作的 URL。 一旦了解了这些基本原理，你就可以开始用 symfony 写一个完整的 web 应用程序 了。但是这需要花很长时间，因为几乎所有的功能都可以通过 symfony 的某种功 能来简化开发……，所以这本书还没结束。 第 5 章 配置 symfony 为了达到简单易用的目的，symfony 定义了一些惯例，这些惯例能够满足大多数 情况的需求。另一方面，使用一系列简单而强大的配置文件，我们可以定制这个 框架及应用程序的几乎所有的地方。使用这些配置文件可以为程序增加一些特殊 的参数。 这一章介绍配置系统如何工作： · symfony 配置信息保存在 YAML 格式的文件里，当然也可以换成其它格式。 · 配置文件分成项目、应用程序、模块这几个等级，分别存放在项目目录中 对应子目录里。 · 你可以定义几套不同的配置文件，symfony 里面的一套配置文件称之为环 境。 · 配置文件里面定义的值可以在 PHP 代码里面取得。 · 另外，symfony 可以识别 YAML 里面的 PHP 代码等，这使得配置系统更灵 活。 配置系统 不论什么用途，大多数 web 应用程序都有一些共同的特征。例如，有些区域只允 许一部分用户访问；很多页面共用一个布局；表单填写验证失败后自动把用户输 入的内容放进表单。框架定义了一些实现这些特性的结构，开发者通过配置系统 进一步的调整它们。这 种策略可以节省大量开发时间，因为很多改变并不用改写 代码，尽管实现这些改变需要很多代码。这种策略也更有效率，因为这些信息可 以存放在容易识别的位置。 但是，这样的做法有两个严重缺点： · 开发者最后整天不停的写复杂的 XML 文件。 · 使用 PHP 处理每个请求花费的时间更多了。 考虑到这些缺点，同时 symfony 又要充分利用配置文件的优点。事实上，symfony 的配置系统的目标是： · 强大：所有的可以配置的东西都可以用配置文件配置 · 简单：很多配置信息不会出现在普通的应用程序里，因为它们很少需要改 变 · 容易：开发者可以很容易的阅读，建立，修改配置文件 · 可定制：默认的配置语言是 YAML，但也可以换成 INI、XML，或者是别的 格式 · 快速：应用程序本身不用处理配置文件，由配置系统处理配置文件，把配 置文件编译成能够快速执行的 PHP 代码 YAML 语法与 symfony 惯例 symfony 默认使用 YAML 格式存放配置信息，而不用传统的 INI 或者 XML 格式。 YAML 通过缩进表示结构而且写起来很快。它的特点与基本规则在第一章里面已 经讲到了。不过，在写 YAML 的时候，你还需要记住几条规则。本节将介绍最常 用的几个规则。想完整的了解 YAML，请访问 YAML 网站(http://www.yaml.org/)。 首先，绝不要在 YAML 文件里使用制表符(tab)，应该使用空格。YAML 解析器不 能解析制表符，所以请使用空格来缩进(在 symfony 里面使用两个空格缩进)，如 例 5-1。 例 5-1 - YAML 文件禁用制表符(tab) # 绝不用制表符 all: -> mail: -> -> webmaster: webmaster@example.com # 应该使用空格 all: mail: webmaster: webmaster@example.com 如果你的参数是以空格开始或者结束的字符串，应使用单引号把它包起来。如果 一个字符串参数包含特殊字符，也要用单引号包起来，如例 5-2。 例 5-2 - 非标准的字符串要用单引号包起来 错误 1: This field is compulsory 错误 2: ' This field is compulsory ' 错误 3: 'Don''t leave this field blank' # 必须用两个单引号来表示字符 串中的' 利用特殊字符头(> 或 |)与一个缩进，长的字符串可以跨行表示。如例 5-3。 例 5-3 - 定义长的多行字符串 accomplishment: > # 由>开头的折叠式 Mark set a major league # 每一个换行被折叠成一个空格 home run record in 1998. # 使得 YAML 可读性更强 stats: | # 由|开头的原始式 65 Home Runs # 所有的换行都被保留 0.278 Batting Average # 缩进不会在结果里出现 如果要定义数组，需要用方括号把元素括起来或者使用展开的减号语法，如例 5-4。 例 5-4 - YAML 的数组语法 # 数组语法的简写 players: [ Mark McGwire, Sammy Sosa, Ken Griffey ] # 数组的展开语法 players: - Mark McGwire - Sammy Sosa - Ken Griffey 如果要定义关联数组或者说哈希表，要用大括号把元素括起来，键与值 key: value 中间保留一个空格。也可以用展开语法，每一个新的键增加一个缩进与换 行，如例 5-5。 例 5-5 - YAML 关联数组语法 # 错误的语法，冒号后缺少空格 mail: {webmaster:webmaster@example.com,contact:contact@example.com} # 关联数组的正确简写 mail: { webmaster: webmaster@example.com, contact: contact@example.com } # 关联数组的展开语法 mail: webmaster: webmaster@example.com contact: contact@example.com 定义一个布尔值时，on、1 或者 true 代表肯定值，off、0、或者 false 代表否 定值。如例 5-6。 例 5-6 - YAML 布尔值语法 true_values: [ on, 1, true ] false_values: [ off, 0, false ] 请不要吝啬使用注释(以井号#开头)还有空格，这会使注释文件更易读，如例 5-7。 例 5-7 - YAML 注释语法与值对齐 # 这是一个注释 mail: webmaster: webmaster@example.com contact: contact@example.com admin: admin@example.com # 多的空格可以帮助对齐 在某些 symfony 配置文件里面，你会发现一些行以#开头(YAML 解析器会忽略这 些行),但这些行看上去像普通的设置行。这是一个 symfony 的惯例：默认设置， 从 symfony 内核里其他的 YAML 文件里面继承的设置，这些会在你的应用程序配 置文件里面出现并用#注释起来，给你参考。如果你想改变这些参数，只要把注 释去掉就可以了。如例 5-8。 例 5-8 - 注释里的默认配置 # 缓存的默认值是关闭 settings: # cache: off # 如果你想修改这个值，去掉注释 settings: cache: on symfony 有时会把一些参数定义分类。一个分类里面的所有设置都放在分类头下 面。把长的 key: value 列表分组能增强可读性。分类头以点(.)开头。如例 5-9。 例 5-9 - 分类头与键类似，但是以.开头 all: .general: tax: 19.6 mail: webmaster: webmaster@example.com 在这个例子里，mail 是一个键，general 只是一个分类头。分类头可以当作不存 在，如例 5-10。tax 参数实际上是 all 键的直接子元素。 例 5-10 - 分类头只用于增强可读性，实际上可以忽略 all: tax: 19.6 mail: webmaster: webmaster@example.com SIDEBAR 如果你不喜欢 YAML YAML 只是一个给 PHP 代码定义设置的界面，所以 YAML 里面定义的配置信息都会 被转换成 PHP 代码。浏览一个应用程序，查看他的缓存的配置信息(例，在 cache/myapp/dev/config/)。你会发现 YAML 配置对应的 PHP 文件。这一章后面 我们会详细介绍配置缓存。 好消息是如果你不喜欢 YAML 文件，你可以自己动手，使用 PHP 代码或者其他的 格式(XML,INI 等)。在本书中，你会遇到其他的不使用 YAML 定义配置的方法， 在第 19 章你会了解如何替换 symfony 的配置文件处理器。如果你用好它们，你 可以利用这些技巧绕开配置文件或者定义你自己的格式。 救命，YAML 文件把我的程序搞死了 YAML 文件会被解析成 PHP 哈希与数组，然后这些值会在程序的不同地方改变视 图，控制器或者模型的行为。很多时候，配置文件里面的问题直到用到的时候才 被察觉。而且，显示的错误信息通常不是明显与 YAML 配置文件相关的。 如果改变了配置文件之后程序突然停止运行了，应 该 检查一下你是否犯了下面的 常见的 YAML 错误： · 键和值中间缺少空格： key1:value1 # 冒号:后缺少空格 · 数组里面的键应该按照同样的方式缩进： all: key1: value1 key2: value2 # 缩进与其他的数组元素不同 key3: value3 · 键或值里有 YAML 保留字符而且没有用单引号： message: tell him: go way # :, [, ], { and } 是 YAML 保留字符 message: 'tell him: go way' # 正确的语法 · 修改一个被注释了的行： # key: value # 由于前面的#,这行永远不会生效 · 同一级别相同键的值设置了两次： key1: value1 key2: value2 key1: value3 # key1 定义了两次，取最后一次定义的值 · 你认为设置值应该是一个特定的类型，实际上如果你不转换它，设置值永 远是字符串： income: 12,345 # 除非你转换它，否则它永远是字符串 配置文件概述 配置信息按照目的存放在不同的文件里。这些文件包含参数定义或者设置。一些 参数可以在不同的级别覆盖(项目，应用程序，模块)；一些只针对特定级别。本 节将介绍这些配置文件，第 19 章将更深入的介绍配置文件。 项目配置 symfony 项目有一些默认配置文件。下面是 myproject/config/目录下面的配置 文件： · config.php：这是所有页面或者命令行方式 PHP 脚本执行的第一个文件。 它包含 symfony 框架的路径，你可以把这个路径指定到另外一个 symfony 框架。如果你在这里增加一些 define 语句，这样定义的常量在项目的每 个应用程序都可以访问得到。第 19 章将会深入介绍这个文件的使用。 · databases.yml：这个文件用来存放数据库连接设置(主机，登录名，密码 等)。第 8 章有更详细的介绍。这个文件的配置信息可以在应用程序这一 级别覆盖。 · properties.ini：这个文件存放命令行工具需要的参数，包括项目名称， 远程服务器的连接设置。第 16 章将详细介绍此文件的功能。 · rsync_exclude.txt：这个文件定义同步服务器的时候哪些文件不需要同 步。详见第 16 章。 · schema.yml 与 propel.ini：这两个文件是 Propel(symfony 的 ORM 层) 的数据访问配置文件。它们用来使 Propel 与 symfony 的类还有项目的数 据协同工作。propel.ini 是自动生成的，所以你不用修改它。如果你不 用 Propel，就不需要这些文件。这两个文件的使用详见第 8 章。 这些文件多数时候是被外部组件或者命令行使用，或者 symfony 在 YAML 解析程 序载入之前就要用到它们。所以有些文件不是 YAML 格式。 应用程序配置 配置的主要部分是应用程序配置。前端控制器(在 web/目录)里定义主要的常量， YAML 文件在应用程序目录的 config/目录里，i18n/目录里是国际化需要的文件， 还有一些在框架文件里隐藏着的但是很有用的其他项目配置信息。 前端控制器配置 前端控制器里存放了应用程序最开始的配置信息；它是一个请求最开始执行的脚 本。请看例 5-11 中默认的 web/index.php。 例 5-11 - 默认的生产环境前端控制器 getController()->dispatch(); 定义了应用程序名(myapp)与环境(prod)之后，先载入通用配置文件，然后继续 分派请求。这里定义了一些有用的常量： · SF_ROOT_DIR：项目根目录 (一般情况请保留默认值，除非想变更目录结 构)。 · SF_APP：项目中的应用程序名。需要它来生成文件路径。 · SF_ENVIRONMENT：环境名 (prod, dev, 或者其他你定义的本项目的环 境)。用来决定使用哪一套配置信息。本章稍后会解释环境的概念。 · SF_DEBUG：是否启用调试模式 (详见第 16 章)。 如果你要改变这些值，那么你可能需要另一个前端控制器。下一章将介绍前端控 制器以及如何新建一个前端控制器。 SIDEBAR 根目录可以在任何地方 只有 web 根目录(symfony 项目的 web/目录)里的脚本对外界公开。前端控制器脚 本，图片，样式表，还有 JavaScript 文件是公开的。其他文件必须放在服务器 web 根目录之外--也就是说其他任何地方。 前端控制器通过 SF_ROOT_DIR 这个路径访问项目的非公开的文件。一 般 来 说 ，项 目 根 目 录 就 是 web/目录的上一层目录。但是你可以选择一个完全不同的文件结 构。假设你的主目录结构由两个目录组成，一个公开另外一个私有： symfony/ # 私有区域 apps/ batch/ cache/ ... www/ # 公开区域 images/ css/ js/ index.php 在这种情况下，项目根目录是 symfony/目录。所以 index.php 前端控制器只要 这样定义整个应用程序就可以工作了： define('SF_ROOT_DIR', dirname(__FILE__).'/../symfony'); 第 19 章将会告诉你更多如何修改 symfony 来实现特殊的目录结构的信息。 主应用程序配置 主应用程序配置存放在 myproject/apps/myapp/config/目录下的文件里： · app.yml：这个文件存放应用程序相关的配置信息，包括定义业务或者程 序逻辑的全局变量，这些都不需要存放在数据库里。税率，运费，e-mail 地址等经常存放在这个文件。这个文件默认是空的。 · config.php：这个文件引导应用程序，它会做所有的基础初始化来启动应 用程序。这里你可以定制目录结构或者增加应用程序相关的常量(详见第 19 章)。他首先会包含项目的 config.php 文件。 · factories.yml：symfony 在这里定义处理视图、请求、回应、会 话 (session) 等的类。如果你想用你自己的类取代 symfony 的类，你可以在这里定义它 们。详见第 19 章。 · filters.yml：过滤器是在每个请求都被执行的一小段代码。这个文件用 来定义哪些过滤器需要被执行，每个模块都可以改写过滤器配置。详见第 6 章。 · logging.yml：这个文件定义哪些情况需要被记录到日志里，从而管理与 调试应用程序。详见第 16 章。 · routing.yml：路由规则，能把难以理解的不好记忆的 URL 变成"漂亮"的 直观形式。此配置文件用来存放这些信息。每个新应用程序都会有一些默 认路由规则。详见第 9 章。 · settings.yml：这个文件存放 symfony 应用程序的主要配置信息。你的应 用程序是否使用国际化功能，它的默认语言，请求 timeout 时间，是否开 启缓存功能等都在这个文件里面定义。只要改变这个文件里的一行代码， 你就可以关闭网站来执行维护升级。这些设置还有它们的用法详见第 19 章。 · view.yml：这个文件里定义默认视图的结构(布局的名称，标题，还 有 meta tag；默认载入的样式表及 Javascript；默认的 content-type 等)。还有 默认的 meta 与标题标签。详见第 7 章。这些配置信息可以在模块里改写。 国际化配置 国际化的应用程序可以显示多种语言。这需要特殊的配置。国际化配置信息存放 在如下两个地方： · 应用程序 config/目录里的 i18n.yml：这个文件定义一般的翻译设置，例 如原文的语言、在数据库还是文件里面存放翻译信息还有翻译信息的格式 等。 · 应用程序 i18n/目录里的翻译文件：这些文件基本上是字典，里面包含程 序模板里面出现的所有文字的翻译，这 样 切 换 语 言 的地方就会显示对应的 翻译。 注意开启 i18n(国际化)功能需要在 setting.yml 文件里面设置。详见第 13 章。 其它应用程序配置 还有一部分配置文件在 symfony 的安装目录里(在 $sf_symfony_data_dir/config/)，这些文件在所有的项目配置目录里都找不到。 这是一些很少需要修改或者对于全部项目共用的配置信息。不过，如果你需要改 动它们，只要在你的 myproject/apps/myapp/config/里建立一个相同名字的空 文件，然后在里面改写你要修改的配置信息就可以了。应用程序里的配置信息总 是优先于框架的配置信息。下面是 symfony 安装目录的 config/目录里的文件： · autoload.yml；此文件包含了自动载入功能的配置信息。这个功能帮你从 特定的目录自动载入你写的类。详见第 19 章。 · constants.php：此文件包含了默认的应用程序文件结构。请使用应用程 序的 config.php 来覆盖这些配置信息。详见第 19 章。 · core_compile.yml 和 bootstrap_compile.yml：这两个文件记录启动应 用程序(在 bootstrap_compile.yml 里)和处理请求(在 core_compile.yml 里)需要载入哪些类。这些类被压缩在一个没有注释的 PHP 文件里，这样 可以最小化文件处理从而加快执行速度(每个请求只载入 1 个文件而不是 40 多个文件)。这在没有安装 PHP 加速器的时候特别有效。优化技术详见 第 18 章。 · config_handlers.yml：在这个文件里你可以增加或者修改处理配置文件 的工具。详见第 19 章。 · php.yml：这个文件用来检查 php.ini 里的配置信息是否满足程序需要， 并且可以帮你覆盖 php.ini 的配置。详见第 19 章。 模块配置 默认情况下，模块没有特别的配置信息。不过，如果你需要，你可以为某个模块 覆盖应用程序级的配置。例如，你需要修改一个模块里所有动作的 HTML 描述信 息，或是载入一个特定的 Javascript 文件。你可以选择针对某个特定的模块增 加新参数来实现保护性封装。 可能你已经猜到，模块配置文件必须放在 myproject/apps/myapp/modules/mymodule/config/目录里，模块配置信息有下 面这几个文件： · generator.yml：根据数据库表自动生成的模块(脚手架与管理后台)会用 这个文件, 它用来定义界面怎么显示行和列，用户可以执行哪些操作(过 滤器，排序，按钮等)。详见第 14 章。 · module.yml：这个文件包含模块的特殊参数(相当于 app.yml，但这是模 块级的),还有动作的配置信息。详见第 6 章。 · security.yml：这个文件用来给动作设置访问限制。你可以在这里设置哪 个页面只能给注册用户看或是一部分有特殊权限的注册用户看。详见第 6 章。 · view.yml：这个文件包含模块的一个或者所有动作的视图配置信息。它会 覆盖应用程序级的 view.yml，详见第 7 章。 · 数据验证文件：虽然这些用来验证表单输入数据的 YAML 数据验证文件存 放在 validate/目录而不是 config/目录里，它 们 仍 然 属 于 模 块 配置文件。 详见第 10 章。 大多数模块配置文件能让你为一个模块的所有视图或者动作定义参数，也可以只 为模块里的一部份视图或者动作定义参数。 SIDEBAR 文件太多了？ 可能应用程序里的配置文件太多了，使你受到了打击。不过请注意： 大多数时候你都不用修改配置，因为默认的配置就能够满足大部分的需求。每个 配置文件与一个特定的功能相关，以后的章节会一个一个详细介绍它们的用法。 当你关注某一个配置文件的时候，你就能清楚的了解它的用途还有它的组织形 式。对于专业 web 开发，默认的配置不会经常被完全重写。配置文件使你不用修 改一行代码轻易地改变 symfony 的功能。想想看要达到同样的目的需要多少 PHP 代码吧。如果所有的配置文件都存放在同一个文件里，那么这个文件不仅仅会变 得完全无法阅读，同样你也无法在不同的级别重新定义配置信息(请看本章后面 的"配置层叠"小节)。 配置系统是 symfony 重大优点之一，它使 symfony 适合于 几乎所有类型的 web 应用程序，不仅限于这个框架原本的设计目的。 环境 在开发应用程序的过程中，你可能同时需要好几套配置信息。例如，开发过程中 用来测试的数据库配置信息，还有生产环境中正式的数据库配置信息。symfony 为满足同时使用不同配置信息的需求，提供了不同的环境。 什么是环境？ 一个应用程序可以在不同的环境中运行。不同的环境共享相同的 PHP 代码(前端 控制器除外)，但是配置信息可能完全不同。symfony 为每个应用程序提供三种 默认的环境：生产(prod)、测试(test)和开发(dev)。只要你愿意你可以无限制 的增加环境的数量。 所以基本上，环境与配置是同义词。例如，测试环境会记录警告与错误，生产(prod) 环境只记录错误。缓存加速功能在开发(dev)环境下通常是关闭的，但是在测试 (test)与生产(prod)环境下开启。开发与测试环境所需要的测试数据，存放在与 生产环境不同的数据库里。所以两种环境的数据库配置会有所不同。所有的环境 可以在一台机器上共存，不过通常一台正式的服务器只包含生产(prod)环境。 在开发环境下，日志与调试功能都是开启的，因为排除问题比性能更重要。相反， 生产环境的配置默认是为性能优化的，所以生产环境会关闭一些功能。建议呆在 开发环境直到你对开发的功能满意为止，然后切换到生产环境测试速度。 测试环境又与开发与生产环境有所不同。你只能通过命令行来访问这个环境，通 常 是做功能测试和执行批处理脚本。因此，测试环境与生产环境接近，但是不能 通过浏览器访问。它能模拟 coookie 与其它 HTTP 相关的组件。 改变你正在访问的应用程序的环境，只要改变前端控制器就可以了。到目前为止， 你只见过开发环境，因为例子里的 URL 都是开发环境前端控制器的： http://localhost/myapp_dev.php/mymodule/index 不过，如果你想看看应用程序在生产环境中的样子，可以执行生产环境的前端控 制器： http://localhost/index.php/mymodule/index 如果你的 web 服务器支持 mod_rewrite，你甚至可以在 web/.htaccess 里自定义 symfony 重写规则。这些规则把生产环境的前端控制器作为默认的执行脚本能让 URL 看上去像这样： http://localhost/mymodule/index SIDEBAR 环境与服务器 不要把环境与服务器的概念混淆了。在 symfony 里，不同的环境是指不同的配置 信息，对应不同的前端控制器(执行请求的脚本)。不同的服务器对应 URL 里的不 同域名。 http://localhost/myapp_dev.php/mymodule/index _________ _____________ 服务器 环境 通常，开发人员在一台开发服务器上工作，这台服务器不与互联网相连，所有的 服务与 PHP 配置文件都可以自由修改。到了发布应用程序的时候，程序文件会传 到生产服务器上然后最终用户才能访问得到。 这意味着同一台服务器上可以有很多个环境。例如，你甚至可以在你的开发服务 器上运行生产环境。不过，大多数时候，生产服务器上只能访问生产环境，这样 可以避免服务器的配置信息泄露以减少安全方面的风险。 定义一个新环境，不需要建立目录或者使用 symfony 命令行工具。只要建立一个 新的前端控制器，修改这个前端控制器里面定义的环境名就可以了。这个环境会 继承所有默认配置信息和所有环境的共同配置信息。下一章会有详细介绍。 配置层叠 同样的配置信息可以在不同的地方定义多次。例如，你想把你的程序的所有页面 的 mime-type 定义成 text/html，只有一个 rss 模块例外，这个模块需要 text/xml 的 mime-type。symfony 可以让你在 myapp/config/view.yml 里面写第一个定义， 然后在 myapp/modules/rss/config/view.yml 里面写第二个定义。配置系统了解 模块级别的定义一定要覆盖应用程序级的定义。 实际上，symfony 具有如下的配置级别： · 粒度级别： o 框架里的默认配置 o 整个项目的全局配置 (在 myproject/config/ 里) o 项目中应用程序的配置 (在 myproject/apps/myapp/config/ 里) o 模块的配置 (在 myproject/apps/myapp/modules/mymodule/config/ 里) · 环境级别： o 针对某一个环境 o 所有环境 所有可以自定义的属性里，有一些是与环境有关的。因此，很多 YAML 配置文件 是按照环境分成了好几段，最后一段针对所有环境。因此一个典型的 symfony 配置文件类似于例 5-12。 例 5-12 - symfony 配置文件的结构 # 生产环境设置 prod: ... # 开发环境设置 dev: ... # 测试环境设置 test: ... # 自定义环境设置 myenv: ... # 所有环境的设置 all: ... 另外，symfony 框架本身定义的默认值并不在项目的目录里，它 们 在 你 的 symfony 的$sf_syfmony_data_dir/config/目录里。默认的配置信息在例 5-13 的文件里 设置。所有的应用程序都会继承到这些设置。 例 5-13 - 默认配置信息, 在 $sf_symfony_data_dir/config/settings.yml 里 # Default settings: default: default_module: default default_action: index ... 这些配置会在项目，应用程序，模块的配置信息里面以注释的形式反复出现，如 例 5-14 所示，这样你就可以知道这些默认值并且可以修改它们。 例 5-14 - 默认配置信息， 在 myapp/config/settings.yml 中出现以供参考 #all: # default_module: default # default_action: index ... 这意味着一个属性可以多次定义，最后的取值取决于层叠的结构。任何一个特定 环境里定义的参数优先于所有环境里定义的参数，所有环境里的参数优先于默认 配置。模 块 配置里的参数优先于应用程序级里定义的同样参数，应用程序里的参 数优先于项目级。这可以通过下面的优先级列表来表示： 1. 模块 2. 应用程序 3. 项目 4. 特定的环境 5. 所有环境 6. 默认 配置缓存 执行时解析 YAML 处理配置文件的层叠结构会增加每次请求的负担。symfony 内 建了配置文件缓存机制来提高请求速度。 不管什么格式的配置文件都需要一些特别的类来处理，又叫处理器，这些配置文 件被转换成快速执行的 PHP 代码。开发环境里，处理着每次请求都会去检查配置 文件的变化，这样提高交互性。它们解析改变的配置文件使你能马上看到 YAML 改变的效果。但是在生产环境，这样的处理只在第一次请求时进行，处理得到的 PHP 代码被保存下来给后面的请求使用。这样能提高性能，因为生产环境里的每 次请求只需要执行一些优化过的 PHP 代码。 例如，如果 app.yml 文件内容如下： all: # 所有环境的设置 mail: webmaster: webmaster@example.com 那么 cache/目录下的 config_app.yml.php 文件,将包括下面的内容： 'webmaster@example.com', )); 这样，大多数时候，symfony 不需要去解析 YAML 文件，只需要执行 cache 里的 配置信息就可以了。不过在开发环境,symfony 会自动比较 YAML 文件还有配置缓 存的修改时间，只重新处理上次请求后修改过的配置文件。 这是 symfony 与其他很多 PHP 框架相比的一个主要优势，这些 PHP 框架里的每次 请求都会去处理配置文件，即使是生产环境。与 Java 不同，PHP 不会在请求之 间共享执行状态。 其他依赖 XML 配置文件的框架在每次请求时处理 XML 性能损 失很大。symfony 不存在这个问题，配置文件带来的速度影响很小。 这样的机制带来一个重要的问题，如果你改变了生产环境的配置信息，你需要强 制重新解析所有你修改过的配置文件，这 样改变才能生效。你只需要清除缓存就 可以了，可以直接清空 cache/目录的内容，或是执行 clear-cache 这个 symfony 任务： > symfony clear-cache 从代码里访问配置信息 所有的配置文件最终都被转换成 PHP 代码，框架会自动使用很多设置。不过，有 时你需要在你的代码中(动作，模板，自定义类等)访问配置文件里定义的设置。 settings.yml、apps.yml、module.yml、logging.yml 还有 i18n.yml 里的配置 信息可以通过一个特殊的 sfConfig 类来访问。 sfConfig 类 你可以在程序代码里通过 sfConfig 类访问配置信息。它是一个配置信息的登记 处，它有一些简单的存取方法，这些存取方法可以在程序的任何地方使用。 // 取得一个设置 parameter = sfConfig::get('param_name', $default_value); 注意你也可以在 PHP 代码里定义或者覆盖一个设置： // 定义一个设置 sfConfig::set('param_name', $value); 参数的名字由几部分组成，中间用下划线分割，顺序如下： · 与配置文件名有关的前缀 (sf_ 代表 settings.yml, app_ 代表 app.yml, mod_ 代表 module.yml, sf_i18n_ 代表 i18n.yml, sf_logging_ 代表 logging.yml) · 父键名 (如果有), 小写形式 · 键名, 小写形式 参数名字不包括环境名称，因为 PHP 代码只能访问到执行时所在的环境里定义的 参数。 例如，如果你需要访问 app.yml 里定义的值，见例 5-15，你需要例 5-16 中的代 码。 例 5-15 - app.yml 配置文件样本 all: version: 1.5 .general: tax: 19.6 default_user: name: John Doe mail: webmaster: webmaster@example.com contact: contact@example.com dev: mail: webmaster: dummy@example.com contact: dummy@example.com 例 5-16 - 在 dev 环境从 PHP 代码里访问配置信息 echo sfConfig::get('app_version'); => '1.5' echo sfConfig::get('app_tax'); // 请注意分类的头会被忽略掉 => '19.6' echo sfConfig::get('app_default_user_name); => 'John Doe' echo sfConfig::get('app_mail_webmaster'); => 'dummy@example.com' echo sfConfig::get('app_mail_contact'); => 'dummy@example.com' 所以 symfony 的配置信息有所有 PHP 常量的优点，但是没有 PHP 常量的缺点，因 为 symfony 配置的值可以改变。 所以, 用来给应用程序设置框架设置的 settings.yml 文件,相当于一系列的 sfConfig::set()调用。例 5-17 会被解释为 例 5-18。 例 5-17 - 不完整的 settings.yml all: .settings: available: on path_info_array: SERVER path_info_key: PATH_INFO url_format: PATH 例 5-18 - symfony 处理 settings.yml 文件的结果 sfConfig::add(array( 'sf_available' => true, 'sf_path_info_array' => 'SERVER', 'sf_path_info_key' => 'PATH_INFO', 'sf_url_format' => 'PATH', )); settings.yml 文件里面设置的含义请参考第 19 章。 自定义应用程序配置与 app.yml 大部分与程序功能有关的设置存放在 app.yml 文件里，这个文件在 myproject/apps/myapp/config/目录。app.yml 与环境有关，默认是空的。把所 有你需要很容易修改的设置放在这个文件里，在代码里用 sfConfig 类访问它们。 如例 5-19。 例 5-19 - 这个 app.yml 给指定的网站定义接受的信用卡类型 all: creditcards: fake: off visa: on americanexpress: on dev: creditcards: fake: on 想要知道当前环境是否接受 fake 信用卡，需要这么写代码： sfConfig::get('app_creditcards_fake'); TIP 当你要定义一个常量或者一个设置的时候，考虑一下把它放在 app.yml 里面 会不会更好。在这里存放应用程序配置很方便。 如果你的自定义参数用 app.yml 的语法难以处理，你可以考虑自己定义一套语 法。这样你可以把配置信息存在一个新的文件里，用新的处理器解析配置文件。 配置文件处理器的资料详见第 19 章。 更多使用配置文件的技巧 在开始写你自己的 YAML 文件之前，有一些最后的技巧需要掌握。这些技巧可以 避免配置信息的重复及其如何处理你自己的 YAML 格式。 在 YAML 文件里使用常量 一些配置设置的值取决于其他的设置。为了避免重复设置同样的值，symfony 支 持在 YAML 文件里使用常量。如果遇到%包起来的大写形式的设置名(可以通过 sfConfig::get()取得值)，配置文件处理器会用这个设置的当前值来替换这个常 量。见例 5-20。 例 5-20 - 在 YAML 文件里使用常量，以 autoload.yml 为例 autoload: symfony: name: symfony path: %SF_SYMFONY_LIB_DIR% recursive: on exclude: [vendor] path 参数的值会是执行 sfConfig::get('sf_symfony_lib_dir')的结果。如果一 个配置文件依赖于另一个配置文件，被依赖的配置文件必须先被解析(请查看 symfony 的源代码来了解配置文件载入的顺序)。app.yml 是最后被解析的文件之 一，所以你可以在这个文件里使用其它文件里定义的设置。 在配置文件里使用脚本 有可能你的配置信息与外部参数有关(例如数据库或者其他配置文件)。为了解决 这种问题，symfony 在把配置文件传给 YAML 处理器之前先用 PHP 来解析配置文 件。这意味着你可以在 YAML 文件里使用 PHP 代码，如例 5-21。 例 5-21 - YAML 文件可以包含 PHP all: translation: format: 但是请注意配置文件在请求周期早期就被处理了，所以你不能使用 symfony 内建 的方法或者函数。 CAUTION 在生产环境中，配置文件会被缓存，所以配置文件只会在清除缓存后被 处理(并执行)一次。 浏览你的 YAML 文件 如果你想直接读取 YAML 文件，你可以使用 sfYaml 类。它是一个可以把 YAML 文 件转化成 PHP 数组的 YAML 解析器。例 5-22 是一个 YAML 文件的例子，例 5-23 是前面 YAML 文件的解析结果。 例 5-22 - test.yml house: family: name: Doe parents: [John, Jane] children: [Paul, Mark, Simone] address: number: 34 street: Main Street city: Nowheretown zipcode: 12345 例 5-23 - 使用 sfYaml 类把 YAML 转换成一个数组 $test = sfYaml::load('/path/to/test.yml'); print_r($test); Array( [house] => Array( [family] => Array( [name] => Doe [parents] => Array( [0] => John [1] => Jane ) [children] => Array( [0] => Paul [1] => Mark [2] => Simone ) ) [address] => Array( [number] => 34 [street] => Main Street [city] => Nowheretown [zipcode] => 12345 ) ) ) 总结 symfony 配置系统使用的 YAML 语言简单并且可读性强。多种环境与层叠结构的 参数定义为开发者提供了多种选择。一些配置文件可以从代码里通过 sfConfig 类访问，特别是 app.yml 里的应用程序配置。 的确,symfony 有很多配置文件，不过这使 symfony 适用性更强。注意除非你的 应用程序需要高级别的定制，否则你根本不需要去修改它们。 第 6 章 深入了解控制器层 在 symfony 中, 控制器是连接商业逻辑和视图层的程序。 根据不同的功能，它 又被细分为几个小部分： · 前端控制器是应用程序的唯一入口。 它载入配置文件并且指定将被执行 的动作。 · 动作包含应用逻辑。它们首先确定请求的完整性， 然后为表现层准备好 数据。 · 通过请求，应答，session 对象，我们可以获取请求参数，应答 HTTP 头， 和持久性的用户数据。这些数据经常被用在控制器层。 · 每一个请求都要执行过滤器程序，这个程序将在动作的前后执行。 例如， 安全和确认过滤器是网络编程经常要用到的。 你可以延伸架构去创作自 己的过滤器。 这一章将介绍这些组件。不要担心。一个简单的页面，你只需要在动作的类里面 写几行代码而已。其他的控制器层组件仅仅被用于一些特定的情况。 前端控制器 前端控制器接收并且处理所有的请求。所以前端控制器是整个应用程序的唯一入 口。 当前端控制器接收到一个请求， 路由选择系统将根据用户所用的 URL 连接相应 的动作和模块。例如，下列的 URL 调用 index.php 脚本(这是前端控制器)，它可 以被理解为调用 mymodule 模块里的 myAction 动作： http://localhost/index.php/mymodule/myAction 如果你对 symfony 的内部结构没有兴趣, 以上对前端控制器的认识已经足够了。 它是 symfony MVC 架构中不可缺少的组件, 但是你很少去更改它。 你可以跳过 下一节，除非你想更深入地了解前端控制器的结构。 前端控制器的工作细节 前端控制器处理请求的时候不仅仅是分配将需要执行的动作。其实，它还执行所 有动作的公共代码，它们包括： 1. 定义核心常量。 2. 定位 symfony 程序库。 3. 调入并初始化核心架构的类。 4. 调入配置文件。 5. 处理请求的 URL 并且指定将被执行的动作和请求参数。 6. 如果动作不存在， 转发给专门接收 404 错误信息的动作。 7. 启动过滤器 （例如，如果请求需要被认证）。 8. 执行过滤器， 第一回。 9. 执行所需要的动作并将结果提交给视图。 10.执行过滤器， 第二回。 11.输出应答。 默认的前端控制器 index.php 是默认的前端控制器。它是一个非常简单的 PHP 文件，在 web/ 文件 夹里。请看例 6-1。 例 6-1 - 默认的前端控制器 getController()->dispatch(); 首先是上一节讲的第一步，定 义 核心常量。然后前端控制器调入 config.php， 也 就是上面的第二步到第四步。 执行 sfController 对象（它是 symfony MVC 架构 里的核心控制器对象）中的 dispatch()函数处理请求，也就是上面的第五步到 第七步。 最后一步是执行过滤器。这部分稍后再讲解。 调用其他的前端控制器来切换环境 一个环境只能有一个前端控制器。事实上，我们应该说一个前端控制器确定了一 个环境。 SF_ENVIRONMENT 常量是环境的定义。 如果你想在项目中切换另一个环境，只需要选择另一个前端控制器。当你用 symfony init-app 创建一个新项目时，在生产环境中默认的前端控制器是 index.php。而在开发环境中默认的前端控制器是 myapp_dev.php（如果你的项 目叫 myapp）。如果 URL 没有指明前端控制器文件名，mod_rewrite 将用 index.php 作为默认值。所以下面这两个 url 在生产环境中是相同的（mymodule/index）。 http://localhost/index.php/mymodule/index http://localhost/mymodule/index 与此页面相同的开发环境的 URL 为： http://localhost/myapp_dev.php/mymodule/index 建立一个新的环境非常容易，只需要增添一个新的前端控制器。比如你想让客户 检验你的项目，你可以建立一个展示环境。你只需要拷贝一份 web/myapp_dev.php， 命名为 web/myapp_staging.php。然后把常量 SF_ENVIRONMENT 改为 staging。 最后，在所有的配置文件里添加 staging:部 分并赋值, 请参看例 6-2。 例 6-2 - 样本 app.yml，展示（staging）环境的设置 staging: mail: webmaster: dummy@mysite.com contact: dummy@mysite.com all: mail: webmaster: webmaster@mysite.com contact: contact@mysite.com 如果你想看一下新环境带来的变化，调用相应的前端控制器： http://localhost/myapp_staging.php/mymodule/index 批处理文件 如果你想在命令行或 crontab 上执行一个脚本并能享用 symfony 的类和其他功 能，比如发出大批电子邮件或通过大量计算而定时地更新你的模型。对于这种脚 本，你需要包括前端控制器里的前几行代码。例 6-3 显示批处理脚本文件的开头 部分。 例 6-3 - 批处理脚本文件样本 关闭标签。因为关闭标签不是必须 的，而且如果在关闭标签之后包含空格会造成问题。 另外，如果你特别注意，你会发现 symfony 程序的行从来不会以空格结尾。原因 就很简单：因为在 Fabien 的编辑器里空格结尾的行看起来很丑。 另一种动作类语法 还有一个方法是把动作分开，一个文件只有一个动作。在这种情况下，每一个动 作类扩展 sfAction （而不是 sfActions）并且命名为 actionNameAction。动 作被命名为 execute。文件名和类名相同。所以例 6-5 可以分成两个文件，例 6-6 和 6-7。 例 6-6 - 单个动作文件, myapp/modules/mymodule/actions/indexAction.class.php class indexAction extends sfAction { public function execute() { ... } } 例 6-7 - 单个动作文件， myapp/modules/mymodule/actions/listAction.class.php class listAction extends sfAction { public function execute() { ... } } 在动作里获取信息 在动作类里你可以获取控制器相关的信息和 symfony 的核心对象。例 6-8 展示它 的用法 例 6-8 - sfActions 常用方法 class mymoduleActions extends sfActions { public function executeIndex() { // Retrieving request parameters $password = $this->getRequestParameter('password'); // Retrieving controller information $moduleName = $this->getModuleName(); $actionName = $this->getActionName(); // Retrieving framework core objects $request = $this->getRequest(); $userSession = $this->getUser(); $response = $this->getResponse(); $controller = $this->getController(); $context = $this->getContext(); // Setting action variables to pass information to the template $this->setVar('foo', 'bar'); $this->foo = 'bar'; // Shorter version } } SIDEBAR 环境单例（context singleton） 你已经看到了，在前端控制器里，有一个 sfContext::getInstance()调用。在 动作里，getContext()方法也会返回同样的单例。这个很有用的对象保存了与某 个请求有关的所有 symfony 核心对象，并且为它们提供了读取方法： sfController: 控制器对象(->getController()) sfRequest: 请求对象 (->getRequest()) sfResponse: 应答对象 (->getResponse()) sfUser: 用户 session 对象 (->getUser()) sfDatabaseConnection: 数据库链接对象 (->getDatabaseConnection()) sfLogger: 日志对象 (->getLogger()) sfI18N: 国际化对象 (->getI18N()) 可以在代码的任何地方调用 sfContext::getInstance()。 动作结束 在动作结束前有几种状况。动作返回的数据将决定如何显示视图。在 sfView 类 里的常量决定哪一个模板被用于展示动作的结果。 如果有一个默认的视图（最普遍的情况）， 动作的结尾应该是这样的。 return sfView::SUCCESS; symfony 将寻找 actionNameSuccess.php 模板。这是动作的默认方式，所以即使 你省略了 return 这一行，symfony 一样会寻找并使用 actionNameSuccess.php 模板。即便动作是空的也一样。例 6-9 是动作结束的例子。 例 6-9 - 动作返回数据给 indexSuccess.php 和 listSuccess.php 模板 public function executeIndex() { return sfView::SUCCESS; } public function executeList() { } 如果有错误，动作应该这样结尾： return sfView::ERROR; symfony 就会去寻找 actionNameError.php 模板。 如果你想用一个特别的视图，你可以这样结尾： return 'MyResult'; symfony 就会去寻找 actionNameMyResult.php 模板。 如果根本就没有或不需要视图--例如，批处理文件的执行--应该这样结尾： return sfView::NONE; 在这种情况下，视图层就不会被执行了。这 就意味着你完全可以越过视图层直接 从动作输出 HTML 代码。请参看 6-10, symfony 提供一个 renderText()方法。这 个方法在响应速度要求很高的动作中会非常有用，比如和 Ajax 的互动。我们将 在第 11 章讨论。 例 6-10 - 用 sfView::NONE 越过视图层直接输出回应 public function executeIndex() { echo "Hello, World!"; return sfView::NONE; } // Is equivalent to public function executeIndex() { return $this->renderText("Hello, World!"); } 在一些情况下，你需要回复一个空的应答但要有 HTTP 头（特别是 X-JSONHTTP 头）。通过 sfResponse 对象定义 HTTP 头将在下一章讨论。返回 HTTP 头 sfView::HEADER_ONLY 常量, 请参看例 6-11。 例 6-11 - 避开视图层，但应答有 HTTP 头 public function executeRefresh() { $output = '<"title","My basic letter"],["name","Mr Brown">'; $this->getResponse()->setHttpHeader("X-JSON", '('.$output.')'); return sfView::HEADER_ONLY; } 如果动作需要一个特殊的模板，去掉 return 声明， 用 setTemplate()方法。 $this->setTemplate('myCustomTemplate'); 跳到另一个动作 在一些情况下，一个动作结束时需要执行另一个动作。例如，一个处理表单提交 的动作在更新数据库后通常被跳转到另一个动作上。第二个例子是动作别名：动 作 index 经常展示一个表，其实它转给了动作 list。 动作类里提供了两个方法可以执行另一个动作： · 如果动作转发给另一个动作： $this->forward('otherModule', 'index'); · 如果跳转到另一个动作： $this->redirect('otherModule/index'); $this->redirect('http://www.google.com/'); NOTE forward 与 redirect 之后的动作代码不会被执行。这一点上与 return 语 句是一样的。它们会抛出一个 sfStopException 异常来停止动作的执行； 这个 异常稍后会被 symfony 截获然后忽略。 选择转发或跳转有时并不容易。为了做出最好的选择，请记住转发在应用程序内 部进行，所以对于用户来说比较直接易懂。在用户的眼里，浏览器显示的 URL 和用户请求的 URL 是一样的。相反地，跳转是一条发给用户浏览器的消息，包括 一个新的请求并改变了最终的 URL。 如果一个表单通过 method="post"调用动作，你应该使用跳转。最大的优点是， 如果用户刷新页面，表单不会被重新提交；另外，如果用户点击后退键，浏览器 会再显示表单，而不是询问用户是否要重新提交表单。 forward404()是一个特殊并很常用的 forward 方法。它 forward 给"page not found"动作。当动作所需的请求参数不全时（比如查出一个错误的 URL），这个 方法就会被用到。例 6-12 展示的例子是一个 show 动作需要一个 id 参数。 例 6-12 - 使用 forward404()方法 public function executeShow() { $article = ArticlePeer::retrieveByPK($this->getRequestParameter('id')); if (!$article) { $this->forward404(); } } TIP 如果要找错误 404 的动作和模板，可以在 $sf_symfony_data_dir/modules/default/目录里找到它们。可以通过在你的应 用程序里增加一个新的 default 模块来定制这个页面，覆盖框架里的内容，定 义 一个 error404 动作和 error404Success 模板就可以了。 另外，还可以修改 settings.yml 文件里的 error_404_module 和 error_404_action 常量来使用已 有的动作作为 404 页面。 经验告诉我们，在多数情况下，动作需要在做出一个判断后再转发或跳转。例如 6-12。所以 sfActions 类有几个方法叫 forwardIf(), forwardUnless(), forward404If(), forward404Unless(), redirectIf(), redirectUnless()。这 些方法接受一个参数并且对它进行判断，如果判断结果是 true，xxxIf() 方法 将被执行；如果判断结果是 false，xxxUnless() 方法将被执行。 请参看例 6-13。 例 6-13 - 使用 forward404If() 方法 // 这个动作于例 6－12 中的作用相同 public function executeShow() { $article = ArticlePeer::retrieveByPK($this->getRequestParameter('id')); $this->forward404If(!$article); } // 这一个也是 public function executeShow() { $article = ArticlePeer::retrieveByPK($this->getRequestParameter('id')); $this->forward404Unless($article); } 这些方法不但使你的程序简短而且清晰易懂。 TIP 当动作执行 forward404()或者类似的方法的时候，symfony 会抛出 sfError404Exception 这个管理 404 回应的异常。这意味着如果在一个你不想访 问控制器的地方显示 404 错误信息，你只要抛出一个类似的异常就可以了。 几个动作共享的代码 synfony 给动作命名为 executeActionName() (如果使用 sfActions 类) 或 execute() (如果使用 sfActions 类)。这样 symfony 就能保证找到动作。你也 可以添加自己的方法， 只要你不用 execute 开头，symfony 就不会把这些方法 当做动作。 如果你需要在执行每个动作前都要执行一段代码，你可以把这段代码放入动作类 里的 preExecute()方法里。你可能猜到如果你想在执行每个动作后执行一段代 码，那你可以把这段代码放入 postExecute()方法里。 例 6-14 介绍了使用这 些方法的规则。 例 6-14 - 使用 preExecute, postExecute, 和自己定义的方法 class mymoduleActions extends sfActions { public function preExecute() { // 这里的代码会在每个动作之前执行 ... } public function executeIndex() { ... } public function executeList() { ... $this->myCustomMethod(); // 可以使用动作类里定义的方法 } public function postExecute() { // 这里的代码会在每次执行完动作之后执行 ... } protected function myCustomMethod() { // 还可以添加自己的方法，只要不以"execute"开头 // 最好把这样的方法声明成 protected 或者 private ... } } 访问请求 你或许熟悉了 getRequestParameter('myparam')方法：它被用于取得请求参数 值。事实上，这个方法只是调入 getRequest()->getParameter('myparam')的代 理方法。在动作类里可以通过 getRequest()方法访问请求对象，在 symfony 里 叫 sfWebRequest，和它所有的方法。 表格 6-1 展示一些常用的 sfWebRequest 方法。 表格 6-1 - sfWebRequest 对象里的方法 名称 功能 输出例子 请求信息 getMethod() 请求 的方 法 返回 sfRequest::GET 或者 sfRequest::POST 常量 getMethodName() 请求 方法 名 'POST' getHttpHeader('Server') 某个 指定 的 'Apache/2.0.59 (Unix) DAV/2 PHP/5.1.6' 名称 功能 输出例子 HTTP 头的 值 getCookie('foo') 某个 cooki e 的 值 'bar' isXmlHttpRequest()* 是否 是 Ajax 请 求？ true isSecure() 是否 是 SSL 请 求？ true 请求参数 hasParameter('foo') 请求 里是 否包 含某 个参 数？ true getParameter('foo') 某个 参数 的值 'bar' getParameterHolder()->g etAll() 包含 所有 参数 的数 组 URI 相关的信息 getUri() 完整 的 URI 'http://localhost/myapp_dev.php/mymodul e/myaction' getPathInfo() 路径 信息 '/mymodule/myaction' getReferer()** 来源 'http://localhost/myapp_dev.php/' getHost() 主机 'localhost' 名称 功能 输出例子 名 getScriptName() 前端 控制 器的 路径 和名 字 'myapp_dev.php' 客户端浏览器信息 getLanguages() 所有 可接 受的 语言 组成 的数 组 Array( [0] => fr [1] => fr_FR [2] => en_US [3] => en ) getCharsets() 所有 可接 受的 字符 集组 成的 数组 Array( [0] => ISO-8859-1 [1] => UTF-8 [2] => * ) getAcceptableContentTyp e() 所有 可接 受的 内容 类型 组成 的数 组 Array( [0] => text/xml [1] => text/html *只能用于 Prototype Javascript 库 ** 有时会被代理服务器阻拦 sfActions 类里有几个代理方法可以更简捷地访问请求方法，请参看例 6-15。 例 6-15 - 从动作类里访问 sfRequest 对象方法 class mymoduleActions extends sfActions { public function executeIndex() { $hasFoo = $this->getRequest()->hasParameter('foo'); $hasFoo = $this->hasRequestParameter('foo'); // Shorter version $foo = $this->getRequest()->getParameter('foo'); $foo = $this->getRequestParameter('foo'); // Shorter version } } 如果请求有附件，sfWebRequest 对象可以访问或移动这些文件，请参看例 6-16。 例 6-16 - sfWebRequest 对象知道如何处理附件 class mymoduleActions extends sfActions { public function executeUpload() { if ($this->getRequest()->hasFiles()) { foreach ($this->getRequest()->getFileNames() as $fileName) { $fileSize = $this->getRequest()->getFileSize($fileName); $fileType = $this->getRequest()->getFileType($fileName); $fileError = $this->getRequest()->hasFileError($fileName); $uploadDir = sfConfig::get('sf_upload_dir'); $this->getRequest()->moveFile('file', $uploadDir.'/'.$fileName); } } } } 你不需要考虑服务器是否支持$_SERVER 或$_ENV 变量，默认值或服务器兼容问题 --sfWebRequest 的方法会帮你解决这些问题。另外，这些方法的名称简单易懂， 你不再需要查看复杂的 PHP 文档，寻找有关请求方面的信息了。 用户会话 symfony 会自动地处理用户会话并保持用户请求的连续性。symfony 利用 PHP 内 置的会话管理功能并增强它灵活性，使它更容易使用。 访问用户会话 在动作里，你可以通过 getUser()方法访问从 sfUser 类生成的用户会话对象。 这个类里有一个参数存储方法，可用于存储用户属性。这些存储的用户属性在用 户会话结束前是有效的。 请参看例 6-17。 用户属性可以是任何数据结构（字 符串，数组，关联数组）。每个用户都有这个功能，即使是没注册的用户。 例 6-17 - sfUser 对象可以存储用户属性 class mymoduleActions extends sfActions { public function executeFirstPage() { $nickname = $this->getRequestParameter('nickname'); // 将数据保存到用户会话 $this->getUser()->setAttribute('nickname', $nickname); } public function executeSecondPage() { // 从用户会话中取得数据，如果取不到值则使用默认值 $nickname = $this->getUser()->getAttribute('nickname', 'Anonymous Coward'); } } CAUTION 你可以在用户会话中保存对象，但是请不要这么作。这是因为会话对象 在不同的请求之间是通过序列化的方式保存在文件里的。从序列化的数据里重建 会话的时候，对象的类必须是已经载入的，不过有的时候他们没有被载入。另外， 如果在会话里保存 Propel 对象，可能会有“卡住”的对象。 就像 symfony 里其他的获取方法一样，getAttribute()方法接受另一个参数，这 个 参 数 指 定一个默认值（如果要存储的用户属性是空的）。hasAttribute()方法 可以用来检查用户属性是否已经被定义了。getAttributeHolder()方法可以用来 访问参数存储器。这也使清除用户属性变得更简单。请参看例 6-18。 例 6-18 - 删除用户会话数据 class mymoduleActions extends sfActions { public function executeRemoveNickname() { $this->getUser()->getAttributeHolder()->remove('nickname'); } public function executeCleanup() { $this->getUser()->getAttributeHolder()->clear(); } } 在模板里，你可以通过储存在$sf_user 变量里的 sfUser 对象访问用户会话属性， 请参看例 6-19。 例 6-19 - 在模板里也可以直接访问用户会话属性Hello, getAttribute('nickname') ?>
NOTE 如果只需要在当前请求里存储信息（例如，在一连串动作调用里）更适合 用 sfRequest 类，它有 getAttribute()和 setAttribute 方法。只有 sfUser 对 象的属性能在不同的请求中持续存在。 短暂的属性 删除用户会话属性（如果不再需要这个属性了）是一个常见的问题。例如，在用 户提交表单后，你想显示一个确认信息。 当处理表单的动作需要转发到另一个 动作时，把 信息从一个动作传到另一个动作唯一的办法就是把信息存在用户会话 的属性里。在显示确认信息之后，你需要删除这个属性。否则，这个属性就会被 存入会话里，一直到会话到期。 你只需要定义短暂的属性，而不需要去删除。因为短暂的属性在接受到下一个请 求后会自动删除，使用户会话更清洁。在动作里，你可以这样来定义短暂的属性： $this->setFlash('attrib', $value); 用户看到这一页后，发出一个新的请求并触发了下一个动作。在这第二个动作里， 你可以这样取得属性的值： $value = $this->getFlash('attrib'); 在显示出下一页后，短暂属性 attrib 就被删除了。即使在下一页里你没有调用 这个属性，它也一样会被从会话里删除。 如果你在模板里调用这个属性，用$sf_flash 对象： has('attrib')): ?> get('attrib') ?> 或： get('attrib') ?> 短暂的属性是传递信息给下一个请求很好的方法。 会话管理 对开发者来说，symfony 的会话功能完全掩饰了对会话 ID 的存储方式。但是， 你仍然可以改变会话管理的默认机制。这是为高级用户设计的。 symfony 把会话 ID 存在客户端的 cookies 上。symfony 的会话 cookies 就叫 symfony, 但是你可以在 factories.yml 里改变会话的名称。 请参看例 6-20。 例 6-20 - 在 apps/myapp/config/factories.yml 里，改变会话的 Cookie 名称 all: storage: class: sfSessionStorage param: session_name: my_cookie_name TIP 会话只有在 factories.yml 里的 auto_start 参数设置成 true 时(这是默认 设置)才会开始开启（通过 PHP 的 session_start()函数）。如果想手动开始用 户会话，关闭会话存储机制里的这个设置就可以了。 symfony 的会话是基于 PHP 会话功能的。这就意味着如果你想用 URL 参数来代替 cookies 的话，你只需要在 php.ini 里修改 use_trans_sid 的设置。 我们不主 张使用这种方法。 session.use_trans_sid = 1 在服务器方面，symfony 把用户会话存在文件系统里面。如果你想把它们存在数 据库里， 你需要修改 factories.yml 里的 class 参数，请参看例 6-21。 例 6-21 - 修改服务器会话的存储方式，在 apps/myapp/config/factories.yml 里 all: storage: class: sfMySQLSessionStorage param: db_table: SESSION_TABLE_NAME # 存放会话的表的名字 database: DATABASE_CONNECTION # 使用的数据库连接的名字 现有的会话存储类有 sfMySQLSessionStorage, sfPostgreSQLSessionStorage, 和 sfPDOSessionStorage， 建议用最后这个。 database 不是必需的配置，它 确定数据库的连接方式；symfony 会用 databases.yml ( 见第 8 章) 里的配置(主 机, 数据库名, 用户名, 密码)去连接数据库。 在 sf_timeout 秒后，会话将自动期满。这个常量的默认值是 30 分钟。当然你可 以在 settings.yml 里修改这个常量。请参看例 6-22。 例 6-22 - 修改会话届期, 在 apps/myapp/config/settings.yml 里 default: .settings: timeout: 1800 # 会话存活的秒数 动作安全 可能会只有某些拥有特定权限的用户能够执行某个动作。symfony 提供的工具可 以让我们建立有安全设置的应用程序，用 户 必 须认证后才能访问应用程序的某些 功能或者部分。权利限制包括两个步骤：首先要声明每一个动作的安全条件，然 后给登录的用户对应的权限。 访问限制 Access Restriction 在执行每一个动作之前，动作都需要经过一个特殊的过滤器。这个过滤器将检查 当前的用户是否有权利执行该动作。 在 symfony 中，权限包括两个部分： · 用户必须被认证后才能执行有安全限制的动作。 · 证书是具名权限，可以通过它来按组管理组织权限。 动作的权限可以在模块的 config/目录的 YAML 配置文件 security.yml 里添加或 修改。在这个文件里，你可以设定每一个动作或所有动作的限制条件。 例 6-23 是 security.yml 的一个示例。 例 6-23 - 设置访问限制， 在 apps/myapp/modules/mymodule/config/security.yml 里 read: is_secure: off # 所有的用户都可以执行 read 动作 update: is_secure: on # update 动作只有认证的用户可以执行 delete: is_secure: on # 只有认证用户 credentials: admin # 并且有 admin 证书可以执行 all: is_secure: off # off 是默认值 动作的权利限制不是默认的。所以如果没有 security.yml 文件，或 security.yml 里面没有对动作的权利限制，任何人都可以执行所有的动作。如果已设定了 security.yml，symfony 将检查该请求是否符合被访问的动作权利限制。 当一 个用户访问一个设有权利限制的动作时， 结果由用户的证书决定： · 如果用户已被认证并有相应的证书，动作将被执行。 · 如果用户没有被认证，他将被跳转到登录的动作上。 · 如果用户已被认证但没有相应的证书，他将被跳转到一个默认的安全动 作。 请参看图 6-1。 默认的登录和安全页面很简单，你可能要重新设计。如果用户没有相应的权利， 你可以在 settings.yml 里指定被调用的动作。请参看例 6-24。 图 6-1 - 默认的安全动作 例 6-24 - 默认的安全动作在 apps/myapp/config/settings.yml 里设置 all: .actions: login_module: default login_action: login secure_module: default secure_action: secure 访问授权 如果要调用设有权限的动作，用户必须被认证后并有相应的证书。你可以用 sfUser 对象扩展用户的权限。 setAuthenticated()方法可以改变用户的认证状 态。 例 6-25 是一个用户认证的简单例子。 例 6-25 - 设置用户的认证状态 class myAccountActions extends sfActions { public function executeLogin() { if ($this->getRequestParameter('login') == 'foobar') { $this->getUser()->setAuthenticated(true); } } public function executeLogout() { $this->getUser()->setAuthenticated(false); } } 认证稍微有一点复杂，你可以检查，添加，删除认证。例 6-26 描述了 sfUser 类里的认证方法。 例 6-26 - 在动作里处理用户的认证 class myAccountActions extends sfActions { public function executeDoThingsWithCredentials() { $user = $this->getUser(); // 增加一个或者两个证书 $user->addCredential('foo'); $user->addCredentials('foo', 'bar'); // 检查用户是否有某个证书 echo $user->hasCredential('foo'); => true // 检查用户是否拥有这些证书中的一个 echo $user->hasCredential(array('foo', 'bar')); => true // 检查用户是否同时拥有两个证书 echo $user->hasCredential(array('foo', 'bar'), true); => true // 删除一个证书 $user->removeCredential('foo'); echo $user->hasCredential('foo'); => false // 删除所有的证书(在登出是特别有用) $user->clearCredentials(); echo $user->hasCredential('bar'); => false } } 如果一个用户有'foo'的证书，这个用户可以访问在 security.yml 里设有该证书 的动作。认证也可以在模板里用来显示被授权的内容。请参看例 6-27。 例 6-27 - 在模板里处理用户的证书- hasCredential('section3')): ?>
=> => symfony 里还有很多其他的辅助函数，如果要讲完它们需要一整本书。辅助函数 的最佳参考是在线 API 文档(http:// www.symfony-project.com/api/symfony.html)， 所有的辅助函数都有详细的介 绍，包括语法，参数，还有例子。 自己写辅助函数 symfony 本身包含了大量的各类辅助函数，不过如果你在 API 文档里找不到你需 要的辅助函数，你可能会想自己写新的辅助函数。这很简单。 一组辅助函数(返回 HTML 代码的标准 PHP 函数)被存放在名叫 FooBarHelper.php 的文件里，FooBar 是这这个辅助函数组的名字。这个文件在 app/myapp/lib/help/目录下(或者任意一个 lib/目录下的 helper/目录)，这样 做的目的是为了让 use_helper('FooBar')辅助函数能自动载入这组辅助函数。 TIP 系统允许你覆盖 symfony 自己的辅助函数。例如，如果你想重新定义 Text 辅助函数的所有内容，只要在 apps/myapp/lib/helper 目录下建立 TextHelper.php 文件。当使用 use_helpler('Text')的时候 symfony 会使用你定 义的辅助函数而不是系统默认的。但是请注意：由于原始文件没有载入，你需要 重新定义这组辅助函数里所有的函数，否则某些系统的辅助函数就用不了了。 页面布局 例 7-1 里的模板不是一个有效的 XHTML 文档。它缺少 DOCTYPE 定义还有 与