merged branch Tobion/patch-1 (PR #3130)
Commits -------5de5382
improved formatting of changelog-2.1bf5ccb0
resolved conflict Discussion ---------- improved markdown formatting of upgrade file Fixed the indention so that the detailed descriptions are part of the corresponding changelog list item. --------------------------------------------------------------------------- by fabpot at 2012-01-17T09:24:04Z It does not merge cleanly. --------------------------------------------------------------------------- by Tobion at 2012-01-17T10:02:14Z @fabpot should be good to go now
This commit is contained in:
commit
c0c2951554
@ -55,29 +55,33 @@ To get the diff between two versions, go to https://github.com/symfony/symfony/c
|
||||
* [BC BREAK] refactored the user provider configuration. The configuration
|
||||
changed for the chain provider and the memory provider:
|
||||
|
||||
Before:
|
||||
Before:
|
||||
|
||||
security:
|
||||
providers:
|
||||
my_chain_provider:
|
||||
providers: [my_memory_provider, my_doctrine_provider]
|
||||
my_memory_provider:
|
||||
users:
|
||||
toto: { password: foobar, roles: [ROLE_USER] }
|
||||
foo: { password: bar, roles: [ROLE_USER, ROLE_ADMIN] }
|
||||
``` yaml
|
||||
security:
|
||||
providers:
|
||||
my_chain_provider:
|
||||
providers: [my_memory_provider, my_doctrine_provider]
|
||||
my_memory_provider:
|
||||
users:
|
||||
toto: { password: foobar, roles: [ROLE_USER] }
|
||||
foo: { password: bar, roles: [ROLE_USER, ROLE_ADMIN] }
|
||||
```
|
||||
|
||||
After:
|
||||
After:
|
||||
|
||||
security:
|
||||
providers:
|
||||
my_chain_provider:
|
||||
chain:
|
||||
providers: [my_memory_provider, my_doctrine_provider]
|
||||
my_memory_provider:
|
||||
memory:
|
||||
users:
|
||||
toto: { password: foobar, roles: [ROLE_USER] }
|
||||
foo: { password: bar, roles: [ROLE_USER, ROLE_ADMIN] }
|
||||
``` yaml
|
||||
security:
|
||||
providers:
|
||||
my_chain_provider:
|
||||
chain:
|
||||
providers: [my_memory_provider, my_doctrine_provider]
|
||||
my_memory_provider:
|
||||
memory:
|
||||
users:
|
||||
toto: { password: foobar, roles: [ROLE_USER] }
|
||||
foo: { password: bar, roles: [ROLE_USER, ROLE_ADMIN] }
|
||||
```
|
||||
|
||||
* [BC BREAK] Method `equals` was removed from `UserInterface` to its own new
|
||||
`EquatableInterface`, now user class can implement this interface to override
|
||||
@ -210,29 +214,29 @@ To get the diff between two versions, go to https://github.com/symfony/symfony/c
|
||||
* [BC BREAK] changed `GetSetMethodNormalizer`'s key names from all lowercased to camelCased (e.g. `mypropertyvalue` to `myPropertyValue`)
|
||||
* [BC BREAK] convert the `item` XML tag to an array
|
||||
|
||||
``` xml
|
||||
<?xml version="1.0"?>
|
||||
<response>
|
||||
<item><title><![CDATA[title1]]></title></item><item><title><![CDATA[title2]]></title></item>
|
||||
</response>
|
||||
```
|
||||
``` xml
|
||||
<?xml version="1.0"?>
|
||||
<response>
|
||||
<item><title><![CDATA[title1]]></title></item><item><title><![CDATA[title2]]></title></item>
|
||||
</response>
|
||||
```
|
||||
|
||||
Before:
|
||||
Before:
|
||||
|
||||
Array()
|
||||
Array()
|
||||
|
||||
After:
|
||||
After:
|
||||
|
||||
Array(
|
||||
[item] => Array(
|
||||
[0] => Array(
|
||||
[title] => title1
|
||||
)
|
||||
[1] => Array(
|
||||
[title] => title2
|
||||
)
|
||||
)
|
||||
)
|
||||
Array(
|
||||
[item] => Array(
|
||||
[0] => Array(
|
||||
[title] => title1
|
||||
)
|
||||
[1] => Array(
|
||||
[title] => title2
|
||||
)
|
||||
)
|
||||
)
|
||||
|
||||
### Translation
|
||||
|
||||
|
100
UPGRADE-2.1.md
100
UPGRADE-2.1.md
@ -3,77 +3,77 @@ UPGRADE FROM 2.0 to 2.1
|
||||
|
||||
* assets_base_urls and base_urls merging strategy has changed
|
||||
|
||||
Unlike most configuration blocks, successive values for
|
||||
``assets_base_urls`` will overwrite each other instead of being merged.
|
||||
This behavior was chosen because developers will typically define base
|
||||
URL's for each environment. Given that most projects tend to inherit
|
||||
configurations (e.g. ``config_test.yml`` imports ``config_dev.yml``)
|
||||
and/or share a common base configuration (i.e. ``config.yml``), merging
|
||||
could yield a set of base URL's for multiple environments.
|
||||
Unlike most configuration blocks, successive values for
|
||||
``assets_base_urls`` will overwrite each other instead of being merged.
|
||||
This behavior was chosen because developers will typically define base
|
||||
URL's for each environment. Given that most projects tend to inherit
|
||||
configurations (e.g. ``config_test.yml`` imports ``config_dev.yml``)
|
||||
and/or share a common base configuration (i.e. ``config.yml``), merging
|
||||
could yield a set of base URL's for multiple environments.
|
||||
|
||||
* moved management of the locale from the Session class to the Request class
|
||||
|
||||
Configuring the default locale:
|
||||
Configuring the default locale:
|
||||
|
||||
Before:
|
||||
Before:
|
||||
|
||||
framework:
|
||||
session:
|
||||
default_locale: fr
|
||||
framework:
|
||||
session:
|
||||
default_locale: fr
|
||||
|
||||
After:
|
||||
After:
|
||||
|
||||
framework:
|
||||
default_locale: fr
|
||||
framework:
|
||||
default_locale: fr
|
||||
|
||||
Retrieving the locale from a Twig template:
|
||||
Retrieving the locale from a Twig template:
|
||||
|
||||
Before: {{ app.request.session.locale }} or {{ app.session.locale }}
|
||||
After: {{ app.request.locale }}
|
||||
Before: `{{ app.request.session.locale }}` or `{{ app.session.locale }}`
|
||||
After: `{{ app.request.locale }}`
|
||||
|
||||
Retrieving the locale from a PHP template:
|
||||
Retrieving the locale from a PHP template:
|
||||
|
||||
Before: $view['session']->getLocale()
|
||||
After: $view['request']->getLocale()
|
||||
Before: `$view['session']->getLocale()`
|
||||
After: `$view['request']->getLocale()`
|
||||
|
||||
Retrieving the locale from PHP code:
|
||||
Retrieving the locale from PHP code:
|
||||
|
||||
Before: $session->getLocale()
|
||||
After: $request->getLocale()
|
||||
Before: `$session->getLocale()`
|
||||
After: `$request->getLocale()`
|
||||
|
||||
* Method `equals` of `Symfony\Component\Security\Core\User\UserInterface` has
|
||||
moved to `Symfony\Component\Security\Core\User\EquatableInterface`.
|
||||
|
||||
You have to change the name of the `equals` function in your implementation
|
||||
of the `User` class to `isEqualTo` and implement `EquatableInterface`.
|
||||
Apart from that, no other changes are required to make it behave as before.
|
||||
Alternatively, you can use the default implementation provided
|
||||
by `AbstractToken:hasUserChanged` if you do not need any custom comparison logic.
|
||||
In this case do not implement the interface and remove your comparison function.
|
||||
You have to change the name of the `equals` function in your implementation
|
||||
of the `User` class to `isEqualTo` and implement `EquatableInterface`.
|
||||
Apart from that, no other changes are required to make it behave as before.
|
||||
Alternatively, you can use the default implementation provided
|
||||
by `AbstractToken:hasUserChanged` if you do not need any custom comparison logic.
|
||||
In this case do not implement the interface and remove your comparison function.
|
||||
|
||||
Before:
|
||||
Before:
|
||||
|
||||
class User implements UserInterface
|
||||
{
|
||||
// ...
|
||||
public function equals(UserInterface $user) { /* ... */ }
|
||||
// ...
|
||||
}
|
||||
class User implements UserInterface
|
||||
{
|
||||
// ...
|
||||
public function equals(UserInterface $user) { /* ... */ }
|
||||
// ...
|
||||
}
|
||||
|
||||
After:
|
||||
After:
|
||||
|
||||
class User implements UserInterface, EquatableInterface
|
||||
{
|
||||
// ...
|
||||
public function isEqualTo(UserInterface $user) { /* ... */ }
|
||||
// ...
|
||||
}
|
||||
|
||||
class User implements UserInterface, EquatableInterface
|
||||
{
|
||||
// ...
|
||||
public function isEqualTo(UserInterface $user) { /* ... */ }
|
||||
// ...
|
||||
}
|
||||
|
||||
* Form children aren't automatically validated anymore. That means that you
|
||||
explicitely need to set the `Valid` constraint in your model if you want to
|
||||
validate associated objects.
|
||||
|
||||
If you don't want to set the `Valid` constraint, or if there is no reference
|
||||
from the data of the parent form to the data of the child form, you can
|
||||
enable BC behaviour by setting the option "cascade_validation" to `true` on
|
||||
the parent form.
|
||||
|
||||
If you don't want to set the `Valid` constraint, or if there is no reference
|
||||
from the data of the parent form to the data of the child form, you can
|
||||
enable BC behaviour by setting the option "cascade_validation" to `true` on
|
||||
the parent form.
|
Reference in New Issue
Block a user