Merge pull request #3174 from bicpi/another_fixing_typos_formatting_logic_collection

weaverryan · weaverryan · commit 0eb25311dd58 · 2013-11-13T05:49:27.000-08:00
Another collection of fixes: Typos, Formatting, Logic, Links
diff --git a/components/dependency_injection/workflow.rst b/components/dependency_injection/workflow.rst
@@ -64,7 +64,7 @@ Compiler passes to allow Interaction between Bundles
 :ref:`Compiler passes <components-dependency-injection-compiler-passes>` are
 used to allow interaction between different bundles as they cannot affect
 each other's configuration in the extension classes. One of the main uses is
-to process tagged services, allowing bundles to register services to picked
+to process tagged services, allowing bundles to register services to be picked
 up by other bundles, such as Monolog loggers, Twig extensions and Data Collectors
 for the Web Profiler. Compiler passes are usually placed in the bundle's
 ``DependencyInjection/Compiler`` directory.
diff --git a/components/http_foundation/introduction.rst b/components/http_foundation/introduction.rst
@@ -322,7 +322,7 @@ Sending the response to the client is then as simple as calling
 Setting Cookies
 ~~~~~~~~~~~~~~~
 
-The response cookies can be manipulated though the ``headers`` public
+The response cookies can be manipulated through the ``headers`` public
 attribute::
 
     use Symfony\Component\HttpFoundation\Cookie;
diff --git a/components/security/authorization.rst b/components/security/authorization.rst
@@ -26,7 +26,7 @@ An authorization decision will always be based on a few things:
     Each attribute stands for a certain right the user should have, e.g.
     ``ROLE_ADMIN`` to make sure the user is an administrator.
 * An object (optional)
-    Any object on which for which access control needs to be checked, like
+    Any object for which access control needs to be checked, like
     an article or a comment object.
 
 .. _components-security-access-decision-manager:
diff --git a/components/security/firewall.rst b/components/security/firewall.rst
@@ -127,11 +127,11 @@ Flow: Firewall, Authentication, Authorization
 Hopefully you can now see a little bit about how the "flow" of the security
 context works:
 
-#. the Firewall is registered as a listener on the ``kernel.request`` event;
-#. at the beginning of the request, the Firewall checks the firewall map
+#. The Firewall is registered as a listener on the ``kernel.request`` event;
+#. At the beginning of the request, the Firewall checks the firewall map
    to see if any firewall should be active for this URL;
-#. If a firewall is found in the map for this URL, its listeners are notified
-#. each listener checks to see if the current request contains any authentication
+#. If a firewall is found in the map for this URL, its listeners are notified;
+#. Each listener checks to see if the current request contains any authentication
    information - a listener may (a) authenticate a user, (b) throw an
    ``AuthenticationException``, or (c) do nothing (because there is no
    authentication information on the request);
diff --git a/cookbook/controller/service.rst b/cookbook/controller/service.rst
@@ -112,13 +112,13 @@ the route ``_controller`` value:
 
         # app/config/routing.yml
         hello:
-            pattern:      /hello
+            path:         /hello
             defaults:     { _controller: acme.hello.controller:indexAction }
 
     .. code-block:: xml
 
         <!-- app/config/routing.xml -->
-        <route id="hello" pattern="/hello">
+        <route id="hello" path="/hello">
             <default key="_controller">acme.hello.controller:indexAction</default>
         </route>
 
diff --git a/cookbook/doctrine/registration_form.rst b/cookbook/doctrine/registration_form.rst
@@ -310,12 +310,12 @@ Next, update your routes. If you're placing your routes inside your bundle
 
         # src/Acme/AccountBundle/Resources/config/routing.yml
         account_register:
-           pattern:  /register
-           defaults: { _controller: AcmeAccountBundle:Account:register }
+            path:     /register
+            defaults: { _controller: AcmeAccountBundle:Account:register }
    
         account_create:
-           pattern:  /register/create
-           defaults: { _controller: AcmeAccountBundle:Account:create }
+            path:     /register/create
+            defaults: { _controller: AcmeAccountBundle:Account:create }
 
     .. code-block:: xml
 
