From 74267cdf612f079d2d72f9573330298aa14a6a18 Mon Sep 17 00:00:00 2001 From: WouterJ Date: Thu, 25 Jun 2015 16:12:57 +0200 Subject: [PATCH 1/3] Fixes due to docbot linting docs --- reference/constraints/Length.rst | 6 +- reference/constraints/NotBlank.rst | 8 +-- reference/forms/twig_reference.rst | 92 ++++++++++++++++++------------ reference/forms/types/checkbox.rst | 6 +- reference/forms/types/choice.rst | 16 +++--- reference/forms/types/integer.rst | 8 +-- 6 files changed, 78 insertions(+), 58 deletions(-) diff --git a/reference/constraints/Length.rst b/reference/constraints/Length.rst index 82d30261827..455f8c882e1 100644 --- a/reference/constraints/Length.rst +++ b/reference/constraints/Length.rst @@ -115,9 +115,9 @@ min This required option is the "min" length value. Validation will fail if the given value's length is **less** than this min value. -It is important to notice that NULL values and empty strings are considered -valid no matter if the constraint required a minimum length. Validators are -triggered only if the value is not blank. +It is important to notice that NULL values and empty strings are considered +valid no matter if the constraint required a minimum length. Validators +are triggered only if the value is not blank. max ~~~ diff --git a/reference/constraints/NotBlank.rst b/reference/constraints/NotBlank.rst index f171526f047..c00e5fb1f6d 100644 --- a/reference/constraints/NotBlank.rst +++ b/reference/constraints/NotBlank.rst @@ -1,10 +1,10 @@ NotBlank ======== -Validates that a value is not blank, defined as not strictly ``false``, not -equal to a blank string and also not equal to ``null``. To force that a value -is simply not equal to ``null``, see the :doc:`/reference/constraints/NotNull` -constraint. +Validates that a value is not blank, defined as not strictly ``false``, +not equal to a blank string and also not equal to ``null``. To force that +a value is simply not equal to ``null``, see the +:doc:`/reference/constraints/NotNull` constraint. +----------------+------------------------------------------------------------------------+ | Applies to | :ref:`property or method ` | diff --git a/reference/forms/twig_reference.rst b/reference/forms/twig_reference.rst index 9abf4c27b4c..80010c8b914 100644 --- a/reference/forms/twig_reference.rst +++ b/reference/forms/twig_reference.rst @@ -4,15 +4,17 @@ Twig Template Form Function and Variable Reference ================================================== -When working with forms in a template, there are two powerful things at your -disposal: +When working with forms in a template, there are two powerful things at +your disposal: -* :ref:`Functions ` for rendering each part of a form -* :ref:`Variables ` for getting *any* information about any field +* :ref:`Functions ` for rendering each part + of a form; +* :ref:`Variables ` for getting *any* information + about any field. You'll use functions often to render your fields. Variables, on the other hand, are less commonly-used, but infinitely powerful since you can access -a fields label, id attribute, errors, and anything else about the field. +a fields label, id attribute, errors and anything else about the field. .. _reference-form-twig-functions: @@ -20,9 +22,9 @@ Form Rendering Functions ------------------------ This reference manual covers all the possible Twig functions available for -rendering forms. There are several different functions available, and each -is responsible for rendering a different part of a form (e.g. labels, errors, -widgets, etc). +rendering forms. There are several different functions available and +each is responsible for rendering a different part of a form (e.g. labels, +errors, widgets, etc). .. _reference-forms-twig-form: @@ -76,8 +78,8 @@ Renders the end tag of a form. {{ form_end(form) }} -This helper also outputs ``form_rest()`` unless you set ``render_rest`` to -false: +This helper also outputs ``form_rest()`` unless you set ``render_rest`` +to false: .. code-block:: jinja @@ -98,7 +100,11 @@ label you want to display as the second argument. {# The two following syntaxes are equivalent #} {{ form_label(form.name, 'Your Name', {'label_attr': {'class': 'foo'}}) }} - {{ form_label(form.name, null, {'label': 'Your name', 'label_attr': {'class': 'foo'}}) }} + + {{ form_label(form.name, null, { + 'label': 'Your name', + 'label_attr': {'class': 'foo'} + }) }} See ":ref:`twig-reference-form-variables`" to learn about the ``variables`` argument. @@ -122,8 +128,8 @@ Renders any errors for the given field. form_widget(view, variables) ---------------------------- -Renders the HTML widget of a given field. If you apply this to an entire form -or collection of fields, each underlying form row will be rendered. +Renders the HTML widget of a given field. If you apply this to an entire +form or collection of fields, each underlying form row will be rendered. .. code-block:: jinja @@ -181,8 +187,8 @@ form_enctype(view) .. note:: - This helper was deprecated in Symfony 2.3 and will be removed in Symfony 3.0. - You should use ``form_start()`` instead. + This helper was deprecated in Symfony 2.3 and will be removed in Symfony + 3.0. You should use ``form_start()`` instead. If the form contains at least one file upload field, this will render the required ``enctype="multipart/form-data"`` form attribute. It's always a @@ -204,7 +210,8 @@ selectedchoice(selected_value) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This test will check if the current choice is equal to the ``selected_value`` -or if the current choice is in the array (when ``selected_value`` is an array). +or if the current choice is in the array (when ``selected_value`` is an +array). .. code-block:: jinja @@ -221,7 +228,7 @@ More about Form Variables In almost every Twig function above, the final argument is an array of "variables" that are used when rendering that one part of the form. For example, the -following would render the "widget" for a field, and modify its attributes +following would render the "widget" for a field and modify its attributes to include a special class: .. code-block:: jinja @@ -242,41 +249,52 @@ Look at the ``form_label`` as an example: {% if not compound %} {% set label_attr = label_attr|merge({'for': id}) %} {% endif %} + {% if required %} - {% set label_attr = label_attr|merge({'class': (label_attr.class|default('') ~ ' required')|trim}) %} + {% set label_attr = label_attr|merge({ + 'class': (label_attr.class|default('') ~ ' required')|trim + }) %} {% endif %} + {% if label is empty %} {% set label = name|humanize %} {% endif %} - {{ label|trans({}, translation_domain) }} + + {% endblock form_label %} -This block makes use of several variables: ``compound``, ``label_attr``, ``required``, -``label``, ``name`` and ``translation_domain``. -These variables are made available by the form rendering system. But more -importantly, these are the variables that you can override when calling ``form_label`` -(since in this example, you're rendering the label). +This block makes use of several variables: ``compound``, ``label_attr``, +``required``, ``label``, ``name`` and ``translation_domain``. These variables +are made available by the form rendering system. But more importantly, these +are the variables that you can override when calling ``form_label`` (since +in this example, you're rendering the label). The exact variables available to override depends on which part of the form you're rendering (e.g. label versus widget) and which field you're rendering -(e.g. a ``choice`` widget has an extra ``expanded`` option). If you get comfortable -with looking through `form_div_layout.html.twig`_, you'll always be able -to see what options you have available. +(e.g. a ``choice`` widget has an extra ``expanded`` option). If you get +comfortable with looking through `form_div_layout.html.twig`_, you'll always +be able to see what options you have available. .. tip:: Behind the scenes, these variables are made available to the ``FormView`` - object of your form when the Form component calls ``buildView`` and ``finishView`` - on each "node" of your form tree. To see what "view" variables a particular - field has, find the source code for the form field (and its parent fields) - and look at the above two functions. + object of your form when the Form component calls ``buildView`` and + ``finishView`` on each "node" of your form tree. To see what "view" + variables a particular field has, find the source code for the form + field (and its parent fields) and look at the above two functions. .. note:: If you're rendering an entire form at once (or an entire embedded form), the ``variables`` argument will only be applied to the form itself and - not its children. In other words, the following will **not** pass a "foo" - class attribute to all of the child fields in the form: + not its children. In other words, the following will **not** pass a + "foo" class attribute to all of the child fields in the form: .. code-block:: jinja @@ -292,10 +310,10 @@ The following variables are common to every field type. Certain field types may have even more variables and some variables here only really apply to certain types. -Assuming you have a ``form`` variable in your template, and you want to reference -the variables on the ``name`` field, accessing the variables is done by using -a public ``vars`` property on the :class:`Symfony\\Component\\Form\\FormView` -object: +Assuming you have a ``form`` variable in your template and you want to +reference the variables on the ``name`` field, accessing the variables is +done by using a public ``vars`` property on the +:class:`Symfony\\Component\\Form\\FormView` object: .. configuration-block:: diff --git a/reference/forms/types/checkbox.rst b/reference/forms/types/checkbox.rst index abef5a25330..b0c657a2add 100644 --- a/reference/forms/types/checkbox.rst +++ b/reference/forms/types/checkbox.rst @@ -4,9 +4,9 @@ checkbox Field Type =================== -Creates a single input checkbox. This should always be used for a field that -has a boolean value: if the box is checked, the field will be set to true, -if the box is unchecked, the value will be set to false. +Creates a single input checkbox. This should always be used for a field +that has a boolean value: if the box is checked, the field will be set to +true, if the box is unchecked, the value will be set to false. +-------------+------------------------------------------------------------------------+ | Rendered as | ``input`` ``checkbox`` field | diff --git a/reference/forms/types/choice.rst b/reference/forms/types/choice.rst index 82c18c6ff92..949e2b437d7 100644 --- a/reference/forms/types/choice.rst +++ b/reference/forms/types/choice.rst @@ -109,15 +109,17 @@ The ``choice_list`` option must be an instance of the ``ChoiceListInterface``. For more advanced cases, a custom class that implements the interface can be created to supply the choices. -With this option you can also allow float values to be selected as data. For example: - -.. code-block:: php +With this option you can also allow float values to be selected as data. +For example:: use Symfony\Component\Form\Extension\Core\ChoiceList\ChoiceList; // ... $builder->add('status', 'choice', array( - 'choice_list' => new ChoiceList(array(1, 0.5, 0.1), array('Full', 'Half', 'Almost empty')) + 'choice_list' => new ChoiceList( + array(1, 0.5, 0.1), + array('Full', 'Half', 'Almost empty') + ) )); The ``status`` field created by the code above will be rendered as: @@ -130,9 +132,9 @@ The ``status`` field created by the code above will be rendered as: -But don't be confused! If ``Full`` is selected (value ``0`` in HTML), ``1`` will -be returned in your form. If ``Almost empty`` is selected (value ``2`` in HTML), -``0.1`` will be returned. +But don't be confused! If ``Full`` is selected (value ``0`` in HTML), ``1`` +will be returned in your form. If ``Almost empty`` is selected (value ``2`` +in HTML), ``0.1`` will be returned. .. include:: /reference/forms/types/options/empty_value.rst.inc diff --git a/reference/forms/types/integer.rst b/reference/forms/types/integer.rst index e6ea1895cb5..29f7609d6dd 100644 --- a/reference/forms/types/integer.rst +++ b/reference/forms/types/integer.rst @@ -4,10 +4,10 @@ integer Field Type ================== -Renders an input "number" field. Basically, this is a text field that's good -at handling data that's in an integer form. The input ``number`` field looks -like a text box, except that - if the user's browser supports HTML5 - it will -have some extra front-end functionality. +Renders an input "number" field. Basically, this is a text field that's +good at handling data that's in an integer form. The input ``number`` field +looks like a text box, except that - if the user's browser supports HTML5 +- it will have some extra front-end functionality. This field has different options on how to handle input values that aren't integers. By default, all non-integer values (e.g. 6.78) will round down From 63ccd0d938df53b4db492d523e0073b4bc16e863 Mon Sep 17 00:00:00 2001 From: WouterJ Date: Thu, 25 Jun 2015 16:36:57 +0200 Subject: [PATCH 2/3] Finalize review of reference documentation --- reference/configuration/doctrine.rst | 126 ++++++++++++----------- reference/configuration/security.rst | 22 ++-- reference/configuration/swiftmailer.rst | 36 ++++--- reference/configuration/twig.rst | 12 ++- reference/configuration/web_profiler.rst | 11 +- reference/dic_tags.rst | 4 +- reference/events.rst | 26 ++--- reference/map.rst.inc | 8 +- 8 files changed, 133 insertions(+), 112 deletions(-) diff --git a/reference/configuration/doctrine.rst b/reference/configuration/doctrine.rst index 88e83838ba1..1a329f7aa57 100644 --- a/reference/configuration/doctrine.rst +++ b/reference/configuration/doctrine.rst @@ -324,8 +324,8 @@ you can control. The following configuration options exist for a mapping: type .... -One of ``annotation``, ``xml``, ``yml``, ``php`` or ``staticphp``. This specifies -which type of metadata type your mapping uses. +One of ``annotation``, ``xml``, ``yml``, ``php`` or ``staticphp``. This +specifies which type of metadata type your mapping uses. dir ... @@ -339,18 +339,18 @@ that exist in the DIC (for example ``%kernel.root_dir%``). prefix ...... -A common namespace prefix that all entities of this mapping share. This prefix -should never conflict with prefixes of other defined mappings otherwise some -of your entities cannot be found by Doctrine. This option defaults to the -bundle namespace + ``Entity``, for example for an application bundle called -AcmeHelloBundle prefix would be ``Acme\HelloBundle\Entity``. +A common namespace prefix that all entities of this mapping share. This +prefix should never conflict with prefixes of other defined mappings otherwise +some of your entities cannot be found by Doctrine. This option defaults +to the bundle namespace + ``Entity``, for example for an application bundle +called AcmeHelloBundle prefix would be ``Acme\HelloBundle\Entity``. alias ..... Doctrine offers a way to alias entity namespaces to simpler, shorter names -to be used in DQL queries or for Repository access. When using a bundle the -alias defaults to the bundle name. +to be used in DQL queries or for Repository access. When using a bundle +the alias defaults to the bundle name. is_bundle ......... @@ -358,8 +358,8 @@ is_bundle This option is a derived value from ``dir`` and by default is set to ``true`` if dir is relative proved by a ``file_exists()`` check that returns ``false``. It is ``false`` if the existence check returns ``true``. In this case an -absolute path was specified and the metadata files are most likely in a directory -outside of a bundle. +absolute path was specified and the metadata files are most likely in a +directory outside of a bundle. .. index:: single: Configuration; Doctrine DBAL @@ -448,14 +448,15 @@ The following block shows all possible configuration keys: .. note:: - The ``server_version`` option was added in Doctrine DBAL 2.5, which is used - by DoctrineBundle 1.3. The value of this option should match your database - server version (use ``postgres -V`` or ``psql -V`` command to find - your PostgreSQL version and ``mysql -V`` to get your MySQL version). + The ``server_version`` option was added in Doctrine DBAL 2.5, which + is used by DoctrineBundle 1.3. The value of this option should match + your database server version (use ``postgres -V`` or ``psql -V`` command + to find your PostgreSQL version and ``mysql -V`` to get your MySQL + version). - If you don't define this option and you haven't created your database yet, - you may get ``PDOException`` errors because Doctrine will try to guess the - database server version automatically and none is available. + If you don't define this option and you haven't created your database + yet, you may get ``PDOException`` errors because Doctrine will try to + guess the database server version automatically and none is available. If you want to configure multiple connections in YAML, put them under the ``connections`` key and give them a unique name: @@ -524,24 +525,26 @@ Keep in mind that you can't use both syntaxes at the same time. Custom Mapping Entities in a Bundle ----------------------------------- -Doctrine's ``auto_mapping`` feature loads annotation configuration from the -``Entity/`` directory of each bundle *and* looks for other formats (e.g. YAML, XML) -in the ``Resources/config/doctrine`` directory. +Doctrine's ``auto_mapping`` feature loads annotation configuration from +the ``Entity/`` directory of each bundle *and* looks for other formats (e.g. +YAML, XML) in the ``Resources/config/doctrine`` directory. -If you store metadata somewhere else in your bundle, you can define your own mappings, -where you tell Doctrine exactly *where* to look, along with some other configurations. +If you store metadata somewhere else in your bundle, you can define your +own mappings, where you tell Doctrine exactly *where* to look, along with +some other configurations. -If you're using the ``auto_mapping`` configuration, you just need to overwrite the -configurations you want. In this case it's important that the key of the mapping -configurations corresponds to the name of the bundle. +If you're using the ``auto_mapping`` configuration, you just need to overwrite +the configurations you want. In this case it's important that the key of +the mapping configurations corresponds to the name of the bundle. -For example, suppose you decide to store your ``XML`` configuration for ``AppBundle`` entities -in the ``@AppBundle/SomeResources/config/doctrine`` directory instead: +For example, suppose you decide to store your ``XML`` configuration for +``AppBundle`` entities in the ``@AppBundle/SomeResources/config/doctrine`` +directory instead: .. configuration-block:: .. code-block:: yaml - + doctrine: # ... orm: @@ -552,22 +555,22 @@ in the ``@AppBundle/SomeResources/config/doctrine`` directory instead: AppBundle: type: xml dir: SomeResources/config/doctrine - + .. code-block:: xml - + - + - + .. code-block:: php - + $container->loadFromExtension('doctrine', array( 'orm' => array( 'auto_mapping' => true, @@ -582,13 +585,14 @@ Mapping Entities Outside of a Bundle You can also create new mappings, for example outside of the Symfony folder. -For example, the following looks for entity classes in the ``App\Entity`` namespace in the -``src/Entity`` directory and gives them an ``App`` alias (so you can say things like ``App:Post``): +For example, the following looks for entity classes in the ``App\Entity`` +namespace in the ``src/Entity`` directory and gives them an ``App`` alias +(so you can say things like ``App:Post``): .. configuration-block:: .. code-block:: yaml - + doctrine: # ... orm: @@ -601,16 +605,16 @@ For example, the following looks for entity classes in the ``App\Entity`` namesp is_bundle: false prefix: App\Entity alias: App - + .. code-block:: xml - + - + - - + .. code-block:: php - + $container->loadFromExtension('doctrine', array( 'orm' => array( 'auto_mapping' => true, @@ -641,31 +645,33 @@ For example, the following looks for entity classes in the ``App\Entity`` namesp Detecting a Mapping Configuration Format ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If the ``type`` on the bundle configuration isn't set, -the DoctrineBundle will try to detect the correct mapping configuration format for -the bundle. +If the ``type`` on the bundle configuration isn't set, the DoctrineBundle +will try to detect the correct mapping configuration format for the bundle. -DoctrineBundle will look for files matching ``*.orm.[FORMAT]`` (e.g. ``Post.orm.yml``) -in the configured ``dir`` of your mapping (if you're mapping a bundle, then ``dir`` is -relative to the bundle's directory). +DoctrineBundle will look for files matching ``*.orm.[FORMAT]`` (e.g. +``Post.orm.yml``) in the configured ``dir`` of your mapping (if you're mapping +a bundle, then ``dir`` is relative to the bundle's directory). The bundle looks for (in this order) XML, YAML and PHP files. -Using the ``auto_mapping`` feature, every bundle can have only one configuration format. -The bundle will stop as soon as it locates one. +Using the ``auto_mapping`` feature, every bundle can have only one +configuration format. The bundle will stop as soon as it locates one. If it wasn't possible to determine a configuration format for a bundle, -the DoctrineBundle will check if there is an ``Entity`` folder in the bundle's root directory. -If the folder exist, Doctrine will fall back to using an annotation driver. +the DoctrineBundle will check if there is an ``Entity`` folder in the bundle's +root directory. If the folder exist, Doctrine will fall back to using an +annotation driver. -Default Value of dir +Default Value of Dir ~~~~~~~~~~~~~~~~~~~~ -If ``dir`` is not specified, then its default value depends on which configuration driver is being used. -For drivers that rely on the PHP files (annotation, staticphp) it will -be ``[Bundle]/Entity``. For drivers that are using configuration -files (XML, YAML, ...) it will be ``[Bundle]/Resources/config/doctrine``. +If ``dir`` is not specified, then its default value depends on which configuration +driver is being used. For drivers that rely on the PHP files (annotation, +staticphp) it will be ``[Bundle]/Entity``. For drivers that are using +configuration files (XML, YAML, ...) it will be +``[Bundle]/Resources/config/doctrine``. -If the ``dir`` configuration is set and the ``is_bundle`` configuration is ``true``, -the DoctrineBundle will prefix the ``dir`` configuration with the path of the bundle. +If the ``dir`` configuration is set and the ``is_bundle`` configuration +is ``true``, the DoctrineBundle will prefix the ``dir`` configuration with +the path of the bundle. .. _`DQL User Defined Functions`: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/dql-user-defined-functions.html diff --git a/reference/configuration/security.rst b/reference/configuration/security.rst index c3f174f4a98..544cc0ec865 100644 --- a/reference/configuration/security.rst +++ b/reference/configuration/security.rst @@ -4,10 +4,10 @@ SecurityBundle Configuration ("security") ========================================= -The security system is one of the most powerful parts of Symfony, and can +The security system is one of the most powerful parts of Symfony and can largely be controlled via its configuration. -Full default Configuration +Full Default Configuration -------------------------- The following is the full default configuration for the security system. @@ -306,8 +306,8 @@ post_only **type**: ``boolean`` **default**: ``true`` By default, you must submit your login form to the ``check_path`` URL as -a POST request. By setting this option to ``false``, you can send a GET request -to the ``check_path`` URL. +a POST request. By setting this option to ``false``, you can send a GET +request to the ``check_path`` URL. Redirecting after Login ~~~~~~~~~~~~~~~~~~~~~~~ @@ -328,7 +328,8 @@ Using the PBKDF2 Encoder: Security and Speed The `PBKDF2`_ encoder provides a high level of Cryptographic security, as recommended by the National Institute of Standards and Technology (NIST). -You can see an example of the ``pbkdf2`` encoder in the YAML block on this page. +You can see an example of the ``pbkdf2`` encoder in the YAML block on this +page. But using PBKDF2 also warrants a warning: using it (with a high number of iterations) slows down the process. Thus, PBKDF2 should be used with @@ -389,10 +390,11 @@ Using the BCrypt Password Encoder )); The ``cost`` can be in the range of ``4-31`` and determines how long a password -will be encoded. Each increment of ``cost`` *doubles* the time it takes to -encode a password. +will be encoded. Each increment of ``cost`` *doubles* the time it takes +to encode a password. -If you don't provide the ``cost`` option, the default cost of ``13`` is used. +If you don't provide the ``cost`` option, the default cost of ``13`` is +used. .. note:: @@ -418,8 +420,8 @@ Firewall Context Most applications will only need one :ref:`firewall `. But if your application *does* use multiple firewalls, you'll notice that if you're authenticated in one firewall, you're not automatically authenticated -in another. In other words, the systems don't share a common "context": each -firewall acts like a separate security system. +in another. In other words, the systems don't share a common "context": +each firewall acts like a separate security system. However, each firewall has an optional ``context`` key (which defaults to the name of the firewall), which is used when storing and retrieving security diff --git a/reference/configuration/swiftmailer.rst b/reference/configuration/swiftmailer.rst index ccadb7dcb69..bae46b9ba33 100644 --- a/reference/configuration/swiftmailer.rst +++ b/reference/configuration/swiftmailer.rst @@ -11,8 +11,9 @@ options, see `Full Default Configuration`_ The ``swiftmailer`` key configures Symfony's integration with Swift Mailer, which is responsible for creating and delivering email messages. -The following section lists all options that are available to configure a -mailer. It is also possible to configure several mailers (see `Using Multiple Mailers`_). +The following section lists all options that are available to configure +a mailer. It is also possible to configure several mailers (see +`Using Multiple Mailers`_). Configuration ------------- @@ -121,9 +122,9 @@ sender_address **type**: ``string`` -If set, all messages will be delivered with this address as the "return path" -address, which is where bounced messages should go. This is handled internally -by Swift Mailer's ``Swift_Plugins_ImpersonatePlugin`` class. +If set, all messages will be delivered with this address as the "return +path" address, which is where bounced messages should go. This is handled +internally by Swift Mailer's ``Swift_Plugins_ImpersonatePlugin`` class. antiflood ~~~~~~~~~ @@ -149,10 +150,10 @@ delivery_address **type**: ``string`` -If set, all email messages will be sent to this address instead of being sent -to their actual recipients. This is often useful when developing. For example, -by setting this in the ``config_dev.yml`` file, you can guarantee that all -emails sent during development go to a single account. +If set, all email messages will be sent to this address instead of being +sent to their actual recipients. This is often useful when developing. For +example, by setting this in the ``config_dev.yml`` file, you can guarantee +that all emails sent during development go to a single account. This uses ``Swift_Plugins_RedirectingPlugin``. Original recipients are available on the ``X-Swift-To``, ``X-Swift-Cc`` and ``X-Swift-Bcc`` headers. @@ -162,16 +163,17 @@ delivery_whitelist **type**: ``array`` -Used in combination with ``delivery_address``. If set, emails matching any of these -patterns will be delivered like normal, instead of being sent to ``delivery_address``. -For details, see :ref:`the cookbook entry. ` +Used in combination with ``delivery_address``. If set, emails matching any +of these patterns will be delivered like normal, instead of being sent to +``delivery_address``. For details, see +:ref:`the cookbook entry `. disable_delivery ~~~~~~~~~~~~~~~~ **type**: ``boolean`` **default**: ``false`` -If true, the ``transport`` will automatically be set to ``null``, and no +If true, the ``transport`` will automatically be set to ``null`` and no emails will actually be delivered. logging @@ -179,10 +181,10 @@ logging **type**: ``boolean`` **default**: ``%kernel.debug%`` -If true, Symfony's data collector will be activated for Swift Mailer and the -information will be available in the profiler. +If true, Symfony's data collector will be activated for Swift Mailer and +the information will be available in the profiler. -Full default Configuration +Full Default Configuration -------------------------- .. configuration-block:: @@ -240,7 +242,7 @@ Full default Configuration -Using multiple Mailers +Using Multiple Mailers ---------------------- You can configure multiple mailers by grouping them under the ``mailers`` diff --git a/reference/configuration/twig.rst b/reference/configuration/twig.rst index bad80fc4da2..2776df191d0 100644 --- a/reference/configuration/twig.rst +++ b/reference/configuration/twig.rst @@ -55,7 +55,15 @@ TwigBundle Configuration ("twig") xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd http://symfony.com/schema/dic/twig http://symfony.com/schema/dic/twig/twig-1.0.xsd"> - + MyBundle::form.html.twig @@ -98,7 +106,7 @@ Configuration .. _config-twig-exception-controller: exception_controller -.................... +~~~~~~~~~~~~~~~~~~~~ **type**: ``string`` **default**: ``twig.controller.exception:showAction`` diff --git a/reference/configuration/web_profiler.rst b/reference/configuration/web_profiler.rst index 50ad25c9043..25e8d853cd9 100644 --- a/reference/configuration/web_profiler.rst +++ b/reference/configuration/web_profiler.rst @@ -4,7 +4,7 @@ WebProfilerBundle Configuration ("web_profiler") ================================================ -Full default Configuration +Full Default Configuration -------------------------- .. configuration-block:: @@ -13,14 +13,17 @@ Full default Configuration web_profiler: - # DEPRECATED, it is not useful anymore and can be removed safely from your configuration + # DEPRECATED, it is not useful anymore and can be removed + # safely from your configuration verbose: true - # display the web debug toolbar at the bottom of pages with a summary of profiler info + # display the web debug toolbar at the bottom of pages with + # a summary of profiler info toolbar: false position: bottom - # gives you the opportunity to look at the collected data before following the redirect + # gives you the opportunity to look at the collected data + # before following the redirect intercept_redirects: false .. code-block:: xml diff --git a/reference/dic_tags.rst b/reference/dic_tags.rst index 47e8c43aebf..67a2a8aaa1b 100644 --- a/reference/dic_tags.rst +++ b/reference/dic_tags.rst @@ -552,8 +552,8 @@ article: :doc:`/cookbook/request/mime_type`. Core Event Listener Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For the reference of Event Listeners associated with each kernel event, see the -:doc:`Symfony Events Reference `. +For the reference of Event Listeners associated with each kernel event, +see the :doc:`Symfony Events Reference `. .. _dic-tags-kernel-event-subscriber: diff --git a/reference/events.rst b/reference/events.rst index 60740ac9fe0..dc32e2266b0 100644 --- a/reference/events.rst +++ b/reference/events.rst @@ -2,20 +2,20 @@ Symfony Framework Events ======================== When the Symfony Framework (or anything using the :class:`Symfony\\Component\\HttpKernel\\HttpKernel`) -handles a request, a few core events are dispatched so that you can add listeners -throughout the process. These are called the "kernel events". For a larger -explanation, see :doc:`/components/http_kernel/introduction`. +handles a request, a few core events are dispatched so that you can add +listeners throughout the process. These are called the "kernel events". +For a larger explanation, see :doc:`/components/http_kernel/introduction`. Kernel Events ------------- Each event dispatched by the kernel is a subclass of -:class:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent`. This means that -each event has access to the following information: +:class:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent`. This means +that each event has access to the following information: :method:`Symfony\\Component\\HttpKernel\\Event\\KernelEvent::getRequestType` - Returns the *type* of the request (``HttpKernelInterface::MASTER_REQUEST`` or - ``HttpKernelInterface::SUB_REQUEST``). + 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. @@ -87,8 +87,8 @@ Listener Class Name This event is not used by the FrameworkBundle, but it can be used to implement a view sub-system. This event is called *only* if the Controller does *not* -return a ``Response`` object. The purpose of the event is to allow some other -return value to be converted into a ``Response``. +return a ``Response`` object. The purpose of the event is to allow some +other return value to be converted into a ``Response``. The value returned by the Controller is accessible via the ``getControllerResult`` method:: @@ -115,8 +115,8 @@ method:: **Event Class**: :class:`Symfony\\Component\\HttpKernel\\Event\\FilterResponseEvent` -The purpose of this event is to allow other systems to modify or replace the -``Response`` object after its creation:: +The purpose of this event is to allow other systems to modify or replace +the ``Response`` object after its creation:: public function onKernelResponse(FilterResponseEvent $event) { @@ -137,8 +137,8 @@ The FrameworkBundle registers several listeners: 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. + Adds a ``Surrogate-Control`` HTTP header when the Response needs to + be parsed for ESI tags. .. seealso:: diff --git a/reference/map.rst.inc b/reference/map.rst.inc index 0bf22aa3b44..174cdd908cc 100644 --- a/reference/map.rst.inc +++ b/reference/map.rst.inc @@ -1,9 +1,9 @@ * **Configuration Options** - Ever wondered what configuration options you have available to you in files - such as ``app/config/config.yml``? In this section, all the available configuration - is broken down by the key (e.g. ``framework``) that defines each possible - section of your Symfony configuration. + Ever wondered what configuration options you have available to you in + files such as ``app/config/config.yml``? In this section, all the available + configuration is broken down by the key (e.g. ``framework``) that defines + each possible section of your Symfony configuration. * :doc:`framework ` * :doc:`doctrine ` From 9a94a41b7d19c7dccd81f4d4283da1feb936fa2b Mon Sep 17 00:00:00 2001 From: WouterJ Date: Thu, 25 Jun 2015 16:38:29 +0200 Subject: [PATCH 3/3] Review Quick Tour articles once again --- quick_tour/the_big_picture.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/quick_tour/the_big_picture.rst b/quick_tour/the_big_picture.rst index 1399307e3ef..1d61f21d5aa 100644 --- a/quick_tour/the_big_picture.rst +++ b/quick_tour/the_big_picture.rst @@ -106,12 +106,12 @@ Congratulations! Your first Symfony project is up and running! them are explained in the :ref:`Setting up Permissions ` section of the official book. - + If the welcome page does not seem to be rendering CSS or image assets, install them first: - + .. code-block:: bash - + $ php app/console assets:install When you are finished working on your Symfony application, you can stop