Merge remote-tracking branch 'upstream/2.7' into 2.7

Author: javiereguiluz

components/console/helpers/dialoghelper.rst

@@ -142,11 +142,15 @@ in the console, so it is a good practice to put some useful information in it. T
 function should also return the value of the user's input if the validation was successful.
 
 You can set the max number of times to ask in the ``$attempts`` argument.
-If you reach this max number it will use the default value.
 Using ``false`` means the amount of attempts is infinite.
 The user will be asked as long as they provide an invalid answer and will only
 be able to proceed if their input is valid.
 
+Each time the user is asked the question, the default one is used if no answer
+is supplied (and validated with the ``$validator`` callback). If the last
+attempt is reached, the application will throw an exception and ends its
+execution.
+
 Validating a Hidden Response
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

components/validator.rst

@@ -46,6 +46,8 @@ characters long::
         }
     }
 
+The validator returns the list of violations.
+
 Retrieving a Validator Instance
 -------------------------------
 

contributing/code/standards.rst

@@ -225,7 +225,8 @@ Service Naming Conventions
 Documentation
 -------------
 
-* Add PHPDoc blocks for all classes, methods, and functions;
+* Add PHPDoc blocks for all classes, methods, and functions (though you may
+  be asked to remove PHPDoc that do not add value);
 
 * Group annotations together so that annotations of the same type immediately
   follow each other, and annotations of a different type are separated by a

controller/service.rst

@@ -23,17 +23,19 @@ These are the main **advantages** of defining controllers as services:
   service container configuration. This is useful when developing reusable bundles;
 * Your controllers are more "sandboxed". By looking at the constructor arguments,
   it's easy to see what types of things this controller may or may not do;
+* If you're not passing some required dependencies or if you are injecting some
+  non-existent services, you'll get errors during the container compilation
+  instead of during runtime execution;
 * Since dependencies must be injected manually, it's more obvious when your
   controller is becoming too big (i.e. if you have many constructor arguments).
 
 These are the main **drawbacks** of defining controllers as services:
 
-* It takes more work to create the controllers because they don't have
-  automatic access to the services or to the base controller shortcuts;
+* It takes more work to create the controllers and they become more verbose
+  because they don't have automatic access to the services and the base
+  controller shortcuts;
 * The constructor of the controllers can rapidly become too complex because you
-  must inject every single dependency needed by them;
-* The code of the controllers is more verbose because you can't use the shortcuts
-  of the base controller and you must replace them with some lines of code.
+  must inject every single dependency needed by them.
 
 The recommendation from the :doc:`best practices </best_practices/controllers>`
 is also valid for controllers defined as services: avoid putting your business

forms.rst

@@ -568,10 +568,10 @@ the correct values of a number of field options.
     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).
+``maxlength``
+    If the field is some sort of text field, then the ``maxlength`` option attribute
+    can be guessed from the validation constraints (if ``Length`` or ``Range`` is used)
+    or from the Doctrine metadata (via the field's length).
 
 .. caution::
 

page_creation.rst

@@ -63,12 +63,7 @@ random) number and prints it. To do that, create a "Controller class" and a
 Before diving into this, test it out! If you are using PHP's internal web server
 go to:
 
-    http://localhost:8000/app_dev.php/lucky/number
-
-.. tip::
-
-    If you're using the built-in PHP web-server, you can omit the ``app_dev.php``
-    part of the URL.
+    http://localhost:8000/lucky/number
 
 If you see a lucky number being printed back to you, congratulations! But before
 you run off to play the lottery, check out how this works. Remember the two steps

reference/configuration/security.rst

@@ -348,7 +348,14 @@ use_referer
 **type**: ``boolean`` **default**: ``false``
 
 If ``true``, the user is redirected to the value stored in the ``HTTP_REFERER``
-header when no previous URL was stored in the session.
+header when no previous URL was stored in the session. If the referrer URL is
+the same as the one generated with the ``login_path`` route, the user is
+redirected to the ``default_target_path`` to avoid a redirection loop.
+
+.. note::
+
+    For historical reasons, and to match the misspelling of the HTTP standard,
+    the option is called ``use_referer`` instead of ``use_referrer``.
 
 .. _reference-security-pbkdf2:
 

reference/constraints/Blank.rst

@@ -1,10 +1,18 @@
 Blank
 =====
 
-Validates that a value is blank, defined as equal to a blank string or equal
-to ``null``. To force that a value strictly be equal to ``null``, see the
-:doc:`/reference/constraints/IsNull` constraint. To force that a value is
-*not* blank, see :doc:`/reference/constraints/NotBlank`.
+Validates that a value is blank - meaning equal to an empty string or ``null``::
+
+    if ('' !== $value && null !== $value) {
+        // validation will fail
+    }
+
+To force that a value strictly be equal to ``null``, see the
+:doc:`/reference/constraints/IsNull` constraint.
+
+
+To force that a value is *not* blank, see :doc:`/reference/constraints/NotBlank`.
+But be careful as ``NotBlank`` is *not* strictly the opposite of ``Blank``.
 
 +----------------+---------------------------------------------------------------------+
 | Applies to     | :ref:`property or method <validation-property-target>`              |

reference/constraints/NotBlank.rst

@@ -1,9 +1,14 @@
 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
+Validates that a value is not blank - meaning not equal to a blank string,
+a blank array or ``null``::
+
+    if (false === $value || (empty($value) && '0' != $value)) {
+        // validation will fail
+    }
+
+To force that a value is simply not equal to ``null``, see the
 :doc:`/reference/constraints/NotNull` constraint.
 
 +----------------+------------------------------------------------------------------------+

reference/dic_tags.rst

@@ -1000,6 +1000,10 @@ and :class:`Symfony\\Component\\Serializer\\Normalizer\\DenormalizerInterface`.
 
 For more details, see :doc:`/serializer`.
 
+The priorities of the default normalizers can be found in the
+:method:`Symfony\\Bundle\\FrameworkBundle\\DependencyInjection\\FrameworkExtension::registerSerializerConfiguration`
+method.
+
 swiftmailer.default.plugin
 --------------------------