Commits
-------
b4d1bdf [Form] added a bc break note about the tag alias matching
Discussion
----------
[Form] added a bc break note about the tag alias matching
6489a65960 is a BC break if we were relying on the previous behavior.
Commits
-------
1f2f866 fixed the serialization of the SwitchUserRole
b55930a [Security] Implemented the Serializable interface in the Role class
Discussion
----------
[Security] Implemented the Serializable interface in the Role class
The Role class is serialized in the session for each role of the user. Implementing the Serializable interface allows to reduce the size of the data.
Commits
-------
df2406f [Security] Add note to changelog about BC break
01b2e39 [Security] Extract default logout success handling logic
Discussion
----------
[Security] Extract default logout success handling logic
Bug fix: no
Feature addition: no
Backwards compatibility break: yes, small one for people using the component
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
License of the code: MIT
As discussed earlier with @fabpot and @schmittjoh. This PR extracts the default logout success handling logic to a separate class that users can extend.
Note: build status is red, but that is because of a failing performance test in the form component? ..
Commits
-------
7d53909 Earlier PHP output buffer flush for non FPM environments
Discussion
----------
Earlier PHP output buffer flush for non FPM environments
In the Response::send() method you are calling the fastcgi_finish_request() in case it exists. This will provide a respectful performance boost when you have significant work being done by listeners acting on kernel terminal events; Sadly you are forgetting people that don't use FPM doing this.
The performance boost for a Vanilla PHP is not much: flushing earlier potentially helps higher layers such as the HTTPd or potential other cache layers: the sooner their buffer gets filled, the sooner they release information to the browser, even if the output buffer is still open. The explicit flush() is supposed to do exactly this.
Commits
-------
33f29ed [Form] '@group benchmark' for form performance tests
Discussion
----------
[Form] '@group benchmark' for form performance tests
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
License of the code: MIT
I think a PR or note about this has been rejected before, but since build statuses on PRs sometimes seem to fail if travis is busy I think moving the form performance tests to `@group benchmark` should be reconsidered.
Edit: even master is currently failing on this
Commits
-------
07992d3 [Validator] Added inheritDoc phpdoc for validate methods
Discussion
----------
[Validator] Added inheritDoc phpdoc for validate methods
Was instructed by @stof to do this for a PR on comparison validators and noticed none of the validators used inheritDoc.
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: n/a
Todo: I haven't looked around too much, but I assume if none of the validators followed this standard that there would be a fair few other classes not using. Obviously not a big issue though
License of the code: MIT
Documentation PR: n/a
Commits
-------
5ae0da0 Update changelogs
ff91b9a [FrameworkBundle] Make FlashBag the default.
Discussion
----------
[2.1][FrameworkBundle] Make FlashBag the default.
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes (but only technically)
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
The difference between `AutoExpireFlashBag` and `FlashBag` is simply that the first will expire flashes regardless of being displayed on the next pageload. This can result in lost messages. It was created simply for BC with 2.0.
`FlashBag` expires flashes once they are retrieved. This also makes it ESI compatible.
/cc @lsmith77
---------------------------------------------------------------------------
by jalliot at 2012-07-14T18:13:40Z
+1!
You should add it to the changelog and upgrade files though :)
Commits
-------
480ab14 Further improving the MessageSelector exception
Discussion
----------
Further improving the MessageSelector exception
Hey guys!
The goal is just to give the users a better starting point when they see this exception.
See previous change in #4173 and conversation in #4207
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4207
Todo: -
License of the code: MIT
Documentation PR: n/a
Thanks!
---------------------------------------------------------------------------
by stof at 2012-07-14T23:11:17Z
Shouldn't it be done in 2.0 instead ?
---------------------------------------------------------------------------
by weaverryan at 2012-07-15T00:15:42Z
I decided to go against 2.1 when I saw that #4173 was against 2.0. If we do it against 2.0, it'll cause a conflict when 2.0 is merged into master - seemed like too much trouble for such a small change.
Commits
-------
12bdec3 Moved the NormalizationAwareInterface check to the ChainEncoder
28e137c [Serializer] Added a ChainEncoder and a ChainDecoder
Discussion
----------
[Serializer] Added a ChainEncoder and a ChainDecoder
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/stof/symfony)
Fixes the following tickets: -
Todo: -
These classes contains the logic previously defined in the Serializer itself to handle the choice of a serializer. This allows reusing it when using only the encoding part of the component, without having to use the Serializer class (which is not as handy to bootstrap when you want to use only encoders and decoders as normalizers come first)
I was wondering if these classes should have adders but I kept the constructor injection only to be consistent with the current code (encoders cannot be registered after the instantiation) and to avoid implementing the SerializerAwareInterface in them (to allow injecting the Serializer in serializer-aware encoders and decoders added later).
Note that this change is fully BC as it only changes the internal implementation of the Serializer.
---------------------------------------------------------------------------
by fabpot at 2012-07-14T11:07:32Z
ping @lsmith77 @Seldaek
---------------------------------------------------------------------------
by Seldaek at 2012-07-14T15:17:42Z
After a quick look, I'd say +1
Commits
-------
a80ef6b Fixed: The type name specified for the service propel.form.type.model does not match the actual name
Discussion
----------
[Propel1Bridge][Form] ModelType name is invalid
Since 6489a65960 "[Form] Added an exception for invalid type services" Symfony/Component/Form/Extension/DependencyInjection/DependencyInjectionExtension requires form type names to match the service name.
This fixes exception "The type name specified for the service propel.form.type.model does not match the actual name"
---------------------------------------------------------------------------
by willdurand at 2012-07-14T14:03:20Z
👍
---------------------------------------------------------------------------
by fabpot at 2012-07-14T14:17:36Z
I think it would be better to named it `propel_model`.
---------------------------------------------------------------------------
by willdurand at 2012-07-14T14:20:05Z
There is `entity` for Doctrine entities, not `doctrine_entity`. This should
be the same for Propel...
2012/7/14 Fabien Potencier <
reply@reply.github.com
>
> I think it would be better to named it `propel_model`.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/4920#issuecomment-6983217
>
---------------------------------------------------------------------------
by stloyd at 2012-07-14T14:22:34Z
@fabpot @willdurand Or we should rename Doctrine one too, to be more consistent...
---------------------------------------------------------------------------
by fabpot at 2012-07-14T14:30:41Z
We should definitely rename Doctrine too.
---------------------------------------------------------------------------
by cvschaefer at 2012-07-14T14:34:51Z
@fabpot Wouldn't that break all existing forms with doctrine entity form types?
---------------------------------------------------------------------------
by stof at 2012-07-14T14:54:03Z
It would break BC indeed, and changing the propel type name in the DIC config (which is the one used in before the latest refactoring) would also be a BC break.
And btw, we also use ``entity`` in the SecurityBundle config, not ``doctrine_entity``
---------------------------------------------------------------------------
by fabpot at 2012-07-14T15:04:31Z
You're right, let's not break BC for the sake of it.
---------------------------------------------------------------------------
by stof at 2012-07-14T15:13:23Z
Ok, so this PR should be merged as is, as I guess more people are using the Propel type in a PropelBundle context than with a standalone Form component (which would have used the getName method)
---------------------------------------------------------------------------
by cvschaefer at 2012-07-14T15:14:44Z
+1
Bernhard Schussek
Fabien Potencier
Jordan Alliot
Bilal Amarni
Daniel Holmes
Ryan Weaver
Drak
excelwebzone
Christophe Coevoet
Alexander
Christoph Schaefer
