diff --git a/book/forms.rst b/book/forms.rst index dab0a3137f3..681ff57dc70 100644 --- a/book/forms.rst +++ b/book/forms.rst @@ -716,14 +716,16 @@ the correct values of a number of field options. And though you'll need to manually add your server-side validation, these field type options can then be guessed from that information. -* ``required``: The ``required`` option can be guessed based on the validation - rules (i.e. is the field ``NotBlank`` or ``NotNull``) or the Doctrine metadata - (i.e. is the field ``nullable``). This is very useful, as your client-side - validation will automatically match your validation rules. +``required`` + The ``required`` option can be guessed based on the validation rules (i.e. is + the field ``NotBlank`` or ``NotNull``) or the Doctrine metadata (i.e. is the + field ``nullable``). This is very useful, as your client-side validation will + automatically match your validation rules. -* ``max_length``: If the field is some sort of text field, then the ``max_length`` - option can be guessed from the validation constraints (if ``Length`` or - ``Range`` is used) or from the Doctrine metadata (via the field's length). +``max_length`` + If the field is some sort of text field, then the ``max_length`` option can be + guessed from the validation constraints (if ``Length`` or ``Range`` is used) or + from the Doctrine metadata (via the field's length). .. note:: @@ -771,12 +773,13 @@ of code. Of course, you'll usually need much more flexibility when rendering: You already know the ``form_start()`` and ``form_end()`` functions, but what do the other functions do? -* ``form_errors(form)`` - Renders any errors global to the whole form - (field-specific errors are displayed next to each field); +``form_errors(form)`` + Renders any errors global to the whole form (field-specific errors are displayed + next to each field). -* ``form_row(form.dueDate)`` - Renders the label, any errors, and the HTML - form widget for the given field (e.g. ``dueDate``) inside, by default, a - ``div`` element. +``form_row(form.dueDate)`` + Renders the label, any errors, and the HTML form widget for the given field + (e.g. ``dueDate``) inside, by default, a ``div`` element. The majority of the work is done by the ``form_row`` helper, which renders the label, errors and HTML form widget of each field inside a ``div`` tag by diff --git a/book/http_cache.rst b/book/http_cache.rst index 46e80ed4e73..1a41d2bb422 100644 --- a/book/http_cache.rst +++ b/book/http_cache.rst @@ -202,34 +202,39 @@ method:: Here is a list of the main options: -* ``default_ttl``: The number of seconds that a cache entry should be - considered fresh when no explicit freshness information is provided in a - response. Explicit ``Cache-Control`` or ``Expires`` headers override this - value (default: ``0``); - -* ``private_headers``: Set of request headers that trigger "private" - ``Cache-Control`` behavior on responses that don't explicitly state whether - the response is ``public`` or ``private`` via a ``Cache-Control`` directive. - (default: ``Authorization`` and ``Cookie``); - -* ``allow_reload``: Specifies whether the client can force a cache reload by - including a ``Cache-Control`` "no-cache" directive in the request. Set it to - ``true`` for compliance with RFC 2616 (default: ``false``); - -* ``allow_revalidate``: Specifies whether the client can force a cache - revalidate by including a ``Cache-Control`` "max-age=0" directive in the - request. Set it to ``true`` for compliance with RFC 2616 (default: false); - -* ``stale_while_revalidate``: Specifies the default number of seconds (the - granularity is the second as the Response TTL precision is a second) during - which the cache can immediately return a stale response while it revalidates - it in the background (default: ``2``); this setting is overridden by the - ``stale-while-revalidate`` HTTP ``Cache-Control`` extension (see RFC 5861); - -* ``stale_if_error``: Specifies the default number of seconds (the granularity - is the second) during which the cache can serve a stale response when an - error is encountered (default: ``60``). This setting is overridden by the - ``stale-if-error`` HTTP ``Cache-Control`` extension (see RFC 5861). +``default_ttl`` + The number of seconds that a cache entry should be considered fresh when no + explicit freshness information is provided in a response. Explicit + ``Cache-Control`` or ``Expires`` headers override this value (default: ``0``). + +``private_headers`` + Set of request headers that trigger "private" ``Cache-Control`` behavior on + responses that don't explicitly state whether the response is ``public`` or + ``private`` via a ``Cache-Control`` directive (default: ``Authorization`` + and ``Cookie``). + +``allow_reload`` + Specifies whether the client can force a cache reload by including a + ``Cache-Control`` "no-cache" directive in the request. Set it to ``true`` for + compliance with RFC 2616 (default: ``false``). + +``allow_revalidate`` + Specifies whether the client can force a cache revalidate by including a + ``Cache-Control`` "max-age=0" directive in the request. Set it to ``true`` for + compliance with RFC 2616 (default: false). + +``stale_while_revalidate`` + Specifies the default number of seconds (the granularity is the second as the + Response TTL precision is a second) during which the cache can immediately + return a stale response while it revalidates it in the background (default: + ``2``); this setting is overridden by the ``stale-while-revalidate`` HTTP + ``Cache-Control`` extension (see RFC 5861). + +``stale_if_error`` + Specifies the default number of seconds (the granularity is the second) during + which the cache can serve a stale response when an error is encountered + (default: ``60``). This setting is overridden by the ``stale-if-error`` HTTP + ``Cache-Control`` extension (see RFC 5861). If ``debug`` is ``true``, Symfony automatically adds a ``X-Symfony-Cache`` header to the response containing useful information about cache hits and @@ -339,11 +344,12 @@ and then returned to every subsequent user who asked for their account page! To handle this situation, every response may be set to be public or private: -* *public*: Indicates that the response may be cached by both private and - shared caches; +*public* + Indicates that the response may be cached by both private and shared caches. -* *private*: Indicates that all or part of the response message is intended - for a single user and must not be cached by a shared cache. +*private* + Indicates that all or part of the response message is intended for a single + user and must not be cached by a shared cache. Symfony conservatively defaults each response to be private. To take advantage of shared caches (like the Symfony reverse proxy), the response will need @@ -1033,12 +1039,14 @@ possible. The ``render_esi`` helper supports two other useful options: -* ``alt``: used as the ``alt`` attribute on the ESI tag, which allows you - to specify an alternative URL to be used if the ``src`` cannot be found; +``alt`` + Used as the ``alt`` attribute on the ESI tag, which allows you to specify an + alternative URL to be used if the ``src`` cannot be found. -* ``ignore_errors``: if set to true, an ``onerror`` attribute will be added - to the ESI with a value of ``continue`` indicating that, in the event of - a failure, the gateway cache will simply remove the ESI tag silently. +``ignore_errors`` + If set to true, an ``onerror`` attribute will be added to the ESI with a value + of ``continue`` indicating that, in the event of a failure, the gateway cache + will simply remove the ESI tag silently. .. index:: single: Cache; Invalidation diff --git a/book/http_fundamentals.rst b/book/http_fundamentals.rst index eaadacff92f..b49729183f7 100644 --- a/book/http_fundamentals.rst +++ b/book/http_fundamentals.rst @@ -515,30 +515,32 @@ libraries that can be used inside *any* PHP project. These libraries, called the *Symfony Components*, contain something useful for almost any situation, regardless of how your project is developed. To name a few: -* :doc:`HttpFoundation ` - Contains - the ``Request`` and ``Response`` classes, as well as other classes for handling - sessions and file uploads; +:doc:`HttpFoundation ` + Contains the ``Request`` and ``Response`` classes, as well as other classes for + handling sessions and file uploads. -* :doc:`Routing ` - Powerful and fast routing system that - allows you to map a specific URI (e.g. ``/contact``) to some information - about how that request should be handled (e.g. execute the ``contactAction()`` - method); +:doc:`Routing ` + Powerful and fast routing system that allows you to map a specific URI + (e.g. ``/contact``) to some information about how that request should be handled + (e.g. execute the ``contactAction()`` method). -* :doc:`Form ` - A full-featured and flexible - framework for creating forms and handling form submissions; +:doc:`Form ` + A full-featured and flexible framework for creating forms and handling form + submissions. -* `Validator`_ - A system for creating rules about data and then validating - whether or not user-submitted data follows those rules; +`Validator`_ + A system for creating rules about data and then validating whether or not + user-submitted data follows those rules. -* :doc:`Templating ` - A toolkit for rendering - templates, handling template inheritance (i.e. a template is decorated with - a layout) and performing other common template tasks; +:doc:`Templating ` + A toolkit for rendering templates, handling template inheritance (i.e. a + template is decorated with a layout) and performing other common template tasks. -* :doc:`Security ` - A powerful library for - handling all types of security inside an application; +:doc:`Security ` + A powerful library for handling all types of security inside an application. -* :doc:`Translation ` - A framework for - translating strings in your application. +:doc:`Translation ` + A framework for translating strings in your application. Each and every one of these components is decoupled and can be used in *any* PHP project, regardless of whether or not you use the Symfony framework. diff --git a/book/internals.rst b/book/internals.rst index e5492ced478..87bae69895d 100644 --- a/book/internals.rst +++ b/book/internals.rst @@ -212,15 +212,15 @@ Each event thrown by the Kernel is a subclass of :class:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent`. This means that each event has access to the same basic information: -* :method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getRequestType` - - returns the *type* of the request (``HttpKernelInterface::MASTER_REQUEST`` - or ``HttpKernelInterface::SUB_REQUEST``); +:method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getRequestType` + Returns the *type* of the request (``HttpKernelInterface::MASTER_REQUEST`` or + ``HttpKernelInterface::SUB_REQUEST``). -* :method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getKernel` - - returns the Kernel handling the request; +:method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getKernel` + Returns the Kernel handling the request. -* :method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getRequest` - - returns the current ``Request`` being handled. +:method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getRequest` + Returns the current ``Request`` being handled. ``getRequestType()`` .................... @@ -347,18 +347,18 @@ The purpose of this event is to allow other systems to modify or replace the The FrameworkBundle registers several listeners: -* :class:`Symfony\\Component\\HttpKernel\\EventListener\\ProfilerListener`: - collects data for the current request; +:class:`Symfony\\Component\\HttpKernel\\EventListener\\ProfilerListener` + Collects data for the current request. -* :class:`Symfony\\Bundle\\WebProfilerBundle\\EventListener\\WebDebugToolbarListener`: - injects the Web Debug Toolbar; +:class:`Symfony\\Bundle\\WebProfilerBundle\\EventListener\\WebDebugToolbarListener` + Injects the Web Debug Toolbar. -* :class:`Symfony\\Component\\HttpKernel\\EventListener\\ResponseListener`: fixes the - Response ``Content-Type`` based on the request format; +:class:`Symfony\\Component\\HttpKernel\\EventListener\\ResponseListener` + Fixes the Response ``Content-Type`` based on the request format. -* :class:`Symfony\\Component\\HttpKernel\\EventListener\\EsiListener`: adds a - ``Surrogate-Control`` HTTP header when the Response needs to be parsed for - ESI tags. +:class:`Symfony\\Component\\HttpKernel\\EventListener\\EsiListener` + Adds a ``Surrogate-Control`` HTTP header when the Response needs to be parsed + for ESI tags. .. seealso:: diff --git a/book/templating.rst b/book/templating.rst index 46dfde2e906..dd2cb88300b 100644 --- a/book/templating.rst +++ b/book/templating.rst @@ -384,15 +384,16 @@ Template Naming and Locations By default, templates can live in two different locations: -* ``app/Resources/views/``: The applications ``views`` directory can contain - application-wide base templates (i.e. your application's layouts and - templates of the application bundle) as well as templates that override - third party bundle templates (see :ref:`overriding-bundle-templates`); +``app/Resources/views/`` + The applications ``views`` directory can contain application-wide base templates + (i.e. your application's layouts and templates of the application bundle) as + well as templates that override third party bundle templates + (see :ref:`overriding-bundle-templates`). -* ``path/to/bundle/Resources/views/``: Each third party bundle houses its - templates in its ``Resources/views/`` directory (and subdirectories). When you - plan to share your bundle, you should put the templates in the bundle instead - of the ``app/`` directory. +``path/to/bundle/Resources/views/`` + Each third party bundle houses its templates in its ``Resources/views/`` + directory (and subdirectories). When you plan to share your bundle, you should + put the templates in the bundle instead of the ``app/`` directory. Most of the templates you'll use live in the ``app/Resources/views/`` directory. The path you'll use will be relative to this directory. For example, @@ -1123,12 +1124,18 @@ is a :class:`Symfony\\Bundle\\FrameworkBundle\\Templating\\GlobalVariables` instance which will give you access to some application specific variables automatically: -* ``app.security`` - The security context. -* ``app.user`` - The current user object. -* ``app.request`` - The request object. -* ``app.session`` - The session object. -* ``app.environment`` - The current environment (dev, prod, etc). -* ``app.debug`` - True if in debug mode. False otherwise. +``app.security`` + The security context. +``app.user`` + The current user object. +``app.request`` + The request object. +``app.session`` + The session object. +``app.environment`` + The current environment (dev, prod, etc). +``app.debug`` + True if in debug mode. False otherwise. .. configuration-block:: diff --git a/book/validation.rst b/book/validation.rst index 0cd59ae5aea..43d231ec393 100644 --- a/book/validation.rst +++ b/book/validation.rst @@ -809,14 +809,15 @@ user registers and when a user updates their contact information later: With this configuration, there are three validation groups: -* ``Default`` - contains the constraints in the current class and all - referenced classes that belong to no other group; +``Default`` + Contains the constraints in the current class and all referenced classes + that belong to no other group. -* ``User`` - equivalent to all constraints of the ``User`` object in the - ``Default`` group; +``User`` + Equivalent to all constraints of the ``User`` object in the ``Default`` group. -* ``registration`` - contains the constraints on the ``email`` and ``password`` - fields only. +``registration`` + Contains the constraints on the ``email`` and ``password`` fields only. To tell the validator to use a specific group, pass one or more group names as the second argument to the ``validate()`` method::