有时候，您想通过某些规则和标准来定义并且展示不同的限制验证错误。比如，您建立了一个给用户进行注册的表单，用户需要输入身份信息和用户凭据来完成注册。当用户进行注册的时候，输入用户名和一个安全的密码是必不可少的，但是是否输入用户的银行账户信息并不是强制要求的，用户具有选择权。
您可以通过继承一个限制基类 Constraint 来创建一个自定义的验证限制，比如，您可以创建一个简单的验证器来检查一个字符串是否只包含字母和数字。 创建限制类首先，您可以通过继承 Constraint 来创建一个验证： // src/AppBundle/Validator/Constraints/ ContainsAlphanumeric.php namespace AppBundle\Validator\Constraints;
从 Symfony 2.7 开始，如果您使用一个过时的类、功能或选项，Symfony 就会触发 E_USER_DEPRECATED 错误。在内部，它看起来是像这样的东西：trigger_error( 'The fooABC method is deprecated since version 2.4 and will be removed in 3.0.', E_USER_DEPRECATED);这很好，因为您能够通过检查您的日志知道在您升级程序之前需要改变什么。
每隔几年，Symfony 都会发布一个新的主版本（第一个数字改变）。这些版本是最棘手的升级，因为它们允许包含向后兼容的中断。然而，Symfony 试图使这个升级过程尽可能的平稳。这意味着您可以在主版本发布之前更新您的代码。这被称为使您的代码未来兼容（future compatible）。这里有三个步骤升级一个主版本：使您的代码不是过时的；通过 Composer 更新新的主版本；
如果您正在升级一个副版本（中间的数字变化），那么您不应该会遇到重要的向后兼容性的改变。细节参见 Symfony backwards compatibility promise。然而，一些向后兼容的中断是可能发生的，您会在一秒钟内学习如何准备他们。这里有 2 个步骤来升级一个副版本：通过 Composer 升级 Symfony 库；更新您的代码，使之在新的版本中工作。
当一个新的补丁版本被发布时（只有最后一个数字改变了），被发布的内容只包含错误修正。这意味着升级一个补丁版本真的很简单。$ composer update symfony/symfony就是这个！您不应该遇到任何的后退 - 兼容性中断或是需要改变您的代码中的任何内容。这是因为当您开启您的工程的时候，您的 composer.json 包含应用了一个像 2.6.
表单组件包含三个核心的对象：一个是表单类型（实现 FormTypeInterface），Form 以及 the FormView。 经常被程序员操作的唯一的类是表单类型类，这个类作为表单的基类。它被用来生成 Form 以及 FormView。你可以通过模拟它和工厂的交互作用来直接测试它，但是这个会很复杂。最好的办法就是将它传递到 FormFactory 这样就会像真正在应用程序中使用一样。
由于 SwiftmailerBundle 的缘故，用 Symfony 发送电子邮件是相当简单的，是利用 Swift Mailer 库的能力。要功能测试电子邮件是否发送，甚至判断电子邮件主题，内容或者其他标题，您可以使用 Symfony 分析器。开始先用一个简单的控制器动作发送一封电子邮件：public function sendEmailAction($name){ $message = \Swift_Message::newInstance() ->
有时运行测试，在运行测试之前，需要做额外的引导工作。例如，如果您正在运行一个功能测试并引入了一个新的翻译资源，那么您需要在运行这些测试之前清除缓存。这份指导书包括了如何做到这一点。首先，添加以下文件：// app/tests.bootstrap.
一个 Symfony 项目中的 Doctrine 仓库（repositories）测试是不被推荐的。当您处理一个仓库（repository）的时候，您真正在处理一些面对真正的数据库连接的东西。幸运的是，您可以很容易地测试您对真实数据库的查询（queries），如下所述。功能测试如果您需要确实地执行一个查询，您需要启动（boot）内核（kernel）以获得一个有效的链接。
如果您的代码和数据库交互，例如从中读取数据或者写入数据，您需要把这个考虑进去来调整测试。有很多方法可以解决这个问题。您可以创建一个 Repository 的仿制品，然后用它来返回预期的对象。在功能测试中，您可能需要准备一个有预定值的测试数据库来确保您的测试始终有相同的数据来使用。如果您想直接测试您的查询（queries），看如何测试 Doctrine 仓库。
重点推荐一个只测试 Response 的功能测试。但是如果您写了监视您的生产服务器的功能测试，您也许想要写一个分析器数据的测试，因为它给了您一个很好的方法来检查各种事情并执行一些度量。Symfony 分析器为每一个请求采集大量数据。用这些数据来检查数据可调用的次数，框架中花费的时间，等等。
如果您需要模拟不同客户之间的互动（比如说一个聊天），先创建几个客户：// ...$harry = static::createClient();$sally = static::createClient();$harry->request('POST', '/say/sally/Hello');$sally->request('GET', '/messages');$this->assertEquals(Response::HTTP_CREATED, $harry->getResponse()->getStatusCode());$this->
功能测试中的认证请求可能会延缓程序组。尤其当使用 form_login 的时候，它可能成为问题，因为它需要额外的填写和提交表单的需求。解决办法之一是在测试环境中像如何在功能测试中模拟 HTTP 认证中解释的用法一样来设置防火墙使用 http_basic。另一个方法是您自己创建一个 token 并将它储存在一个会话中。当您这样做的时候，您必须确认一个适当的 cookie 随着一个请求发送。
如果您的应用程序需要 HTTP 认证，跳过服务器变量的用户名和密码来生成客户端 createClient()：$client = static::createClient(array(), array( 'PHP_AUTH_USER' => 'username', 'PHP_AUTH_PW' => 'pa$$word',));您也可以在每一个请求的基础数据上重写它：$client->
通常，当您需要创建一个页面，您需要创建一个控制器并且从该控制器中呈现模板。但如果您仅仅呈现一个简单的模板，并且不需要传递给它的任何数据，则完全没必要创建一个控制器，通过使用内置的 FrameworkBundle:Template:template 控制器就可以达到目的。例如，假设您想要呈现 static/privacy.html.twig 模板，并且不需要给它传递任何变量。
书写扩展的主要目的就是把经常使用的代码移动到一个可重用的类中，比如说添加国际化支持。扩展可以定义标签、 筛选、 测试、 操作符、 全局变量、 函数和节点访客。创建扩展也使得在编译执行的时候和代码运行的时候使您的代码能更好地分离。这样的话，能使您的代码运行得更快。在编写您自己的扩展之前, 请看一看 Twig 官方的扩展库。
Symfony 默认 Twig 作为其模板引擎，但如果你想，你仍然可以使用纯 PHP 代码。在 Symfony 中，两种模板引擎都同样支持。Symfony 中在 PHP 上添加了一些不错的功能，使得使用 PHP 来编写模板更强大。呈现 PHP 模板如果你想使用 PHP 模板引擎，首先，请确保在应用程序配置文件中启用它：YAML：# app/config/config.ymlframework: # ...
通常，当您引用模板的时候，您将使用 MyBundle:Subdir:filename.html.twig 格式 (请参见模板命名和位置)。Twig 也以本机方式提供了一种称为“命名空间路径”的功能支持，然后为您的包进行了自动内置。下面的路径便是一个例子：{% extends "AppBundle::layout.html.twig" %}{% include "AppBundle:Foo:bar.html.
有时您想要一个对您所用的所有模板都可用的变量。这在您的 app/config/config.yml 文件夹里是可行的。YAML:# app/config/config.ymltwig: # ... globals: ga_tracking: UA-xxxxx-xXML:<!-- app/config/config.xml --><twig:config> <!-- ... --> <twig:global key="ga_tracking">UA-xxxxx-x</twig:global><
关注时代Java
