Commits
-------
36cebf0 Fix infinite loop on circullar reference in form factory
Discussion
----------
[BugFix][Form]Throw exception on form name circulal ref
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Closes: #2673
When FormType method `getName()` returns the same value as `getParent()` we're asking about trouble, and land into infinite loop.
Commits
-------
57e1aeb Fixed undefined index notice in readProperty() method (PropertyPath)
Discussion
----------
Fixed undefined index notice in readProperty() method (PropertyPath)
Hi,
For some reasons, I get `notice` errors on `readProperty()` with Propel:
Notice: Undefined index: 0 in /Users/william/projects/Propel/testProjects/symfony2/vendor/symfony/src/Symfony/Component/Form/Util/PropertyPath.php line 284
The `PropelObjectCollection` implements `ArrayAccess`, the `readProperty()` method does not check if the given `index` exists so the `notice` error is thrown. I suppose to check whether the index exists or not has to be added.
Regards,
William
---------------------------------------------------------------------------
by fabpot at 2011/09/27 23:42:07 -0700
The patch is probably not what we want to do. First, I suppose that you are not creating the propertyPath by hand. If that is the case, we need to understand why the property path does not exist. Then, even if we might want to check the existence of the index, if it does not exist, we should probably throw an exception instead of just ignoring the problem.
---------------------------------------------------------------------------
by willdurand at 2011/09/28 01:14:49 -0700
My bad. This is a Propel bug due to `ArrayObject`. It throws a notice error if the index is not found in `offsetGet()` which is wrong according to the `ArrayAccess` interface. If the index is not found, we have to return `null`.
@fabpot Are you agree with that (for the `null` value) ?
---------------------------------------------------------------------------
by fabpot at 2011/09/28 01:17:09 -0700
My point is that it should never happen under normal circumstances.
---------------------------------------------------------------------------
by willdurand at 2011/09/28 01:23:55 -0700
@fabpot Not sure to get it.
The fact is that it tries to get the value (`getValue()`) of a fresh object, just added to the `collection` when I'm submitting a form with a `CollectionType` and a new entry in it.
I mean it tries to get this new object (not yet persisted, not yet in the collection) in the collection (`getValue()` -> `readProperty()`) which implements `ArrayAccess` but this object cannot be in the collection at this time.
Am I wrong ?
And, without this notice error thrown by Propel, I probably never opened this issue...
---------------------------------------------------------------------------
by willdurand at 2011/09/29 06:40:34 -0700
@fabpot: you can try this example: http://www.propelorm.org/cookbook/symfony2/mastering-symfony2-forms-with-propel.html#manytomany_relations in order to make your own tests. Will it be enough?
As I said, it throws a weird notice for the reasons above.
---------------------------------------------------------------------------
by jaugustin at 2011/10/04 12:58:10 -0700
any news on this ?
@fabpot did you have time to look at the test case ?
---------------------------------------------------------------------------
by cedriclombardot at 2011/11/09 14:29:42 -0800
@fabpot: can we have news about this ?
Commits
-------
79ae3fc [Form] fixed radio and checkbox when data is not bool
Discussion
----------
[Form] fixed checkbox view
The checkbox view was being built based on app data, not client data. This fixes it.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by fabpot at 2011/11/16 13:31:09 -0800
`RadioType` suffers from the same problem, no?
---------------------------------------------------------------------------
by kriswallsmith at 2011/11/16 13:32:50 -0800
Yeah, I'll fix that too.
---------------------------------------------------------------------------
by kriswallsmith at 2011/11/16 13:43:29 -0800
Updated to include `RadioType`.
Commits
-------
8399574 Fixes a small php doc issue of Symfony\Component\Console\Command\Command::setDefinition()
Discussion
----------
Fixes a small php doc issue of Symfony\Component\Console\Command\Command::setDefinition()
Have setDefinition() accept InputDefinition instead of Definition.
Commits
-------
29e12af [TwigBundle] Extract output buffer cleaning to method
ed1a6c2 [TwigBundle] Do not clean output buffering below initial level
Discussion
----------
[TwigBundle] Do not clean output buffering below initial level
This resulted in issues with PHPUnit 3.6, which will buffer all output and clean them in the end. Since
we cleaned their buffer, the subsequent clean would raise a warning. This is documented in [issue 390](https://github.com/sebastianbergmann/phpunit/issues/390) of
the PHPUnit tracker.
Closes#2531.
This also affects FOSRestBundle's ExceptionController /cc @lsmith.
---------------------------------------------------------------------------
by fabpot at 2011/11/11 07:33:24 -0800
I have a similar fix locally but I have not merged it yet as it looks a bit dirty (but I've not a better idea yet). Anyway, your PR is better than mine as you've added some unit tests already.
Commits
-------
2582fcb Added tests for string fix in DateTimeToArrayTransformer (8351a11286).
8351a11 Added check for array fields to be integers in reverseTransform method. This prevents checkdate from getting strings as arguments and throwing incorrect ErrorException when submitting form with malformed (string) data in, for example, Date field. #2609
Discussion
----------
Fix for #2609
Second take for fix for #2609, hope it's ok now. Tests are failing without my fix and passing with it.
This resulted in issues with PHPUnit 3.6, which will buffer all output and clean them in the end. Since
we cleaned their buffer, the subsequent clean would raise a warning. This is documented in issue 390 of
the PHPUnit tracker.
Closes#2531.
Commits
-------
f9befb6 Remove only the security token instead of the session cookie.
348bccb Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
Discussion
----------
Fix for issue 1798
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
---------------------------------------------------------------------------
by snc at 2011/11/01 04:01:49 -0700
@stof I have changed the code so that it only removes the token... do we still need any hook support?
---------------------------------------------------------------------------
by stof at 2011/11/01 04:07:17 -0700
well, the hook is for your own use case but it would be for 2.1 only anyway, not for 2.0
---------------------------------------------------------------------------
by snc at 2011/11/07 15:11:52 -0800
Now that #2414 is merged to 2.1, this could be simplified for the master branch...
Commits
-------
7346896 Changed Serialized#supportsNormalization to PRIVATE
e851efc Updated SerializerTest with "normalizeTraversable" & "testNormalizeGivesPriorityToInterfaceOverTraversable"
d789f94 Serializer#normalize gives precedence to objects that support normalization
9e6ba9a Added protected Serializer#supportsNormalization
Discussion
----------
[Serializer] `normalize` should use supported normalizer before Traversable
Bug fix: yes
Feature addition: no
Backwards compatibility break: no (discussion needed)
Symfony2 tests pass: yes
Fixes the following tickets: #2295
**Same as PR #2539, except rebased onto `2.0`**
Should I abstract out a `supportsDenormalization` function just for symmetry?
Commits
-------
ffa537c replace occurences of "an UserInteface" with "a UserInterface"
Discussion
----------
replace occurences of "an UserInteface" with "a UserInterface"
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)
