Commits
-------
7a76dba [Form] Renamed the options "data_timezone" and "user_timezone"
655d645 [Form] Fixed tests failing on systems with timezones other than +01:00
Discussion
----------
[Form] Fixed tests and renamed the options "data_timezone" and "user_timezone"
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
The option names were renamed for better consistency with the terms "model data" or "model format" and "view data" or "view format".
Commits
-------
88caf3a [HttpKernel] removed the storage of the current locale in the session
Discussion
----------
[HttpKernel] removed the storage of the current locale in the session
Before this commit, the current locale was stored in the session (if one
was already started). That way, for the next requests, even if the
request locale attribute was not set, the locale was "restored".
But this is a really bad practice as it means that the same URL can have
a different content depending on the previous requests. It would have
been better if the Vary header was set but the locale can be different
from the value coming from the Accept-Language anyway.
This is a BC break but fortunately, you can restore the 2.0 behavior by
creating a simple event listener that contains the logic removed by this
commit.
---------------------------------------------------------------------------
by travisbot at 2012-07-01T06:56:48Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1748659) (merged 009e30f0 into 2e356c1a).
---------------------------------------------------------------------------
by schmittjoh at 2012-07-01T08:15:46Z
How about using a cookie instead? It would remove the BC break, and also be possible to use a vary header?
---------------------------------------------------------------------------
by fabpot at 2012-07-01T09:13:44Z
The goal is to make Symfony as stateless as possible; introducing a cookie would defeat this goal.
---------------------------------------------------------------------------
by drak at 2012-07-01T09:19:37Z
@fabpot - thank you for bringing this to attention. I was meaning to do it a long time ago. The requested language is entirely a per request issue and must always be so. URLs must only ever return one content, and not multiple (e.g. different languages). The correct way to behave is to detect the language based on URL and failing that where a language is not requested, to look at the preferred language from the browser request and if available it can be redirected to that resource (e.g. /fr). This is what we do in Zikula. We have a further session based setting for "preferred language" which if set will override the browser default.
In summary:
1. If the language is specified in the GET request, return that language always. E.g. domain.com/fr/foo should return a French version of foo
2. If no language is specified in the GET request: first check the session for a preferred language, otherwise check the browser string for the preferred language and then if necessary, redirect to that resource. We have a setting which additionally say "always have language in URL, and don't put language code in URL for default language"
This means what in Zikula we only ever have one URL per language version of a page, but it still allows for users to set their preferred language which is taken in to account mainly when they visit the homepage (but in fact any page without a specific language in the request).
---------------------------------------------------------------------------
by drak at 2012-07-01T09:38:06Z
+1 on this PR. Basically the request locale should be in the Request object and calculated according to the applications preferences.
---------------------------------------------------------------------------
by schmittjoh at 2012-07-01T12:38:25Z
I agree that content must be detected based on the request, but I strongly disagree with relying entirely on the URL.
@fabpot, if you think about it using a cookie would still be stateless. There would be no state whatsoever, the detection would be entirely based on the request. Whether the language information is transmitted in the URL or as part of request headers is for the developer to decide eventually, at least IMO. My suggestion would just provide a default which is more BC.
---------------------------------------------------------------------------
by drak at 2012-07-01T20:08:50Z
@schmittjoh it's not entirely from the URL, there are browser preferences and also user defaults ca nalso available but the latter is slightly higher level. IMO it's not really Symfony's job here, it's application level specific. We have a pretty good working example of that in Zikula. Anyone can easily implement your own requirements with a listener.
What is absolutely clear however is it is wrong for one URL to deliver more than one version of any content.
---------------------------------------------------------------------------
by schmittjoh at 2012-07-01T21:16:52Z
I'm 100% for this change. My suggestion would just be more BC while still keeping Symfony2 stateless. Of course, it can be easily implemented in userland if we do not care about BC here.
Regarding different URLs per content, I do not think that this is our decision to make. Generally, developers should be able to make whatever content negotation they see fit. Whether they rely solely on the URL, or also take other request headers into account should not be limited by Symfony2.
---------------------------------------------------------------------------
by fabpot at 2012-07-02T10:37:26Z
I've added a paragraph in the UPGRADE file with a listener example that can be used to keep BC.
Before this commit, the current locale was stored in the session (if one
was already started). That way, for the next requests, even if the
request locale attribute was not set, the locale was "restored".
But this is a really bad practice as it means that the same URL can have
a different content depending on the previous requests. It would have
been better if the Vary header was set but the locale can be different
from the value coming from the Accept-Language anyway.
This is a BC break but fortunately, you can restore the 2.0 behavior by
creating a simple event listener that contains the logic removed by this
commit.
Commits
-------
c1e4166 moved create of default form label to view layer
Discussion
----------
move create of default form label to view layer
A small optimization if you provide custom labels in the view layer (i.e. `{{ form_label(form.name, 'Your name') }}`
```
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
```
---------------------------------------------------------------------------
by travisbot at 2012-06-24T14:45:17Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1694310) (merged 37f0b774 into 0d4b02e4).
---------------------------------------------------------------------------
by travisbot at 2012-06-24T15:03:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1694418) (merged c1e4166e into 0d4b02e4).
Commits
-------
06976fc Updated upgrade 2.1 file.
110ccd8 [BrowserKit] Updated changelog.
686854b [http kernel] Added client response type test.
ce7e1e6 [browser kit] Client now stores filtered response after request.
Discussion
----------
[browser kit] Client now stores filtered response after request.
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes/no, choice is your
Symfony2 tests pass: yes
`Symfony\Component\HttpKernel\Client::request()` method now returns a `Symfony\Component\BrowserKit\Response` instance.
Fixes issue #4475.
---------------------------------------------------------------------------
by stof at 2012-06-05T08:58:00Z
This *is* as BC break as it changes the class returned by the method, even if the BC break is a bugfix to respect the epxected behavior :)
---------------------------------------------------------------------------
by jfsimon at 2012-06-05T09:05:32Z
@stof you're right!
---------------------------------------------------------------------------
by travisbot at 2012-06-06T15:29:54Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1533533) (merged 686854b2 into 1541fe26).
---------------------------------------------------------------------------
by stof at 2012-06-09T10:12:18Z
@jfsimon can you add a note in the changelog of the component and in the upgrade file ?
---------------------------------------------------------------------------
by jfsimon at 2012-06-09T10:51:00Z
@stof done!
---------------------------------------------------------------------------
by travisbot at 2012-06-09T11:12:43Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1575524) (merged 06976fcd into 1541fe26).
---------------------------------------------------------------------------
by stof at 2012-06-09T12:50:16Z
@fabpot 👍
Bernhard Schussek
Fabien Potencier
Michaël Perrin
Frédéric Hardy
Kris Wallsmith
Javier Lopez
Julien Brochet
Michel Salib
Grégoire Paris
Jean-François Simon
Jérémie Augustin
Jakub Zalas
Albert Jessurum