Commits
-------
fbd2a0e make suggested changes for default value
c507b1d update variable name to match the option name
b53f000 add the ability to set the form prototype name in CollectionType. this will aid in handling nested collections in forms
Discussion
----------
[Form] Collection
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: [#1324](https://github.com/symfony/symfony/issues/1324)
add the ability to set the form prototype name in CollectionType. this will aid in handling nested collections in forms
---------------------------------------------------------------------------
by IamPersistent at 2011/10/17 02:54:45 -0700
Actually, as an afterthought, I looked over at the issues and this is basically https://github.com/symfony/symfony/issues/1324 just adding an extra option instead of using the prototype option.
@stloyd, my thought was handling the case where someone was "clever" enough to set the 'prototype_name' option to "". But I could be over-thinking :)
---------------------------------------------------------------------------
by stloyd at 2011/10/17 03:00:23 -0700
@IamPersistent IMO if someone is setting this option, he should be aware of that problem, also AFAIK `$$$$` could be *valid* name too ;-)
---------------------------------------------------------------------------
by IamPersistent at 2011/10/17 03:02:14 -0700
@stloyd, I'm fine with changing it, I'll wait to see what everyone else has to say about this request vs using the prototype option for the name in 1324
---------------------------------------------------------------------------
by IamPersistent at 2011/10/17 03:28:49 -0700
@stloyd, @stof, I made the suggested changes, now I suppose, let the debate begin over PR1324 vs this
---------------------------------------------------------------------------
by stloyd at 2011/10/17 03:47:53 -0700
IMO this PR makes changing prototype name in more clean way, so I would prefer this one over that proposed in #1324.
Commits
-------
89cd64a Set error code when number cannot be parsed. Fixes#2389
Discussion
----------
Set error code when number cannot be parsed in StubNumberFormatter
The stub implementation of NumberFormatter never sets an error code and instead always returns the "no-error" code. This causes unexpected results when a transformer gives it bad arguments, such as transforming the input value to boolean false and causing exceptions further down the line, as in #2389.
Instead, it should set an error code when appropriate and return it when requested so that a TransformationFailedException can be raised and the input value left unaltered.
There may be other instances where an error should be set. This covers the common use case of non-numeric input.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2389
Commits
-------
c9d05d7 Let NumberFormatter handle integer type casting
Discussion
----------
Let NumberFormatter handle integer type casting
The integer to localised string transformer is currently casting everything it gets to an integer, even if it is not a number. This responsibility should be passed off to NumberFormatter.
Partially addresses #2389 by not mistakenly typecasting a boolean false into an integer 0
---------------------------------------------------------------------------
by mrtorrent at 2011/10/30 15:04:28 -0700
Apologies, forgot the template:
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2389 (partial)
Commits
-------
316eacb Fixed merge conflict.
Discussion
----------
Fixed merge conflict
There was a merge conflict in the composer.json file of the doctrine bridge...
Commits
-------
eca414b Fixed incomplete EntityType tests
Discussion
----------
[Doctrine] [Form] (Re: #2472) Fixed incomplete EntityType tests
**Previously #2472, but rebased onto `symfony/2.0` per @fabpot's request. See #2472 for more info**
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: N/A
Commits
-------
05a4e9d [Validators][Type] Added support for ctype_* functions + tests
Discussion
----------
[Validators][Type] Added support for ctype_* functions + tests
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Not sure if the ctype_* functions support should be included in the AssertTypeValidator or in a dedicated one.
What do you think ?
Commits
-------
cbd0c3c [Config] Implemented Serializable on resources
Discussion
----------
[Config] Implemented Serializable on resources
bug fix: no
feature addition: no
BC break: not really. you simply need to clear your cache in debug mode
test passes: yes
Serializing private variables without implementing Serializable uses far more space as it prepend the fully qualified class name before the name of each property. This change allows keeping the meta file smaller.
Commits
-------
6cb7acf CS - camelCase & curly braces
d9b7abb Added EntityChoiceList test for `group_by` and invalid, deep property paths
e6554d6 Removed Closure support from group_by (PropertyPath strings only)
037933a CS - (String) renamed to (string)
7ad0f05 Added group_by test for EntityType
882482a Added group_by tests for EntityChoiceList
040e988 `EntityChoiceList` now supports grouping of entities by property path or closure
b171a6a Added `group_by` to EntityType
Discussion
----------
[Doctrine] [Form] EntityType+EntityChoiceList supports grouping choices
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1735
Per the discussion in #1735, `EntityType` does not immediately support grouping options, though I updated support for it in `EntityChoiceList` in fb9d951b1d.
This PR accomplishes the following:
* Adds optional `group_by` property to `EntityType` that supports either a `PropertyPath` or a `\Closure` that is evaluated on the entity choices
* Support for groups is added via the constructor in `EntityChoiceList`
* Groups are created prior to `EntityChoiceList#loadEntities` via a new `groupEntities` function
* Added tests for `EntityChoiceList`
* Added test for `EntityType` `group_by` support
*There is an alternative version that only modifies `EntityType`, but that requires the addition of `EntityType#buildView(...)`, which is messy, IMO: https://github.com/ericclemmons/symfony/compare/master...1735-entity_type_group_by*
---------------------------------------------------------------------------
by fabpot at 2011/10/25 01:48:23 -0700
ping @beberlei
---------------------------------------------------------------------------
by beberlei at 2011/10/25 03:06:05 -0700
I didnt run the tests, but generally this looks very good and is a good extension.
---------------------------------------------------------------------------
by beberlei at 2011/11/01 06:25:09 -0700
@fabpot i revewied this and it looks very good, tests all pass, i think this is a very nice addition.
Commits
-------
149bdb9 Enhance error messages with regard to form type properties.
Discussion
----------
[Form] Enhanced error messages
With this patch its much easier to see what went wrong with a form type and what the possible options are.
Also added tests for this error conditions.
Commits
-------
661421f [Doctrine] Remove AbstractDoctrineBundle and move code into Doctrine Bridge
Discussion
----------
[WIP] [Doctrine] Remove abtract doctrine bundle
Remove AbstractDoctrineBundle and move code into Doctrine Bridge. It is a BC break because all the "other" Doctrine Bundles MongoDB ODM, CouchDB ODM and PHPCR need to be updated to cope with this.
I will prepare PRs for them aswell and then remove the [WIP] here.
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #2463
---------------------------------------------------------------------------
by beberlei at 2011/10/26 12:32:51 -0700
Here are all 3 PRs, can we coordinate on merging them somehow?
https://github.com/symfony/DoctrineMongoDBBundle/pull/50https://github.com/symfony-cmf/symfony-cmf/pull/118https://github.com/doctrine/DoctrineCouchDBBundle/pull/4
---------------------------------------------------------------------------
by beberlei at 2011/10/26 12:33:38 -0700
Ping @lsmith77 @jwage
---------------------------------------------------------------------------
by lsmith77 at 2011/10/26 12:35:29 -0700
all good for me ..
---------------------------------------------------------------------------
by stof at 2011/10/26 14:58:01 -0700
Well, this does not fix#2463. A change done in the bridge will still be able to break the service definitions of the other bundles or require tricky stuff to keep different versions of the logic.
---------------------------------------------------------------------------
by beberlei at 2011/10/26 22:49:39 -0700
@stof true, that is what https://github.com/doctrine/common/pull/71 will be about.
---------------------------------------------------------------------------
by stloyd at 2011/10/26 23:51:25 -0700
Comment just for linking cross PRs and for watching ;-) doctrine/common#71
---------------------------------------------------------------------------
by lsmith77 at 2011/10/31 08:18:45 -0700
please add forward compatibly into symfony 2.0 as per #2522
---------------------------------------------------------------------------
by beberlei at 2011/11/01 05:11:34 -0700
This doesn't make sense imho, since the number of people using the doctrine extension is 4 and everybody also prepared their pull request for this.
The problem is really that we need a branch for the MongoDB Bundle
---------------------------------------------------------------------------
by beberlei at 2011/11/01 05:40:49 -0700
@fabpot i created a branch in MongoDBBundle for 2.0 so this is ready to be merged.
Commits
-------
dec1858 Fixed typo
Discussion
----------
Fixed typo
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
This PR is the 2.0 branch version of #2519
Commits
-------
80f0b98 [DependencyInjection] Fix DefinitionDecorator::getArgument() for replacements
4bbb685 [DependencyInjection] Test Definition and DefinitionDecorator exceptions
Discussion
----------
[DependencyInjection] Fix getArgument() for replaced definition arguments
I was implementing something that worked with DefinitionDecorators before the container was compiled and ran into some missing functionality. While I was tinkering, I also added some additional tests for exceptions in both Definition and DefinitionDecorator.
While Definition::getArgument() could be used to fetch replaced values, it relied upon bad comparison logic (e.g. "index_1" > 1). Additionally, storing original arguments and replacements in the same array makes Definition::getArguments()'s bounds check unreliable. A single argument and its replacement would count twice, allowing getArgument(2) to pass the bounds check and result in an array index error.
With this new method, fetching of replacement arguments is more straightforward and bounds checking functions as it should.
