8000 Merge branch '2.7' into 2.8 · symfony/symfony-docs@7adc43d · GitHub
[go: up one dir, main page]
Skip to content

Commit 7adc43d

Browse files
xabbuhxabbuh
committed
Merge branch '2.7' into 2.8
* 2.7: [#6579] some tweaks Added callable validation_groups example Fix console.exception and console.terminate order Update options_resolver.rst Fixed a typo in cookbook/security/entity_provider Added a note about coding standards and method arguments reflect the EOM of Symfony 2.3
2 parents 0edf881 + f1329d0 commit 7adc43d

File tree

15 files changed

+134
-44
lines changed

15 files changed

+134
-44
lines changed

‎README.markdown

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,8 @@ Contributing
77
------------
88

99
>**Note**
10-
>Unless you're documenting a feature that was introduced *after* Symfony 2.3
11-
>(e.g. in Symfony 2.4), all pull requests must be based off of the **2.3** branch,
10+
>Unless you're documenting a feature that was introduced *after* Symfony 2.7
11+
>(e.g. in Symfony 2.8), all pull requests must be based off of the **2.7** branch,
1212
>**not** the master or older branches.
1313
1414
We love contributors! For more information on how you can contribute to the

‎book/forms.rst

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -648,6 +648,12 @@ Now the form will skip your validation constraints. It will still validate
648648
basic integrity constraints, such as checking whether an uploaded file was too
649649
large or whether you tried to submit text in a number field.
650650

651+
.. seealso::
652+
653+
To see how to use a service to resolve ``validation_groups`` dynamically
654+
read the :doc:`/cookbook/validation/validation-group-service-resolver`
655+
chapter in the cookbook.
656+
651657
.. index::
652658
single: Forms; Built-in field types
653659

‎components/console/events.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -121,7 +121,7 @@ Listeners receive a
121121
.. tip::
122122

123123
This event is also dispatched when an exception is thrown by the command.
124-
It is then dispatched just before the ``ConsoleEvents::EXCEPTION`` event.
124+
It is then dispatched just after the ``ConsoleEvents::EXCEPTION`` event.
125125
The exit code received in this case is the exception code.
126126

127127
The ``ConsoleEvents::EXCEPTION`` Event

‎components/form/introduction.rst

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -163,14 +163,14 @@ component offers a rich integration.
163163

164164
To use the integration, you'll need the ``TwigBridge``, which provides integration
165165
between Twig and several Symfony components. If you're using Composer, you
166-
could install the latest 2.3 version by adding the following ``require``
166+
could install the latest 2.7 version by adding the following ``require``
167167
line to your ``composer.json`` file:
168168

169169
.. code-block:: json
170170
171171
{
172172
"require": {
173-
"symfony/twig-bridge": "2.3.*"
173+
"symfony/twig-bridge": "2.7.*"
174174
}
175175
}
176176
@@ -246,15 +246,15 @@ via your own Twig extension.
246246

247247
To use the built-in integration, be sure that your project has Symfony's
248248
Translation and :doc:`Config </components/config/introduction>` components
249-
installed. If you're using Composer, you could get the latest 2.3 version
249+
installed. If you're using Composer, you could get the latest 2.7 version
250250
of each of these by adding the following to your ``composer.json`` file:
251251

252252
.. code-block:: json
253253
254254
{
255255
"require": {
256-
"symfony/translation": "2.3.*",
257-
"symfony/config": "2.3.*"
256+
"symfony/translation": "2.7.*",
257+
"symfony/config": "2.7.*"
258258
}
259259
}
260260
@@ -298,13 +298,13 @@ array or object) and pass it through your own validation system.
298298

299299
To use the integration with Symfony's Validator component, first make sure
300300
it's installed in your application. If you're using Composer and want to
301-
install the latest 2.3 version, add this to your ``composer.json``:
301+
install the latest 2.7 version, add this to your ``composer.json``:
302302

303303
.. code-block:: json
304304
305305
{
306306
"require": {
307-
"symfony/validator": "2.3.*"
307+
"symfony/validator": "2.7.*"
308308
}
309309
}
310310

