Symfony 自动与默认目录结构建立联系。你可以轻松地重写这个目录来建立你自己的。默认目录结构如下： your-project/├─ app/│ ├─ cache/│ ├─ config/│ ├─ logs/│ └─ ...├─ src/│ └─ ...├─ vendor/│ └─ ...└─ web/ ├─ app.php └─ ...
每一个应用程序都是代码和一系列规定了代码如何执行相应功能的设置的集合。设置可能定义了使用的数据库或者有些东西是否应该被缓存又或者冗长的日志应该如何处理。在 Symfony 中，“环境”的思想就是可以使用很多不同的设置运行相同的代码库。举例来说，dev 环境应当使用从而使得开发简单并且有好的设置，然而 prod 环境就应当使用优化速度的设置。
Composer 是一个现代的应用程序所使用的封包管理器。使用 Composer 来管理你的 Symfony 应用程序的相关性并且在你的 PHP 工程中安装 Components。 推荐在你的操作系统中像下面介绍的那样全局安装 Composer。 在 Linux 和 Mac OS X 上安装 Composer在 Linux 和 Mac OS X 上安装 Composer，执行下列两条命令： $ curl -sS https://getcomposer.
CSRF 令牌意味着每一个用户都是不同的。这就是为什么如果你尝试缓存带有表单的页面时需要注意这点。 获取更多有关于 Symfony 中 CSRF 保护如何运作的信息，请查阅 CSRF 保护。 为什么缓存带有 CSRF 令牌的页面会出现问题典型地，每个用户都被分配了一个特定的 CSRF 令牌，这个令牌储存在校验的会话中。
由于 Symfony 的缓存使用的是标准的 HTTP 缓存头文件，Symfony 反向代理 可以很容易地就被其它的反向代理取代。Varnish 是一个强大的，开源的，HTTP 加速器可以提供缓存内容加速并且包括支持 Edge Side Includes。 使 Symfony 信任反向代理Varnish 自动在请求中将 IP 地址作为 X-Forwarded-For 转发并且去掉 X-Forwarded-Proto 的头信息。
当创建可重复利用以及可扩展的应用程序时，开发者经常面临一个选择：创建一个简单的大的 bundle 还是创建多个小的 bundle。创建一个简单的 bundle 的缺点就是不能让用户选择移除他们不需要的功能。创建多个 bundle 的缺点就是配置会变得很繁杂无聊，很多设置都需要对不同的 bundle 重复设置。
如果你打开你的应用程序配置文件（通常是 app/config/config.yml），你将会看到一些不同设置的部分，例如 framework, twig 和 doctrine。这些配置的每一个都有特定的 bundle，允许基于你的设置定义高级的选项并且让 bundle 设置为低级的，复杂的。
在 Symfony 中，你可以通过应用很多的服务来找到你自己。这些服务可以在你的应用程序的 app/config/ 目录下注册。但是如果当你想要分离 bundle 让它们应用于其它的工程中时，你就会想要让 bundle 自己拥有服务配置。这篇文章将会教你如何实现这个目标。 建立一个 Extension 类为了加载服务配置，你必须为你的 bundle 建立一个 Dependency Injection (DI) Extension。
Symfony 的标准版本来自于一个完整的 demo,这个 demo 位于一个名叫 AcmeDemoBundle 的 bundle 中。在开始一个工程的时候它是一个很好的可以引用的样板文件，但是最终你可能会想要移除它。 这篇文章使用 AcmeDemoBundle 作为例子，但是你可以使用这些步骤移除任何的 bundle。 1.
这篇文档是教你如何重写第三方 bundle 的不同部分的快速指南。 模板获取有关于重写模板的信息参见 重写 Bundle 模板 如何使用 Bundle 的继承来重写部分 Bundle 路由在 Symfony 中路由是不会自动输入的，如果你想要从任何的 bundle 中包含路由，那么它们必须从你的应用程序的某个地方人工输入（例如 app/config/routing.yml）。
在使用第三方 bundle 的时候，你很可能有这样一个想法，就是你想用你自己的 bundle 文件重写那个第三方的 bundle 文件。Symfony 为你提供了一个非常方便的方法来重写诸如 controllers, templates 以及其它的在 bundle 的 Resources/ 目录中的文件。 举例来说，假如你正在安装 FOSUserBundle，但是你想重写它的基础的 layout.html.
这里有两种类型的 bundle： 特定应用程序的 bundle：只应用于建立你的应用程序； 可复用的 bundle：意味着可以在多个工程中共享。 这篇文章就是要告诉你如何构建你的可复用 bundle 从而它们可以很方便的进行设置和扩展。这些建议的大多数都不会应用在应用程序的 bundle，因为你总是希望让它们保持尽可能的简单。
大多数的 bundles 都提供自己的安装指南，然而，基本的 bundles 安装步骤都是一样的： A)添加 Composer 依赖B)启用 Bundle C)设置 Bundle A)添加 Composer 依赖依赖是由 Composer 管理的，所以如果你不太了解 Composer，你可以在它的相关文档中学习一些基本理论。
Assetic 的过滤器可以应用到独立的文件上，甚至一组文件，就像你看到的这样，文件都有特定的扩展名。为了向你展示如何处理每一个选项，假设你想使用 Assetic 的 CoffeeScript 过滤器，这个过滤器将 CoffeeScript 文件编译成 JavaScript 文件。 主要的设置就是 coffee, node 和 node_modules 的路径。设置的例子如下所示： YAML:# app/config/config.
在众多的过滤器之中，Assetic 拥有四个可以用作动态的图像优化的过滤器。这就让你可以在没有应用图片编辑器以及没有编辑每一张图片的情况下就可以享受小尺寸图片的好处。这个结果可以是缓存也可以进行产出转储，所以你的最终用户也没有备份。 使用 JpegoptimJpegoptim 是一款优化 JPEG 格式文件的实用工具。
YUI Compressor 不再归属于雅虎。这就是为什么除非特别必要，否则强烈建议你避免使用 YUI 实用程序。阅读如何裁剪 CSS/JS 文件(使用 UglifyJS 和 UglifyCSS)来寻求一种更新的现代的的替代品。 雅虎提供了一款优秀的压缩 JavaScripts 和 stylesheets 的实用工具这样他们就可以在线路中传输的更快了，这就是 YUI Compressor。
UglifyJS 是一个 JavaScript 的集合了 parser/compressor/beautifier 的工具包。它可以用来合并压缩 JavaScript 资产从而减少 HTTP 的请求的数量并且加快你的网站的加载速度。UglifyCSS 是一个和 UglifyJS 十分相似的 CSS compressor/beautifier。 在本指导中，对 UglifyJS 的安装，配置以及使用都进行了详细的讲解。
Symfony 官方的最佳实践推荐使用 Assetic 来管理网页资产，除非你用的习惯基于 JavaScript 的前端工具。即使那些基于 JavaScript 的解决方案大多数适用于那些从技术角度来说的案例，使用纯的 PHP 可选函数库在一些脚本中也会很有用： 如果你不能安装或者使用 npm 和其他的 JavaScript 解决方案； 如果你更喜欢限制你的应用程序中使用不同技术的数量；
Assetic 结合了两种主要的观点:资产和过滤器。资产文件如 CSS、JavaScript 和图像文件。过滤器是一种可以在文件被应用到浏览器之前就应用到文件上的东西。这样就会将存储在应用程序中的资产文件与呈献给用户的文件分开。 没有 Assetic，你就需要直接提供存储在应用程序之中的文件： Twig:<script src="{{ asset('js/script.js') }}"></script>PHP:<
Symfony2 是一个基于 MVC 模式的面向对象的 PHP5 框架，有着开发速度快、性能高等特点。Symfony 的目的是加速 Web 应用的创建与维护。
关注时代Java