diff --git a/reference/configuration/doctrine.rst b/reference/configuration/doctrine.rst
@@ -405,6 +405,6 @@ which is the first one defined or the one configured via the
 ``default_connection`` parameter.
 
 Each connection is also accessible via the ``doctrine.dbal.[name]_connection``
-service where ``[name]`` if the name of the connection.
+service where ``[name]`` is the name of the connection.
 
 .. _DBAL documentation: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html
diff --git a/reference/configuration/swiftmailer.rst b/reference/configuration/swiftmailer.rst
@@ -100,8 +100,8 @@ type
 
 **type**: ``string`` **default**: ``file``
 
-The method used to store spooled messages. Currently only ``file`` is supported.
-However, a custom spool should be possible by creating a service called
+The method used to store spooled messages. Valid values are ``memory`` and
+``file``. A custom spool should be possible by creating a service called
 ``swiftmailer.spool.myspool`` and setting this value to ``myspool``.
 
 path
diff --git a/reference/constraints/False.rst b/reference/constraints/False.rst
@@ -45,7 +45,7 @@ method returns **false**:
         Acme\BlogBundle\Entity\Author
             getters:
                 stateInvalid:
-                    - "False":
+                    - 'False':
                         message: You've entered an invalid state.
 
     .. code-block:: php-annotations
@@ -103,8 +103,8 @@ method returns **false**:
 
 .. caution::
 
-    When using YAML, be sure to surround ``False`` with quotes (``"False"``)
-    or else YAML will convert this into a Boolean value.
+    When using YAML, be sure to surround ``False`` with quotes (``'False'``)
+    or else YAML will convert this into a ``false`` Boolean value.
 
 Options
 -------
diff --git a/reference/constraints/File.rst b/reference/constraints/File.rst
@@ -177,7 +177,7 @@ If set, the validator will check that the mime type of the underlying file
 is equal to the given mime type (if a string) or exists in the collection
 of given mime types (if an array).
 
-You can find a list of existing mime types on the `IANA website`_
+You can find a list of existing mime types on the `IANA website`_.
 
 maxSizeMessage
 ~~~~~~~~~~~~~~
diff --git a/reference/constraints/Length.rst b/reference/constraints/Length.rst
@@ -134,14 +134,14 @@ is used.
 minMessage
 ~~~~~~~~~~
 
-**type**: ``string`` **default**: ``This value is too short. It should have {{ limit }} characters or more.``.
+**type**: ``string`` **default**: ``This value is too short. It should have {{ limit }} characters or more.``
 
 The message that will be shown if the underlying value's length is less than the `min`_ option.
 
 maxMessage
 ~~~~~~~~~~
 
-**type**: ``string`` **default**: ``This value is too long. It should have {{ limit }} characters or less.``.
+**type**: ``string`` **default**: ``This value is too long. It should have {{ limit }} characters or less.``
 
 The message that will be shown if the underlying value's length is more than the `max`_ option.
 
diff --git a/reference/constraints/Null.rst b/reference/constraints/Null.rst
@@ -77,6 +77,11 @@ of an ``Author`` class exactly equal to ``null``, you could do the following:
             }
         }
 
+.. caution::
+
+    When using YAML, be sure to surround ``Null`` with quotes (``'Null'``)
+    or else YAML will convert this into a ``null`` value.
+
 Options
 -------
 
diff --git a/reference/constraints/Regex.rst b/reference/constraints/Regex.rst
@@ -188,9 +188,9 @@ will convert the pattern given in the `pattern`_ option into an HTML5 compatible
 pattern. This means that the delimiters are removed (e.g. ``/[a-z]+/`` becomes ``[a-z]+``).
 
 However, there are some other incompatibilities between both patterns which
-cannot be fixed by the constraint. For instance, the html5 pattern attribute
+cannot be fixed by the constraint. For instance, the HTML5 ``pattern`` attribute
 does not support flags. If you have a pattern like ``/[a-z]+/i`` you need to
-specify the html5 compatible pattern in the ``htmlPattern`` option:
+specify the HTML5 compatible pattern in the ``htmlPattern`` option:
 
 .. configuration-block::
 
diff --git a/reference/constraints/True.rst b/reference/constraints/True.rst
@@ -50,7 +50,7 @@ Then you can constrain this method with ``True``.
         Acme\BlogBundle\Entity\Author:
             getters:
                 tokenValid:
