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
-------
c6cb8b2 [Form] Removed unused option "inline" that was introduced by accident
Discussion
----------
[Form] Removed unused option "inline" that was introduced by accident
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Commits
-------
854daa8 [Form] Fixed errors not to be added onto non-synchronized forms
Discussion
----------
[Form] Fixed errors not to be added onto non-synchronized forms
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4686
Todo: -
Commits
-------
e8bb834 [Form] Fixed data to be written back by PropertyPath if it cannot be handled by reference
Discussion
----------
[Form] Fixed data to be written back by PropertyPath if it cannot be handled by reference
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4535
Todo: -
Commits
-------
c061c30 Router#resolveString should return null instead of empty string when $value is null
a1d1a02 Null default value route regression
Discussion
----------
[Router] Null default value route regression
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4823
Todo:
License of the code: MIT
Documentation PR:
---
The commit by @vicb 0555913fbb introduces a regression in the handling of default values that are null, while there are requirements still set for this value.
This is a failing test case and fix for the issue.
---------------------------------------------------------------------------
by merk at 2012-07-10T04:24:40Z
Now contains a fix, tests now pass.
Commits
-------
2fa98e8 [FrameworkBundle] Changed DelegatingEngine::renderResponse to use specified engine's renderResponse
Discussion
----------
[FrameworkBundle] Changed DelegatingEngine::renderResponse to use specified engine's renderResponse
Currently the DelegatingEngine in the FrameworkBundle has a renderResponse method that creates a new response, it should use the engine's renderResponse since EngineInterface requires a renderResponse to be defined and gives more flexibly to change the response object when creating a new templating engine.
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
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
-------
7727de7 [Form] Deprecated Form::bindRequest() and replaced it by a PRE_BIND listener
Discussion
----------
[Form] Deprecated Form::bindRequest() and replaced it by a PRE_BIND listener
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Instead of `bindRequest`, you should now simply call `bind`:
Before:
```
$form->bindRequest($request);
```
After:
```
$form->bind($request);
```
Commits
-------
dc4d343 [TwigBundle] Fixed error message
Discussion
----------
[TwigBundle] Fixed error message
Small fix to display the filename that cannot be read in the Twig Lint command.
Commits
-------
ec8c023 Serbian Cyrillic translation updated.
Discussion
----------
Serbian Cyrillic translation updated.
Shouldn't source messages be updated in all files in one commit? Also, version is 1.2 in both, en and sr files, but source messages are not.
I would like to be notified whenever translation is changed, maybe we should have some topic on mailing list so all translators can receive notifications once messages are changed.
Commits
-------
a6d44bd When serializing a Route, don't serialize the compiled route.
Discussion
----------
When serializing a Route, don't serialize the compiled route.
The compiled route typically has a reference to the Route. The Route of course has a reference to the compiled route. This is a circular reference. That can sometimes cause issues, say for var_export(). I ran into this issue while serializing route objects, but it could happen in other cases, too.
In any event, since the compiled route object is simply derived data I see no reason to keep it around. If we serialize a Route, we just want the basic route information. We can recompile later if needs be. As a nice side-effect, this makes the serialized string much smaller.
---------------------------------------------------------------------------
by stof at 2012-07-04T21:09:34Z
I would implement the Serializable interface instead. It would be more consistent with what Symfony does elsewhere, and would avoid breaking things when you extend the class (Silex does it). Private properties cannot be accessed from the child class, and this is what PHP tries to do when you use ``__sleep`` as you only return the property name.
---------------------------------------------------------------------------
by Tobion at 2012-07-04T22:52:00Z
I also saw this circular reference. Maybe it's time to remove the reference from compiled route to the original route?!
If a developer needs the original route, he should keep the reference himself. No need to do it for him. It's like offering a "decompiling" reference that shouldnt be there.
---------------------------------------------------------------------------
by Crell at 2012-07-05T00:08:51Z
With Serializable, I'd have to reimplement serialize() myself, wouldn't I? I just want to exclude the one value, but otherwise serialize normally. Seems like that would be a non-small amount of work compared to a one-liner.
---------------------------------------------------------------------------
by stof at 2012-07-05T00:09:44Z
@Crell you have to reimplement it in the child class only if you want to add more stuff in the serialized data.
and breaking Silex just to be lazy here is not a good idea
---------------------------------------------------------------------------
by Crell at 2012-07-05T00:24:52Z
I'm not trying to break Silex. :-P
I think this is what you mean, but I'm not sure that completely changing the serialized form (which this does) is wise. Is that not also a BC break of sorts?
Once we settle on one we can cherry-pick out the commits we want.
---------------------------------------------------------------------------
by stof at 2012-07-05T01:00:29Z
changing the serialization format is not an issue: the only place where serialized routes are likely to be stored is in the cache, and the cache does not need to be BC between 2.0 and 2.1. The user already have to delete it due to other changes.
---------------------------------------------------------------------------
by fabpot at 2012-07-09T15:02:59Z
+1 for implementing `Serializable`. Can you squash your commits and fix the CS (we need 4 spaces)? Thanks.
---------------------------------------------------------------------------
by Crell at 2012-07-10T03:25:04Z
Squshed, Spaced, and Rebased.