* 2.1:
[Console] Add support for parsing terminal width/height on localized windows, fixes#5742
[Form] Fixed treatment of countables and traversables in Form::isEmpty()
refactor ControllerNameParser
[Form] Fixed FileType not to throw an exception when bound empty
- Test undefined index #
Maintain array structure
Check if key # is defined in $value
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
This PR was merged into the master branch.
Commits
-------
d5426f0 [Form] Add tests to prove that label is not rendered when is marked as false
120547c [Form][TwigBridge] Don't set label attributes if is marked as not to be rendered [Form][FrameworkBundle] Add option to disable rendering of label for fields
36e4556 [Form] Option for not displaying a label by setting label to false. [Form] Fixed formatting & translation ..
Discussion
----------
[Form] Added option for not displaying a form-label by setting label to false
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Replaces: #5421
@fabpot @BenjaminBeck: I was just not sure what to do with "table based" forms, so I left `<td></td>` rendered when there is no label, because I'm not sure that we can hide it easily.
---------------------------------------------------------------------------
by XWB at 2012-12-11T09:30:14Z
👍
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
* 2.0:
[DependencyInjection] fixed composer.json
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
fixed CS
small fix of #5984 when the container param is not set
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
[Security] remove escape charters from username provided by Digest DigestAuthenticationListener
[Security] added test extra for digest authentication
fixed CS
[Security] Fixed digest authentication
[Security] Fixed digest authentication
[SecurityBundle] Convert Http method to uppercase in the config
Use Norm Data instead of Data
Conflicts:
src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
src/Symfony/Component/DependencyInjection/composer.json
This PR was merged into the master branch.
Commits
-------
1858b96 [Form] Adapted FormValidator to latest changes in the Validator
1f752e8 [DoctrineBridge] Adapted UniqueValidator to latest changes in the Validator
efe42cb [Validator] Refactored the GraphWalker into an implementation of the Visitor design pattern.
Discussion
----------
[Validator] Refactored the Validator for use in Drupal
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: TODO
Drupal wants to use the Symfony Validator component in their next version. I was talking to @fago recently about the changes that we'd need to make and implemented these changes in this PR. I don't want to rush this, but the deadline is tight, since Drupal feature freeze is on December 1st and @fago needs at least a couple of days to integrate the Validator into Drupal.
This PR introduces two significant changes:
* Interfaces were created for all classes that constitute the Validator's API. This is were the PR breaks BC, because `ConstraintValidatorInterface::initialize()` is now type hinted against `ExecutionContextInterface` instead of `ExecutionContext`.
* The graph walker was refactored into an implementation of the Visitor pattern. This way, the validator was decoupled from the structure of the metadata (class → properties and getter methods) and makes it possible to implement a different metadata structure, as is required by the Drupal Entity API.
As a consequence of the API change, custom validation code is now much easier to write, because `ValidatorInterface` and `ExecutionContextInterface` share the following set of methods:
```php
interface ValidatorInterface
{
public function validate($value, $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $groups = null);
public function getMetadataFor($value);
}
interface ExecutionContextInterface
{
public function validate($value, $subPath = '', $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $subPath = '', $groups = null);
public function getMetadataFor($value);
}
```
No more juggling with property paths, no more fiddling with the graph walker. Just call on the execution context what you'd call on the validator and you're done.
There are two controversial things to discuss and decide (cc @fabpot):
* I moved the `@api` tags of all implementations to the respective interfaces. Is this ok?
* I would like to deprecate `ValidatorInterface::getMetadataFactory()` (tagged as `@api`) in favor of the added `ValidatorInterface::getMetadataFor()`, which offers the exact same functionality, but with a different API and better encapsulation, which makes it easier to maintain for us. We can tag `getMetadataFor()` as `@api`, as I don't expect it to change. Can we do this or should we leave the old method in?
I would like to decide the major issues of this PR until **Sunday November 25th** in order to give @fago enough room for his implementation.
Let me hear your thoughts.
This PR was merged into the 2.1 branch.
Commits
-------
84635bd [Form] allowed no type guesser to be registered
Discussion
----------
[Form] made the factory builder pass null when no type guesser registered
reopened#5422 against 2.1 as it's a bug fix
---------------------------------------------------------------------------
by stof at 2012-10-13T21:23:34Z
@fabpot anything left for this PR ?
---------------------------------------------------------------------------
by fabpot at 2012-10-14T09:41:29Z
@bamarni Can you add some unit tests and also update the FormExtensionInterface interface phpdoc as `getTypeGuesser` can now return `null`? Thanks. ping @bschussek
---------------------------------------------------------------------------
by bamarni at 2012-10-14T17:10:27Z
I've added a few tests covering this.
@fabpot : the phpdoc is already correct, it currently can return null, this only occurs with this convenient class.
---------------------------------------------------------------------------
by bschussek at 2012-10-16T07:43:41Z
This PR breaks FormFactory::createBuilderForProperty(), which expects a guesser to be present. Can you check the component for other uses of the guesser and add a null-check there?
---------------------------------------------------------------------------
by bamarni at 2012-10-16T10:57:54Z
I cannot find other places than the factory (searching for 'getTypeGuesser').
---------------------------------------------------------------------------
by bschussek at 2012-11-08T16:58:37Z
You should also adapt `FormRegistry::getTypeGuesser()` not to build a `FormTypeGuesserChain` if the array of guessers is empty. In that case it will return now `null` (adapt the doc block). We also need a different was of checking if the type guessers have already been parsed in FormRegistry. Otherwise the first if condition in `FormRegistry::getTypeGuesser()` will never become false. You could for example initialize the property `$guesser` to `false` and only set it to `null` after the first run of `getTypeGuesser()`.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:40:00Z
good catch I had missed it! I've applied your suggestion in the latest commit. Do you see anything else before I squash?
---------------------------------------------------------------------------
by bschussek at 2012-11-08T18:45:15Z
A test for `FormRegistry::getTypeGuesser()` would of course be awesome.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:52:13Z
Then it was already awesome! (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Tests/FormRegistryTest.php#L252)
I've also added one for the null case if it's what you meant.
* 2.1: (24 commits)
forced Travis to use source to workaround their not-up-to-date Composer on PHP 5.3.3
[Routing] removed irrelevant string cast in Route
Fixed typo
Make YamlFileLoader and XmlFileLoader file loading extensible
[HttpKernel] fix typo
Fixed singularization of "prices"
[Form] Removed an exception that prevented valid formats from being passed, e.g. "h" for the hour, "L" for the month etc.
[HttpKernel] fixed Client when using StreamedResponses (closes#5370)
fixed PDO session handler for Oracle (closes#5829)
[HttpFoundation] fixed PDO session handler for Oracle (closes#5829)
[Locale] removed a check that is done too early (and it is done twice anyways)
Update src/Symfony/Component/Validator/Resources/translations/validators.fa.xlf
Adding new localized strings for farsi validation.
[HttpFoundation] moved the HTTP protocol check from StreamedResponse to Response (closes#5937)
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
[Form] Excluded some tests in NumberToLocalizedStringTransformerTest which fail on ICU 4.4, but work on ICU 4.8
added missing tests from previous merge
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Fix export-ignore on Windows
Show correct class name InputArgument in error message
...
Conflicts:
.travis.yml
src/Symfony/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformer.php
This PR was merged into the 2.1 branch.
Commits
-------
4909bc3 [Form] Fixed forms not to be marked invalid if their children are already marked invalid
Discussion
----------
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4359
Todo: -
License of the code: MIT
Documentation PR: -
This PR prevents unsynchronized forms from being marked invalid if any of their children is also unsynchronized (and thus also marked invalid). Displaying an invalid message twice does not help the user and, if used in conjunction with error bubbling, may lead to duplicate errors (see #4359).
* 2.1:
removed unused use statements
[Form] Adapted HTML5 format in DateTimeType as response to a closed ICU ticket
[2.1][HttpFoundation] Fixed Php doc in Request::get
bumped Symfony version to 2.1.4-DEV
updated VERSION for 2.1.3
update CONTRIBUTORS for 2.1.3
updated CHANGELOG for 2.1.3
merged branch jakzal/yamlDoubleQuotesDumperFix (PR #4320)
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was squashed before being merged into the master branch (closes#5838).
Commits
-------
201f3e6 [Form] Fixed cannot unset string offsets in CsrfValidationListener
Discussion
----------
[Form] Fixed cannot unset string offsets in CsrfValidationListener
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
A php fatal error is happening when someone rewrite the entire form data for an object with a single input.
```
Fatal error: Cannot unset string offsets in vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Csrf/EventListener/CsrfValidationListener.php on line 72
```
Example:
```html
<form action="/app_dev.php/post/create" method="post" >
<div id="posttype">
<div>
<label for="posttype_name" class="required">Name</label>
<input type="text" id="posttype_name" name="posttype[name]" required="required" maxlength="255" />
</div>
<div>
<label for="posttype_text" class="required">Text</label>
<textarea id="posttype_text" name="posttype[text]" required="required"></textarea>
</div>
<input type="hidden" id="posttype__token" name="posttype[_token]" value="83a1617c694fbdea43c2527f1a55c7419ce82a42" /></div>
<p>
<button type="submit">Create</button>
</p>
</form>
```
If someone alters the html to add a simple input at the bottom of the form like this one:
```html
<input type="text" id="posttype" name="posttype" value="test123" />
```
The result will be a php fatal error.
---------------------------------------------------------------------------
by bschussek at 2012-10-26T09:49:05Z
Thank you for the pull request! Could you please reference the pull request in the test?
```php
// https://github.com/symfony/symfony/pull/5838
public function testStringFormData()
{
...
```
---------------------------------------------------------------------------
by jfcixmedia at 2012-10-26T10:21:29Z
@bschussek Added, thanks.
This PR was squashed before being merged into the master branch (closes#4115).
Commits
-------
878dd91 [2.2] [Form] Trim listener, unicode whitespace characters.
Discussion
----------
[2.2] [Form] Trim listener, unicode whitespace characters.
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo:
I have some questions. ZERO WIDTH SPACE (200B) doesn't belong to White_Space but it's invisible and treated as white space by the html4.1 spec - http://www.w3.org/TR/html4/struct/text.html#h-9.1
Same question for
* U+202F NARROW NO-BREAK SPACE
* U+FEFF ZERO WIDTH NO-BREAK SPACE
---------------------------------------------------------------------------
by Dattaya at 2012-04-26T09:49:25Z
It seems to me that the check `mb_check_encoding($data, 'UTF-8')` is unnecessary. For non utf8 characters `preg_replace` returns `null` if `u` flag is set.
From http://www.pcre.org/pcre.txt:
>When you set the PCRE_UTF8 flag, the byte strings passed as patterns
and subjects are (by default) checked for validity on entry to the rel-
evant functions.
...
>If an invalid UTF-8 string is passed to PCRE, an error return is given.
---------------------------------------------------------------------------
by Dattaya at 2012-07-27T06:52:58Z
Forgot to mention that `Cc` property includes more characters than needed (`0009-000D` and `0085`) but I think control characters shouldn't appear in a form field anyway.
---------------------------------------------------------------------------
by stof at 2012-10-13T16:47:47Z
@Dattaya ping
* 2.1: (28 commits)
Delete use of CreationExeption
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
[Form] Fixed creation of multiple money fields with different currencies
[Form] Fixed setting the "data" option to an object in "choice" and "entity" type
Fixed Serbian plural translations.
Fixed IPv6 Check in RequestMatcher
Fix typo
change what I think is a typo
[Console] Fix error when mode is not in PATH
[WebProfilerBundle] fixed macro usage (to be forward compatible with Twig 2.x)
Change monolog require-dev to use the branch alias instead of dev-master
[FrameworkBundle] partially reverted previous merge
[2.1] Added missing error return codes in commands
Made the router lazy when setting the context
[WebProfilerBundle] fixed typos
Fix incorrect variable in FileProfilerStorage
UnitTest fix
UnitTest fix
added a unit test
fixed#5384
...
* 2.0:
[Form] Fixed creation of multiple money fields with different currencies
Fixed IPv6 Check in RequestMatcher
fixed DomCrwaler/Form to handle <button> when submitted
Conflicts:
tests/Symfony/Tests/Component/DomCrawler/FormTest.php
tests/Symfony/Tests/Component/Form/Extension/Core/Type/MoneyTypeTest.php
This PR was merged into the 2.1 branch.
Commits
-------
bda29b3 [Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
Discussion
----------
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5388
Todo: -
License of the code: MIT
Documentation PR: -
Commits
-------
58ebd1b [Form] Fixed error bubbling from DateTime widget - Issue #52708ea1607 Update src/Symfony/Component/Form/Extension/Core/Type/DateTimeType.php
Discussion
----------
[Form] Fixed error bubbling from DateTime widget - Issue #5270
This is related to https://github.com/symfony/symfony/issues/5270
---------------------------------------------------------------------------
by mpiecko at 2012-08-16T19:37:45Z
Travisbot shows something like this in it's log:
[Composer\Downloader\TransportException] The "http://nodeload.github.com/phingofficial/phing/zipball/2.4.12" file could not be downloaded (HTTP/1.1 500 Internal Server Error)
So is it my PR ot Travis CI who fails ... ? I saw this error in some other PR's ...
---------------------------------------------------------------------------
by stloyd at 2012-08-16T20:40:39Z
It's GitHub =)
---------------------------------------------------------------------------
by mpiecko at 2012-08-17T09:36:31Z
Bad GitHub :)
---------------------------------------------------------------------------
by bschussek at 2012-08-17T11:21:39Z
Could you please add a test to DateTimeTypeTest?
---------------------------------------------------------------------------
by mpiecko at 2012-08-17T12:23:40Z
Sure!
---------------------------------------------------------------------------
by bschussek at 2012-08-30T08:20:08Z
👍
Commits
-------
e7e39e0 [Form] refactor Guess
dcbeeb1 [Form] replaced UnexpectedValueException by InvalidArgumentException in Guess
Discussion
----------
[Form] replaced UnexpectedValueException by InvalidArgumentException in Guess
BC break: yes
this is a better fit because the error is a logic exception (that can be detected at compile time, i.e. when writing the code) instead of a runtime exception
---------------------------------------------------------------------------
by bschussek at 2012-08-29T10:51:54Z
👍
Commits
-------
d5eb4f7 [Form] fix phpdoc of Form::hasErrors
5cb8264 [Form] deprecated Form::hasErrors that isn't part of the Interface
Discussion
----------
[Form] deprecated Form::hasErrors that isn't part of the Interface
This method is not part of FormInterface, so I deprecated it as it cannot be used reliably. This is consistent with other hassers that were deprecated like `hasChildren` where one should use `count` instead.
---------------------------------------------------------------------------
by stof at 2012-08-26T19:11:19Z
You should deprecate it, not remove it
---------------------------------------------------------------------------
by Tobion at 2012-08-26T19:17:35Z
oh right. I thought it was added in 2.1 and thus can be removed but it's also in 2.0.
Done.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:00:32Z
👍
Commits
-------
fb002d8 [Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Discussion
----------
[Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5029
Todo: -
This PR fixes two bugs.
The first bug is described in #5029. The second parameter to the "form_label" function in Twig, if given, always overwrote whatever label was defined previously.
```
{# null would overwrite whatever is currently set #}
form_label(form, null, { ... })
```
The second bug affected passing variables from outer to inner blocks. In the following example, "label_attr" would not be forwarded to the "form_label" function.
```
form_row(form, { "label_attr": { "class": "my_class" }})
```
Both bugs are fixed now.
Commits
-------
24b764e [Form] Fixed issues mentioned in the PR
9216816 [Form] Turned Twig filters into tests
310f985 [Form] Added a layer of 2.0 BC methods to FormView and updated UPGRADE and CHANGELOG
5984b18 [Form] Precalculated the closure for deciding whether a choice is selected (PHP +30ms, Twig +30ms)
5dc3c39 [Form] Moved the access to templating helpers out of the choice loop for performance reasons (PHP +100ms)
0ef9acb [Form] Moved the method isChoiceSelected() to the ChoiceView class (PHP +150ms)
8b72766 [Form] Tweaked the generation of option tags for performance (PHP +200ms, Twig +50ms)
400c95b [Form] Replace methods in ChoiceView by public properties (PHP +100ms, Twig +400ms)
d072f35 [Form] The properties of FormView are now accessed directly in order to increase performance (PHP +200ms, Twig +150ms)
Discussion
----------
[Form] Made FormView and ChoiceView properties public for performance reasons
Bug fix: no
Feature addition: no
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR changes the access to properties of `FormView` and `ChoiceView` objects from getters to direct property accesses. On [my example form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) this improves rendering performance for **300ms** with PHP templates and **550ms** with Twig on my local machine.
Unfortunately, this breaks BC both with 2.0 and with the current master in Form Types and PHP templates. Twig templates are not affected by this change.
2.0:
```
$formView->set('my_var', 'foobar');
$formView->get('my_var');
$formView->getChild('childName');
$formView['childName'];
```
master:
```
$formView->setVar('my_var', 'foobar');
$formView->getVar('my_var');
$formView->get('childName');
$formView['childName'];
```
this PR:
```
$formView->vars['my_var'] = 'foobar';
$formView->vars['my_var'];
$formView->children['childName'];
$formView['childName'];
```
Should we add methods to keep BC with 2.0?
The second part of this PR contains improvements to the rendering of choice fields. These gain another **~500ms** for PHP templates and **80ms** for Twig. These improvements are BC, unless you overwrote the block "choice_widget_options" in your form themes which then needs to be adapted.
**Update:**
The PR now includes a BC layer for 2.0.
---------------------------------------------------------------------------
by stof at 2012-07-21T11:37:41Z
@bschussek couldn't we keep the getters and setters for BC even if the rendering accesses the public properties directly ?
---------------------------------------------------------------------------
by bschussek at 2012-07-21T11:52:33Z
@stof A BC layer for 2.0 is now included. People who upgraded to master already unfortunately need to adapt their code.
---------------------------------------------------------------------------
by sstok at 2012-07-21T12:40:57Z
👍
Commits
-------
f71e2a8 [Form] FormBuilder Bug Fix: remove() was not properly removing children
Discussion
----------
[Form] FormBuilder Bug Fix: remove() was not properly removing children
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4803
License of the code: MIT
FormBuilder initially sets unresolved children as NULL, until resolved.
If FormBuilder::remove() is called before that child is resolved, the
if statement turns false, because isset(null) is false, when it should
be true. Instead, we should check to see if the key exists, and if so,
process and unset it.
Closes#4803
---------------------------------------------------------------------------
by bschussek at 2012-07-10T07:41:55Z
Can you please add a test covering this case?
---------------------------------------------------------------------------
by ChrisTickner at 2012-07-10T09:43:07Z
Sure, added a test case. It fails before the patch and passes after.
---------------------------------------------------------------------------
by bschussek at 2012-07-10T09:47:06Z
Thanks. Can you please add a comment to the test with the URL of this PR? Also, please squash your commits into one when your done.
---------------------------------------------------------------------------
by ChrisTickner at 2012-07-10T10:02:16Z
Oops, I deleted the remote branch and re-pushed without realizing we'd lose some history on this PR page. Live and learn I suppose.
---------------------------------------------------------------------------
by bschussek at 2012-07-10T10:18:20Z
Thanks!
FormBuilder initially sets unresolved children as NULL, until resolved.
If FormBuilder::remove() is called before that child is resolved, the
if statement turns false, because isset(null) is false, when it should
be true. Instead, we should check to see if the key exists, and if so,
process and unset it.
Closes#4803
Commits
-------
6ad4018 [Form] Also display the hint about adder/remover on invalid property access
Discussion
----------
[Form] Also display the hint about adder/remover on invalid property access
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
This PR follows up #4777. In this case the hint about adders and removers is also added when a property is found, but is not public, a common case.
Commits
-------
9c94b48 [Form] Fixed the "data" option to supersede default data set in the model
Discussion
----------
[Form] Fixed the "data" option to supersede default data set in the model
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3899
Todo: -
Commits
-------
df5bb4a [Form] Unified rendering of errors for nested elements
Discussion
----------
[Form] Unified rendering of errors for nested elements
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes?
Symfony2 tests pass: yes
Fixes the following tickets: #4615
Todo: -
Commits
-------
1345360 [Form] Fixed PropertyPath handling of offsetGet() that returns a constant value
6e1462e [Form] Fixed PropertyPath handling of __get() method that returns a constant
Discussion
----------
[Form] Fixed "Indirect modification.." exceptions in PropertyPath
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4450, #4535?, #4612
Todo: -
Commits
-------
040ba8f [Form] Fixed: ChoiceType omits the "empty_value" option if the choices contain an empty element
Discussion
----------
[Form] Fixed: ChoiceType omits the "empty_value" option if the choices contain an empty element
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3854, #3864
Todo: -
Commits
-------
1fa22d9 [Form] Output a more usable error when PropertyPath has tried to find adders and getters, but failed to find them
Discussion
----------
[Form] Output a more usable error when PropertyPath has tried to find ad...
...ders and getters, but failed to find them
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
I've refactored the writeProperty method of propertypath in order to supply a better error message when writing has failed.
The writeProperty method itself now finds singulars (if a singular was not passed) for the private findAdderAndRemover method which allowed for some duplicate code to be removed and since the writeProperty now holds this data, it can provide a more verbose exception message.
---------------------------------------------------------------------------
by bschussek at 2012-07-09T13:54:35Z
Apart from the typo this PR looks good.
---------------------------------------------------------------------------
by Burgov at 2012-07-09T14:01:04Z
fixed&squashed
Commits
-------
d6e1f39 [Form] Fixed FormBuilder to maintain order of its children
Discussion
----------
[Form] Fixed FormBuilder to maintain order of its children
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4693
Todo: -
Commits
-------
6f9eda9 [Form][Validator] Fixed generation of HTML5 pattern attribute based on Assert\Regex to remove delimiters.
Discussion
----------
[Form][Validator] Fixed generation of HTML5 pattern attribute based on Assert\Regex by removing delimiters or using a new option: htmlPattern.
Hopefully, this time is the good one…
* Fixes: [#3766, #4077, #4513, #4520, #4521]
* Bug fix: yes
* Feature addition: yes
* BC break: no
* Symfony2 tests pass: yes
In Issue #3766, it was asked that Assert\Regex generates HTML5 pattern attribute.
It was done in PR #4077, but the generated Regex is in delimited format which is not supported by HTML5.
Hence, `/[a-z]+/` would be converted to `[a-z]+`.
If flags are specified like in `/[a-z]+/i`, it cannot be converted and pattern validation will be disabled client-side. If is however now possible, using a new option, `htmlPattern`, to specify the pattern you want to be used.
Example:
```php
<?php
/**
* @Assert\Regex(pattern="/^[0-9]+[a-z]*$/i", htmlPattern="^[0-9]+[a-zA-Z]*$")
*/
private $civic_number;
```
**Note**: [Documentation](http://symfony.com/doc/current/reference/constraints/Regex.html) should be updated accordingly.
---------------------------------------------------------------------------
by lavoiesl at 2012-06-08T15:45:17Z
God, I just found out you can "add more commits to this pull request by pushing to the master branch on lavoiesl/symfony"…
---------------------------------------------------------------------------
by travisbot at 2012-06-08T15:50:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1568634) (merged 2d767b41 into b84b46ba).
---------------------------------------------------------------------------
by petajaros at 2012-07-04T14:23:16Z
Anything new about this issue?
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T16:25:43Z
Alright, tests are passing using `phpunit -c phpunit.xml.dist --filter 'RegexValidatorTest'`. @travisbot reports errors because he can’t even start the tests due to dependencies, which is not related
---------------------------------------------------------------------------
by vicb at 2012-07-04T16:31:13Z
It should be ready to merge when you have taken the last comments into account. thanks.
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T16:39:05Z
So it seems this PR will finally pass, thanks a lot.
---------------------------------------------------------------------------
by vicb at 2012-07-04T17:03:35Z
Thank you for this PR and the changes.
---------------------------------------------------------------------------
by fabpot at 2012-07-04T17:10:20Z
@lavoiesl Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T17:25:18Z
There. I also left trace of some commits I did.
Thanks
[Validator] Added delimiter escaping to Validator\Constraints\Regex::getNonDelimitedPattern
[Form][Validator] Added htmlPattern option for Regex Validation.
[Validator] Fixed Validator\Constraints\Regex::getNonDelimitedPattern variable declarations
[Validator] Fixed tests for Regex htmlPattern option (instead of html_pattern)
[Validation] tweaked generation of pattern to include .* when not anchors are present. Also removed the exception and made getNonDelimitedPattern private
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
-------
6b5b625 [Form] added FormBuilderInterface in Tests namespace, so as to enable easy mocking
Discussion
----------
[Form] added FormBuilderInterface in Tests namespace, so as to enable ea...
...sy mocking
Adding a ``FormBuilderInterface`` in the ``Tests`` namespace, along same lines as ``FormInterface`` already there, for the purposes of being able to mock it straightforwardly (as ``FormBuilderInterface`` extends ``\Traversable``, and therefore creating a mock in PHPUnit causes a fatal error that the mock ``must implement interface Traversable as part of either Iterator or IteratorAggregate``). Currently in the tests a ``FormBuilder`` object is used with a mock event dispatcher and form factory passed into the constructor, but this is long-winded to have to do in tests for code outside the framework.
---------------------------------------------------------------------------
by travisbot at 2012-06-13T22:03:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1613957) (merged 6b5b625a into c07e9163).
---------------------------------------------------------------------------
by bschussek at 2012-06-14T07:22:33Z
👍
Commits
-------
a30f4a0 [Form] cleanup
Discussion
----------
[Form] cleanup
---------------------------------------------------------------------------
by travisbot at 2012-05-27T19:47:21Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1450050) (merged 09574f4b into adf07f1e).
---------------------------------------------------------------------------
by travisbot at 2012-05-27T19:57:42Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1450149) (merged a8c63d72 into adf07f1e).
---------------------------------------------------------------------------
by vicb at 2012-05-27T20:00:13Z
thanks a bunch @travisbot !
---------------------------------------------------------------------------
by travisbot at 2012-05-28T06:52:52Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1453555) (merged a30f4a03 into adf07f1e).
---------------------------------------------------------------------------
by bschussek at 2012-05-28T09:20:05Z
Thank you Victor! 👍
Commits
-------
b4e2818 [Form] Using new methods instead of the deprecated
Discussion
----------
[Form] Using new methods instead of the deprecated
---------------------------------------------------------------------------
by travisbot at 2012-05-25T21:05:11Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1436891) (merged b4e28186 into ff4d446c).
fixed bug with parent property
fix is_required field
fixed subform translation_domain inheritance
some translation_domain inheritance code refactoring
added form type translation_domain inheritance tests
changed methods place in form type test
changed arguments in createNamed method call in FormTypeTest
Commits
-------
82c221a [Form] Fixed strict "data_class" check to work with instances of \ArrayAccess
Discussion
----------
[Form] Fixed collection type to work with recent Form changes
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by tristanbes at 2012-05-22T16:42:36Z
Ping @fabpot Could you please merge it ASAP, because this bugs breaks all forms containing collection type.
Thanks
---------------------------------------------------------------------------
by travisbot at 2012-05-22T16:54:24Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1401580) (merged 82c221a1 into 1a1403f5).
This reverts commit 5182a0c2c4.
PropertyPath instances should be empty. If you have an empty property path string, there is no need to create a PropertyPath instance for it.
Conflicts:
tests/Symfony/Tests/Component/Form/PropertyPathTest.php
Commits
-------
95727ff [OptionsResolver] Updated PHP requirements to 5.3.3
1c5f6c7 [OptionsResolver] Fixed issues mentioned in the PR comments
d60626e [OptionsResolver] Fixed clear() and remove() method in Options class
2b46975 [OptionsResolver] Fixed Options::replace() method
16f7d20 [OptionsResolver] Improved implementation and clarity of the Options class
6ce68b1 [OptionsResolver] Removed reference to non-existing property
9c76750 [OptionsResolver] Fixed doc and block nesting
876fd9b [OptionsResolver] Implemented fluid interface
95454f5 [OptionsResolver] Fixed typos
256b708 [OptionsParser] Renamed OptionsParser to OptionsResolver
04522ca [OptionsParser] Added method replaceDefaults()
b9d053e [Form] Moved Options classes to new OptionsParser component
Discussion
----------
Extracted OptionsResolver component out of Form
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=options)
This PR refactors the options-related code of the Form component into a separate component. See the README file for usage examples.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-17T18:11:03Z
To me it seems like we have some redundancy with the Config/Definition component. I'm wondering if these two can/should be merged somehow?
---------------------------------------------------------------------------
by kriswallsmith at 2012-04-17T18:14:44Z
I would also suggest merging this into the Config component. Its current name too closely resembles Python's optparser lib, which could create confusion.
---------------------------------------------------------------------------
by bschussek at 2012-04-17T18:18:49Z
Merge conflict artifacts are fixed now.
@schmittjoh Do we? Isn't the idea of the Config component to read complex configuration from different configuration providers? (YAML, XML, Annotations etc.)
The idea of this parser is to be highly performant and to be usable in simple classes. If this can be achieved with the Config component, I'm happy to learn more.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-17T18:27:08Z
The config component is basically a super intelligent version of array_merge and the like.
About performance, I haven't really done any tests to say something about the impact. I think it's safe to say that it would be at least slower than your implementation in its current form due to the additional indirection. However, we could probably add a caching layer.
---------------------------------------------------------------------------
by bschussek at 2012-04-17T18:31:22Z
Have you checked the README I wrote? Are you sure the Config component is intended for the same purpose and not *way* too complex in this case?
---------------------------------------------------------------------------
by stof at 2012-04-17T18:51:14Z
You also forgot to update the ``replace`` section of the root composer.json file.
And regarding doing such thing with the Config Definition stuff, it would be more difficult: it builds the tree of values with their defaults, and then merges stuff coming from different sources. The form component however receives defaults from different places (which also define the allowed keys at the same time) and then receives user options only once. And it needs to handle easily default values which depend from other values. So I think both implementations are useful for different needs (however, we could argue about making it a subnamespace in the Config component, but this would add yet another different stuff in it)
---------------------------------------------------------------------------
by jalliot at 2012-04-17T18:58:03Z
@bschussek You need to add this component to the main composer.json too.
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T06:54:17Z
doesn't this overlap a bit with the ``TreeBuilder`` in the Config component?
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T06:59:12Z
ah just saw @stof's comment .. i think the biggest argument against TreeBuilder is that it was designed for a very specific purpose and performance wasn't one of them. where as Form needs something that performs fast. so yeah i do see different use cases, but i don't think this means we should have a new component.
furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T08:10:49Z
@stof, @jalliot: Fixed.
> furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.
@lsmith77: Because that's not what this component does. The key feature of this component is to resolve default values of options that depend on the *concrete* values of other options. I invite you to read the README.
Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configurations from storage providers, such as the filesystem.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T08:18:48Z
Note: Not all relevant code of this component is shown in the diff. The (crucial) Options and LazyOption classes have only been moved out of Form.
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T08:20:02Z
> Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configuration values from the filesystem (typically).
decoupled is all fine, but to me this feels a bit too granular. but i am just expressing a gut feeling here
---------------------------------------------------------------------------
by jalliot at 2012-04-18T08:34:03Z
I think too it should be included in the config component (maybe in a subnamespace). Indeed the behaviour is too different to be merged into the current component but its purpose is similar and is all about *configuration* (hence the name of the component). Otherwise we could also split the current Config component into smaller components as it seems to me there are already parts of it that are totally unrelated to each other.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T11:30:55Z
@jalliot Can you go into detail which parts that are and what changes you suggest?
@kriswallsmith Any other naming suggestion?
---------------------------------------------------------------------------
by jalliot at 2012-04-18T11:34:35Z
@bschussek I don't know the current component well enough but that's the impression I had last time I looked at its code but I may be wrong.
---------------------------------------------------------------------------
by stof at 2012-04-18T19:30:43Z
@bschussek the Definition subnamespace of the Config component is standalone. It is not directly related to the Loader part
---------------------------------------------------------------------------
by bschussek at 2012-04-19T09:32:48Z
@stof So what do you recommend?
I think this is also a question of marketing. Is the Definition subnamespace intended to be used totally separately of the loaders? What are the use cases? If there are good use cases, it makes sense to me to extract the Definition part into a separate component. Otherwise not.
It is also a question of marketing, because the purpose of a component should be communicable in simple words (quoting @fabpot). The purpose of Config is (copied from the README):
> Config provides the infrastructure for loading configurations from different data sources and optionally monitoring these data sources for changes. There are additional tools for validating, normalizing and handling of defaults that can optionally be used to convert from different formats to arrays.
I think this purpose is completely different than that of OptionsParser.
---------------------------------------------------------------------------
by stof at 2012-04-19T11:39:50Z
The current description itself shows the current state: what is advocated as the main goal of the component (and was the original part) is the loader stuff. But the Definition part (mentioned as "additional tools") is bigger in term of LOC
---------------------------------------------------------------------------
by bschussek at 2012-04-19T11:55:17Z
@stof: Yes, this is a fact, but what's your opinion? How do we proceed with this PR?
---------------------------------------------------------------------------
by stof at 2012-04-19T12:21:44Z
Well, my opinion is that the current Config component may deserve to be split into 2 components (as someone may need only part of it). But this would be a huge BC break. @fabpot what do you think ?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T10:14:57Z
@fabpot Can we merge this?
---------------------------------------------------------------------------
by fabpot at 2012-05-10T06:45:20Z
@bschussek I'm +1 for this PR but as mentioned by @kriswallsmith, we must find another name as `OptionsParser` immediately make me think of something related to the CLI.
---------------------------------------------------------------------------
by stof at 2012-05-10T06:47:45Z
However, after thinking about it again, I would vote for keeping it in its own component instead of adding yet another independant part in Config, to avoid forcing Form users to get the whole Config component
---------------------------------------------------------------------------
by bschussek at 2012-05-10T09:09:36Z
I'm having difficulties finding a better name. The main difference to CLI option parsers is that these actualy *parse* a string, while this class only receives an array of options (does not do any parsing). Otherwise both have the same purpose.
A couple of other suggestions:
* OptionsLoader (likely confused with our filesystem loaders)
* OptionsResolver
* OptionsMerger
* OptionsMatcher (not accurate)
* OptionsBuilder (likely confused with the builder pattern)
* OptionsJoiner
* OptionsBag (likely confused with the session bags)
* OptionsConfig (likely confused with Config)
* OptionsDefinition (likely confused with Config\Definition)
* OptionsSpec
* OptionsCombiner
* OptionsInitializer
* OptionsComposer
The difficulty is to find a name that best reflects its purpose:
```
$parser->setDefaults(...);
$parser->setRequired(...);
$parser->setOptional(...);
$parser->setAllowedValues(...)
$parser->parse($userOptions);
```
The only of the above examples that makes sense to me here is OptionsResolver -> resolve($userOptions).
Ideas?
---------------------------------------------------------------------------
by stof at 2012-05-10T09:56:54Z
OptionsResolver seems a better name than OptionsParser
---------------------------------------------------------------------------
by luxifer at 2012-05-10T09:59:45Z
Agree with @stof
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T10:03:53Z
I don't really like the plural in the name, but OptionsResolver seems better than OptionsParser. OptionResolver maybe?
---------------------------------------------------------------------------
by sstok at 2012-05-10T10:10:14Z
@r1pp3rj4ck Options makes more sense as they can be nested/deeper, and thus are multiple.
Agree with @stof also.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T10:13:01Z
@sstok well, we have multiple events too and the name is EventDispatcher, not EventsDispatcher. Actually none of the component names are plural.
---------------------------------------------------------------------------
by newicz at 2012-05-10T10:33:50Z
OptionsResolver - I find it suggesting that there is some kind of problem to be resolved and there's not,
maybe OptionsDefiner but it isn't good aswell this is a tough one
Commits
-------
c195957 [Components] Tests/Autoloading fixes
Discussion
----------
Fix components
See #4141
----
This PR:
* configures each component to use composer to manage "dev" dependencies instead of env variables;
* adds phpunit configuration file on Filesystem component;
* fixes READMEs.
It's mergeable without any problems, but I would recommend to wait a fix in Composer in order to use `self.version` in `require`/`require-dev` sections.
Note: I kept `suggest` sections because it makes sense but this PR doesn't aim to provide useful explanations for each entry. It could be another PR, not that one.
---------------------------------------------------------------------------
by willdurand at 2012-04-30T20:43:13Z
@fabpot I reviewed each component, one by one. Now `phpunit` always works, even if tests are skipped. A simple `composer install --dev` allows to run the complete test suite. Each commit is well separated from the others. I guess, everything is ok now.
---------------------------------------------------------------------------
by Tobion at 2012-04-30T20:47:00Z
Please squash, as it makes no sense to have the same commit for each component.
---------------------------------------------------------------------------
by fabpot at 2012-05-01T14:26:11Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T14:29:38Z
done
---------------------------------------------------------------------------
by fabpot at 2012-05-01T15:48:25Z
It does not seem that the commits are squashed.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T15:54:08Z
done
* Switched to Composer to manage "dev" dependencies
* Fixed READMEs
* Excluded vendor in phpunit.xml.dist files
* Fixed message in bootstrap.php files
* Added autoloader for the component itself
CSRF fields are now only added when the view is built. For this reason we already know if
the form is the root form and avoid to create unnecessary CSRF fields for nested fields.
In order to perform some introspection on a FormBuilder instance,
we need to be able to get its children. Almost everything is accessible
in this class, but the children are not.
This PR adds a all() method to respect the current API (get(), remove(),
...).
This demonstrates the issue described in symfony/symfony#3354. FieldType no longer has access to the child type's data_class option, which makes it unable to create the default closure for empty_data.
Commits
-------
c4e68a3 [Form] Moved logic of addXxx()/removeXxx() methods to the PropertyPath class
Discussion
----------
[Form] Moved logic of addXxx()/removeXxx() methods to the PropertyPath class
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3732
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3732)
The addXxx()/removeXxx() methods should now be called correctly in ChoiceType and CollectionType.
PropertyPath now favors addXxx()/removeXxx() over setXxx() for collections. For example:
```
$propertyPath = new PropertyPath('article.tags');
// Tries to use addTag()/removeTag() and only uses setTags() (et al.)
// if not found
$propertyPath->setValue($article, $tags);
```
For other languages than English or very irregular plurals, a custom singular can be set by separating it with a pipe:
```
$propertyPath = new PropertyPath('article.genera|genus');
```
---------------------------------------------------------------------------
by bschussek at 2012-04-07T12:40:39Z
Again, the failing build is not my fault.
Commits
-------
61d792e [Form] Changed checkboxes in an expanded multiple-choice field to not include the choice index
bc9bc4a [Form] Fixed behavior of expanded multiple-choice field when submitted without ticks
2e07256 [Form] Simplified choice list API
2645120 [Form] Fixed handling of expanded choice lists, checkboxes and radio buttons with empty values ("")
Discussion
----------
[Form] Fixed handling of empty values in checkbox/radio/choice type
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3839, #3366
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3839)
This PR fixes the processing of checkboxes and radio buttons with empty "value" attributes as well as of expanded choice forms with empty values. Additionally, some unnecessary complexity has been removed of the new ChoiceList API.
---------------------------------------------------------------------------
by stof at 2012-04-10T13:56:12Z
You probably need to change some things in the CHANGELOG file too
---------------------------------------------------------------------------
by bschussek at 2012-04-10T14:39:24Z
No. This is an update of a previous post-2.0 PR, the CHANGELOG is still accurate.
---------------------------------------------------------------------------
by stof at 2012-04-10T14:46:47Z
well, doesn't it require changes to the description of previous changes related to the ChoiceList ? It does in the UPGRADE file so it is weird if the CHANGELOG does not require any change.
---------------------------------------------------------------------------
by bschussek at 2012-04-10T14:56:05Z
Feel free to check yourself :)
Setting a property path like "article.tags" will now automatically try to
favor addTag() and removeTag() over setTags(), if found. If you want to
set up a property path with an irregular singular that is not detected,
you can use "|" to separate the plural from the singular form in the
path: "article.genera|genus".
Another consequence of this commit is that the MergeCollectionListener has
been simplified a lot. Forms returning an array or a collection will
always result in adders/removers being called now without having to add
this listener.