-                    - "True": { message: "The token is invalid." }
+                    - 'True': { message: "The token is invalid." }
 
     .. code-block:: php-annotations
 
@@ -116,6 +116,11 @@ Then you can constrain this method with ``True``.
 
 If the ``isTokenValid()`` returns false, the validation will fail.
 
+.. caution::
+
+    When using YAML, be sure to surround ``True`` with quotes (``'True'``)
+    or else YAML will convert this into a ``true`` Boolean value.
+
 Options
 -------
 
diff --git a/reference/constraints/UniqueEntity.rst b/reference/constraints/UniqueEntity.rst
@@ -167,8 +167,8 @@ errorPath
 .. versionadded:: 2.1
     The ``errorPath`` option was added in Symfony 2.1.
 
-If the entity violates constraint the error message is bound to the first
-field in `fields`_. If there are more than one fields, you may want to map
+If the entity violates the constraint the error message is bound to the first
+field in `fields`_. If there is more than one field, you may want to map
 the error message to another field.
 
 Consider this example:
diff --git a/reference/forms/types/collection.rst b/reference/forms/types/collection.rst
@@ -202,7 +202,7 @@ you need is the JavaScript:
     is automatically available on the ``data-prototype`` attribute of the
     element (e.g. ``div`` or ``table``) that surrounds your collection. The
     only difference is that the entire "form row" is rendered for you, meaning
-    you wouldn't have to wrap it in any container element as was done
+    you wouldn't have to wrap it in any container element as it was done
     above.
 
 Field Options
diff --git a/reference/forms/types/integer.rst b/reference/forms/types/integer.rst
@@ -13,7 +13,7 @@ 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 (e.g. 6).
 
 +-------------+-----------------------------------------------------------------------+
-| Rendered as | ``input`` ``text`` field                                              |
+| Rendered as | ``input`` ``number`` field                                            |
 +-------------+-----------------------------------------------------------------------+
 | Options     | - `rounding_mode`_                                                    |
 |             | - `precision`_                                                        |
diff --git a/reference/forms/types/options/attr.rst.inc b/reference/forms/types/options/attr.rst.inc
@@ -3,9 +3,9 @@ attr
 
 **type**: array **default**: Empty array
 
-If you want to add extra attributes to HTML field representation
-you can use ``attr`` option. It's an associative array with HTML attribute
-as a key. This can be useful when you need to set a custom class for some widget::
+If you want to add extra attributes to an HTML field representation
+you can use the ``attr`` option. It's an associative array with HTML attributes
+as keys. This can be useful when you need to set a custom class for some widget::
 
     $builder->add('body', 'textarea', array(
         'attr' => array('class' => 'tinymce'),
diff --git a/reference/forms/types/options/date_widget.rst.inc b/reference/forms/types/options/date_widget.rst.inc
@@ -5,10 +5,10 @@ widget
 
 The basic way in which this field should be rendered. Can be one of the following:
 
-* ``choice``: renders three select inputs.  The order of the selects is defined
+* ``choice``: renders three select inputs. The order of the selects is defined
   in the `format`_ option.
 
-* ``text``: renders a three field input of type text (month, day, year).
+* ``text``: renders a three field input of type ``text`` (month, day, year).
 
-* ``single_text``: renders a single input of type date (text in Symfony 2.0). User's 
-  input is validated based on the `format`_ option.
+* ``single_text``: renders a single input of type ``date`` (``text`` in Symfony 2.0).
+  User's input is validated based on the `format`_ option.
diff --git a/reference/forms/types/options/error_mapping.rst.inc b/reference/forms/types/options/error_mapping.rst.inc
@@ -1,11 +1,11 @@
-.. versionadded:: 2.1
-    The ``error_mapping`` option is new to Symfony 2.1.
-
 error_mapping
 ~~~~~~~~~~~~~
 
 **type**: ``array`` **default**: ``empty``
 
+.. versionadded:: 2.1
+    The ``error_mapping`` option is new to Symfony 2.1.
+
 This option allows you to modify the target of a validation error.
 
 Imagine you have a custom method named ``matchingCityAndZipCode`` that validates