‎components/options_resolver.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -430,7 +430,7 @@ if you need to use other options during normalization::
430430
{
431431
// ...
432432
$resolver->setNormalizer('host', function (Options $options, $value) {
433-
if (!in_array(substr($value, 0, 7), array('http://', 'https://'))) {
433+
if ('http://' !== substr($value, 0, 7) && 'https://' !== substr($value, 0, 8)) {
434434
if ('ssl' === $options['encryption']) {
435435
$value = 'https://'.$value;
436436
} else {

‎contributing/code/patches.rst

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -113,7 +113,7 @@ Choose the right Branch
113113
Before working on a patch, you must determine on which branch you need to
114114
work:
115115

116-
* ``2.3``, if you are fixing a bug for an existing feature or want to make a
116+
* ``2.7``, if you are fixing a bug for an existing feature or want to make a
117117
change that falls into the :doc:`list of acceptable changes in patch versions
118118
</contributing/code/maintenance>` (you may have to choose a higher branch if
119119
the feature you are fixing was introduced in a later version);
@@ -124,7 +124,7 @@ work:
124124

125125
All bug fixes merged into maintenance branches are also merged into more
126126
recent branches on a regular basis. For instance, if you submit a patch
127-
for the ``2.3`` branch, the patch will also be applied by the core team on
127+
for the ``2.7`` branch, the patch will also be applied by the core team on
128128
the ``master`` branch.
129129

130130
Create a Topic Branch
@@ -137,18 +137,18 @@ topic branch:
137137
138138
$ git checkout -b BRANCH_NAME master
139139
140-
Or, if you want to provide a bugfix for the ``2.3`` branch, first track the remote
141-
``2.3`` branch locally:
140+
Or, if you want to provide a bugfix for the ``2.7`` branch, first track the remote
141+
``2.7`` branch locally:
142142

143143
.. code-block:: bash
144144
145-
$ git checkout -t origin/2.3
145+
$ git checkout -t origin/2.7
146146
147-
Then create a new branch off the ``2.3`` branch to work on the bugfix:
147+
Then create a new branch off the ``2.7`` branch to work on the bugfix:
148148

149149
.. code-block:: bash
150150
151-
$ git checkout -b BRANCH_NAME 2.3
151+
$ git checkout -b BRANCH_NAME 2.7
152152
153153
.. tip::
154154

@@ -236,7 +236,7 @@ while to finish your changes):
236236
237237
.. tip::
238238

239-
Replace ``master`` with the branch you selected previously (e.g. ``2.3``)
239+
Replace ``master`` with the branch you selected previously (e.g. ``2.7``)
240240
if you are working on a bugfix
241241

242242
When doing the ``rebase`` command, you might have to fix merge conflicts.
@@ -263,8 +263,8 @@ You can now make a pull request on the ``symfony/symfony`` GitHub repository.
263263

264264
.. tip::
265265

266-
Take care to point your pull request towards ``symfony:2.3`` if you want
267-
the core team to pull a bugfix based on the ``2.3`` branch.
266+
Take care to point your pull request towards ``symfony:2.7`` if you want
267+
the core team to pull a bugfix based on the ``2.7`` branch.
268268

269269
To ease the core team work, always include the modified components in your
270270
pull request message, like in:
@@ -335,7 +335,7 @@ Rework your Patch
335335

336336
Based on the feedback on the pull request, you might need to rework your
337337
patch. Before re-submitting the patch, rebase with ``upstream/master`` or
338-
``upstream/2.3``, don't merge; and force the push to the origin:
338+
``upstream/2.7``, don't merge; and force the push to the origin:
339339

340340
.. code-block:: bash
341341

‎contributing/code/standards.rst

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -153,13 +153,19 @@ Structure
153153
that are not intended to be instantiated from the outside and thus are not
154154
concerned by the `PSR-0`_ and `PSR-4`_ autoload standards;
155155

156+
* Declare the class inheritance and all the implemented interfaces on the same
157+
line as the class name;
158+
156159
* Declare class properties before methods;
157160

158161
* Declare public methods first, then protected ones and finally private ones.
159162
The exceptions to this rule are the class constructor and the ``setUp`` and
160163
``tearDown`` methods of PHPUnit tests, which should always be the first methods
161164
to increase readability;
162165

166+
* Declare all the arguments on the same line as the method/function name, no
167+
matter how many arguments there are;
168+
163169
* Use parentheses when instantiating classes regardless of the number of
164170
arguments the constructor has;
165171

‎contributing/documentation/format.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -177,8 +177,8 @@ Symfony, you should precede your description of the change with a
177177

178178
.. code-block:: rst
179179
180-
.. versionadded:: 2.3
181-
The ``askHiddenResponse`` method was introduced in Symfony 2.3.
180+
.. versionadded:: 2.7
181+
The ``askHiddenResponse`` method was introduced in Symfony 2.7.
182182
183183
You can also ask a question and hide the response. This is particularly [...]
184184
@@ -187,9 +187,9 @@ how the behavior has changed:
187187

188188
.. code-block:: rst
189189
190-
.. versionadded:: 2.3
190+
.. versionadded:: 2.7
191191
The ``include()`` function is a new Twig feature that's available in
192-
Symfony 2.3. Prior, the ``{% include %}`` tag was used.
192+
Symfony 2.7. Prior, the ``{% include %}`` tag was used.
193193
194194
Whenever a new minor version of Symfony is released (e.g. 2.4, 2.5, etc),
195195
a new branch of the documentation is created from the ``master`` branch.

‎contributing/documentation/overview.rst

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -116,14 +116,14 @@ memorable name for the new branch (if you are fixing a reported issue, use
116116

117117
.. code-block:: bash
118118
119-
$ git checkout -b improve_install_chapter upstream/2.3
119+
$ git checkout -b improve_install_chapter upstream/2.7
120120
121121
In this example, the name of the branch is ``improve_install_chapter`` and the
122-
``upstream/2.3`` value tells Git to create this branch based on the ``2.3``
122+
``upstream/2.7`` value tells Git to create this branch based on the ``2.7``
123123
branch of the ``upstream`` remote, which is the original Symfony Docs repository.
124124

125125
Fixes should always be based on the **oldest maintained branch** which contains
126-
the error. Nowadays this is the ``2.3`` branch. If you are instead documenting a
126+
the error. Nowadays this is the ``2.7`` branch. If you are instead documenting a
127127
new feature, switch to the first Symfony version that included it, e.g.
128128
``upstream/3.1``. Not sure? That's ok! Just use the ``upstream/master`` branch.
129129

@@ -159,7 +159,7 @@ changes should be applied:
159159
:align: center
160160

161161
In this example, the **base fork** should be ``symfony/symfony-docs`` and
162-
the **base** branch should be the ``2.3``, which is the branch that you selected
162+
the **base** branch should be the ``2.7``, which is the branch that you selected
163163
to base your changes on. The **head fork** should be your forked copy
164164
of ``symfony-docs`` and the **compare** branch should be ``improve_install_chapter``,
165165
which is the name of the branch you created and where you made your changes.
@@ -208,7 +208,7 @@ contribution to the Symfony docs:
208208
209209
# create a new branch based on the oldest maintained version
210210
$ cd projects/symfony-docs/
211-
$ git checkout -b my_changes upstream/2.3
211+
$ git checkout -b my_changes upstream/2.7
212212
213213
# ... do your changes
214214
@@ -265,8 +265,8 @@ into multiple branches, corresponding to the different versions of Symfony itsel
265265
The ``master`` branch holds the documentation for the development branch of
266266
the code.
267267

268-
Unless you're documenting a feature that was introduced after Symfony 2.3,
269-
your changes should always be based on the ``2.3`` branch. Documentation managers
268+
Unless you're documenting a feature that was introduced after Symfony 2.7,
269+
your changes should always be based on the ``2.7`` branch. Documentation managers
270270
will use the necessary Git-magic to also apply your changes to all the active
271271
branches of the documentation.
272272

‎cookbook/map.rst.inc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -254,6 +254,7 @@
254254

255255
* :doc:`/cookbook/validation/custom_constraint`
256256
* :doc:`/cookbook/validation/severity`
257+
* :doc:`/cookbook/validation/group_service_resolver`
257258

258259
* :doc:`/cookbook/web_server/index`
259260

‎cookbook/security/entity_provider.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -314,7 +314,7 @@ and password ``admin`` (which has been encoded).
314314
| 1 | admin | $2a$08$jHZj/wJfcVKlIwr5AvR78euJxYK7Ku5kURNhNx.7.CSIJ3Pq6LEPC | admin@example.com | 1 |
315315
+----+----------+--------------------------------------------------------------+--------------------+-----------+
316316
317-
.. sidebar:: Do you need to a Salt property?
317+
.. sidebar:: Do you need to use a Salt property?
318318

319319
If you use ``bcrypt``, no. Otherwise, yes. All passwords must be hashed
320320
with a salt, but ``bcrypt`` does this internally. Since this tutorial

‎cookbook/upgrade/bundles.rst

Lines changed: 13 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -20,9 +20,9 @@ Most third-party bundles define their Symfony dependencies using the ``~2.N`` or
2020
2121
{
2222
"require": {
23-
"symfony/framework-bundle": "~2.3",
24-
"symfony/finder": "~2.3",
25-
"symfony/validator": "~2.3"
23+
"symfony/framework-bundle": "~2.7",
24+
"symfony/finder": "~2.7",
25+
"symfony/validator": "~2.7"
2626
}
2727
}
2828
@@ -37,9 +37,9 @@ The above example can be updated to work with Symfony 3 as follows:
3737
3838
{
3939
"require": {
40-
"symfony/framework-bundle": "~2.3|~3.0",
41-
"symfony/finder": "~2.3|~3.0",
42-
"symfony/validator": "~2.3|~3.0"
40+
"symfony/framework-bundle": "~2.7|~3.0",
41+
"symfony/finder": "~2.7|~3.0",
42+
"symfony/validator": "~2.7|~3.0"
4343
}
4444
}
4545
@@ -143,11 +143,15 @@ following recommended configuration as the starting point of your own configurat
143143
- php: 5.3.3
144144
env: COMPOSER_FLAGS='--prefer-lowest --prefer-stable' SYMFONY_DEPRECATIONS_HELPER=weak
145145
- php: 5.6
146-
env: SYMFONY_VERSION='2.3.*'
146+
env: SYMFONY_VERSION='2.7.*'
147147
- php: 5.6
148-
env: DEPENDENCIES='dev' SYMFONY_VERSION='2.8.*@dev'
148+
env: SYMFONY_VERSION='2.8.*'
149149
- php: 5.6
150-
env: SYMFONY_VERSION='3.0.*@dev'
150+
env: SYMFONY_VERSION='3.0.*'
151+
- php: 5.6
152+
env: SYMFONY_VERSION='3.1.*'
153+
- php: 5.6
154+
env: DEPENDENCES='dev' SYMFONY_VERSION='3.2.*@dev'
151155
152156
before_install:
153157
- composer self-update

‎cookbook/upgrade/major_version.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ done!
9393
.. sidebar:: Using the Weak Deprecations Mode
9494

9595
Sometimes, you can't fix all deprecations (e.g. something was deprecated
96-
in 2.6 and you still need to support 2.3). In these cases, you can still
96+
in 2.8 and you still need to support 2.7). In these cases, you can still
9797
use the bridge to fix as many deprecations as possible and then switch
9898
to the weak test mode to make your tests pass again. You can do this by
9999
using the ``SYMFONY_DEPRECATIONS_HELPER`` env variable:

‎cookbook/validation/group_service_resolver.rst

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
How to Dynamically Configure Validation Groups
2+
==============================================
3+
4+
Sometimes you need advanced logic to determine the validation groups. If they
5+
can't be determined by a simple callback, you can use a service. Create a
6+
service that implements ``__invoke`` which accepts a ``FormInterface`` as a
7+
parameter.
8+
9+
.. code-block:: php
10+
11+
// src/AppBundle/Validation/ValidationGroupResolver.php
12+
namespace AppBundle\Validation;
13+
14+
use Symfony\Component\Form\FormInterface;
15+
16+
class ValidationGroupResolver
17+
{
18+
private $service1;
19+
20+
private $service2;
21+
22+
public function __construct($service1, $service2)
23+
{
24+
$this->service1 = $service1;
25+
$this->service2 = $service2;
26+
}
27+
28+
/**
29+
* @param FormInterface $form
30+
* @return array
31+
*/
32+
public function __invoke(FormInterface $form)
33+
{
34+
$groups = array();
35+
36+
// ... determine which groups to apply and return an array
37+
38+
return $groups;
39+
}
40+
}
41+
42+
Then in your form, inject the resolver and set it as the ``validation_groups``.
43+
44+
.. code-block:: php
45+
46+
// src/AppBundle/Form/MyClassType.php;
47+
namespace AppBundle\Form;
48+
49+
use AppBundle\Validator\ValidationGroupResolver;
50+
use Symfony\Component\Form\AbstractType
51+
use Symfony\Component\OptionsResolver\OptionsResolver;
52+
53+
class MyClassType extends AbstractType
54+
{
55+
private $groupResolver;
56+
57+
public function __construct(ValidationGroupResolver $groupResolver)
58+
{
59+
$this->groupResolver = $groupResolver;
60+
}
61+
62+
// ...
63+
public function configureOptions(OptionsResolver $resolver)
64+
{
65+
$resolver->setDefaults(array(
66+
'validation_groups' => $this->groupResolver,
67+
));
68+
}
69+
}
70+
71+
This will result in the form validator invoking your group resolver to set the
72+
validation groups returned when validating.

0 commit comments

Comments
 (0)
0