Commits
-------
a924dab [OptionsResolver] Made the OptionsResolver clonable
70307e5 [Form] Improved EntityType performance by caching the EntityChoiceList
8298d8c [Form] Improved ChoiceType performance by caching ChoiceList objects
Discussion
----------
[Form] Improved performance of ChoiceType and EntityType
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Commits
-------
a92f80b [Validator] Added Length constraint and deprecated MinLength and MaxLength
83a3f75 [Validator] Deprecated the constraints Min and Max in favor of Range
0cdacee [Validator] Removed MinCount and MaxCount and replaced them by the constraint Count
741c147 [Validator] Renamed deprecated Size constraint to Range
Discussion
----------
[Validator] Reintroduced Range constraint and created Count and Length constraints
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
After @Tobion's comment to #4851, this is the next try to streamline the constraints and reduce duplication of logic. The downside of the current MinLength/MaxLength and MinCount/MaxCount pairs is that they cannot output a fitting error message if a value should have an *exact* length/count. So this PR introduces
* Range (formerly Size) to replace Min/Max
* Count to replace MinCount/MaxCount
* Length to replace MinLength/MaxLength
Feedback is appreciated.
---------------------------------------------------------------------------
by Tobion at 2012-07-11T20:40:08Z
The `choice` constraint also cannot handle `min = max`. Or maybe we don't need these options on choice anymore as we can achieve the same with the new `count` constraint?!
---------------------------------------------------------------------------
by beberlei at 2012-07-12T08:59:44Z
Dude, nobody has time to fix the BC breaks you introduce :-)
---------------------------------------------------------------------------
by TomAdam at 2012-07-12T12:38:49Z
The changes to the `Size` validator yesterday broke my project, and I started rewriting to use `MaxLength / MinLength` validators today, until I spotted this. It would be good if this PR could have a reasonably high priority (whether or not it is accepted) as it will change how I fix my issues. I suspect a lot of people using the master branch will be in the same situation.
Commits
-------
34abe37 Added mime type for RAR archive, sending from Linux Chrome via nginx
Discussion
----------
Added new mime type for RAR archive
This mime type detected when sending file from Linux Chrome Browser via nginx
Commits
-------
5e6c06f [Security] Remove hard dependency on $providerKey for default auth success handler
Discussion
----------
[Security] Remove hard dependency on $providerKey for default auth success handler
Bug fix: yes?
Feature addition: yes?
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
License of the code: MIT
In 8ffaafa867 a hard dependency was introduced between the default authentication success handling code and the active firewall. This makes sense. However, for people implementing their own success handler this makes it impossible to extend the default class as the `$providerKey` is set in the extension of the security bundle.
This PR makes the dependency a soft one so people can extend the class and use the default definition as a parent for their own service. However it is the responsibility of the developers to set the appropriate `$providerKey` if they want to use the target url saved in the session. Imo this is the right way as the developer should also set the appropriate options for the parent class in the overriding constructor.
---------------------------------------------------------------------------
by stof at 2012-07-11T19:01:12Z
@asm89 this PR need to be rebased according to github
---------------------------------------------------------------------------
by asm89 at 2012-07-11T19:13:09Z
@stof Done :)
---------------------------------------------------------------------------
by asm89 at 2012-07-12T10:07:53Z
@fabpot Done.
By default, the UniqueEntityValidator maps the violation on the first
field of the UniqueEntity constraint. The new option allows to control
this behavior if a better mapping is suited.
Commits
-------
f59b052 [Security] Fix the default authentication handlers config definition
Discussion
----------
[Security] Fix the default authentication handlers config definition
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
License of the code: MIT
Options should be a collection, when you use the default handler definition as a parent you will get an error that the argument of the constructor is a string and not an array, because for your own service the extension of the security bundle will not replace the arguments.
Commits
-------
0be602d [Validator] Deprecated the Size constraint
d661837 [Validator] Reverted the changes done to the Size constraint in 3a5e84f4a7d84b689 [Validator] Added the constraints MinCount and MaxCount
1a732e4 [Validator] Removed the Range constraint as it duplicates functionality given in Min and Max
Discussion
----------
[Validator] Deprecated the Size constraint in favor of MinCount and MaxCount
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR cleans up with the current ambiguity between
* Min
* Max
* MinLength
* MaxLength
* Range
* Size
in the following ways:
* The Range constraint was removed again as it can be completely replaced by Min and Max.
* The Size constraint was reverted to it's 2.0 feature set and deprecated.
* The constraints MinCount and MaxCount were added to make up for the functionality that was added to Size.
Commits
-------
b7aae48 [Locale] Fixed error resetting in StubIntlDateFormatter::parse()
Discussion
----------
[Locale] Fixed error resetting in StubIntlDateFormatter::parse()
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4242
Todo: -
---------------------------------------------------------------------------
by bschussek at 2012-07-11T08:00:15Z
ping @eriksencosta, @igorw - is this solved as intended?
---------------------------------------------------------------------------
by eriksencosta at 2012-07-11T11:20:24Z
Yes, thanks!
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
-------
ded6c03 [Form] DateTimeType now handles RFC 3339 dates as provided by HTML5
7e8b622 [Form] Added the option "format" to DateTimeType
9eeb200 [Form] Changed the default format of DateType to "yyyy-MM-dd" to support HTML 5 out of the box
d621a76 [Form] Improved DateTimeType code
Discussion
----------
[Form] Changed DateType and DateTimeType to support HTML5 by default
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #2849, #3162
Todo: -
This PR changes DateType and DateTimeType to support HTML5 by default when setting the option "widget" to "single_text".
Also, the option "format" was added to DateTimeType.
---------------------------------------------------------------------------
by stof at 2012-07-10T15:38:44Z
This loos OK to me
---------------------------------------------------------------------------
by MDrollette at 2012-07-10T16:36:26Z
@stof typo: "looks" #meta-stoffed
Commits
-------
02e0a8f Allow Kernel::$name to be overridden by subclasses
Discussion
----------
Allow Kernel::$name to be overridden by subclasses
Because the name of the kernel is calculated in the constructor,
any child class that had overriden the kernel name, will be
ignored.
By setting the kernel name in the child class, we can avoid having
to execute the regex to calculate the name upon every construction
of a Kernel.
A test (and a kernel fixture) is added to prove that the override
works correctly.
Note: the Kernel API has not been touched, so there should be no
issues with BC.
What do you think?
Because the name of the kernel is calculated in the constructor,
any child class that had overriden the kernel name, will be
ignored.
By setting the kernel name in the child class, we can avoid having
to execute the regex to calculate the name upon every construction
of a Kernel.
A test (and a kernel fixture) is added to prove that the override
works correctly.
Note: the Kernel API has not been touched, so there should be no
issues with BC.
