Commits
-------
257f86c [Form] Collection's prototype is not not a child anymore.
2b4cc9b [Form] Changed collection prototype rendering.
Discussion
----------
[Form] Changed collection prototype rendering
Based on PR #1500. It is now rendered inside an attribute of collection
tag.
The data-attribute can be retrieved using this piece of jQuery code. You aways will need to adapt it. I think this will be also doable with plain JS.
```javascript
<script type="text/javascript">
jQuery('p.add-child').click(function() {
var prototype = $('form #id').attr('data-prototype');
prototype = prototype.replace(/\$\$name\$\$/g, 'levelxx');
$('#id').append(prototype);
});
</script>
```
Closes#1497
---------------------------------------------------------------------------
by beberlei at 2011/07/18 06:40:40 -0700
form div[data-prototype]? What about forms with two collections?
---------------------------------------------------------------------------
by marcw at 2011/07/18 07:25:51 -0700
My bad, the javascript snippet is not crystal clear. Actually, you'll have to specify the div's id to retrieve the right `data-prototype` attribute.
The good way of doing this is by specifying the div's id in the selector (like in the 2nd part of the js example), like this :
var prototype = $('form #level1_level2_level3_level3').attr('data-prototype');
---------------------------------------------------------------------------
by tystr at 2011/07/18 12:32:39 -0700
+1
---------------------------------------------------------------------------
by marcw at 2011/07/22 01:46:08 -0700
thanx @vicb ! :)
Commits
-------
2e024f8 [Form] CollectionType now checks for data_class parameter instead of only class.
0327beb [Form] Added ObjectFactoryListener. Fixes#1746.
Discussion
----------
[Form] Added ObjectFactoryListener. Fixes#1746.
---------------------------------------------------------------------------
by marcw at 2011/07/21 09:32:17 -0700
This patch also fixes a validation issue because it was impossible for the validator to validate an array.
---------------------------------------------------------------------------
by stof at 2011/07/21 09:47:46 -0700
yeah, using the data_class of the prototype would be great
This commit also fixes exception pages when Twig is not enabled as a templating engine.
Instead of just displaying the raw Twig template as before, we now fallback to the default
exception handler introduced some time ago.
Commits
-------
79e4ed6 simplified assignment
04302ff simplified ternary-operator
3a285c1 fixed handling of null-values in attribute- and query-arrays
Discussion
----------
[FrameworkBundle] fixed handling of null-values in attribute- and query-arrays
when esi is enabled and internal uris are generated for esi-tags, an
attribute-array consisting entirely of null-values isn't handled correctly.
The reason is that php's `http_build_query()`-method outputs an empty string
for such arrays:
http_build_query(array('foo' => '')) == 'foo='
http_build_query(array('foo' => null)) == ''
In the latter case, the generation of an URI in [`HttpKernel::generateInternalUri()`][code1]
generates an URI that could not be matched by the corresponding route (ex.
`_internal/Controller/.html` opposed to `_internal/Controller/none.html` which
should be expected).
This commit adds a possible solution as well as a simple test for this issue.
[code1]: https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/HttpKernel.php#L179
when esi is enabled and internal uris are generated for esi-tags, an
attribute-array consisting entirely of null-values isn't handled correctly.
The reason is that php's `http_build_query()`-method outputs an empty string
for such arrays:
http_build_query(array('foo' => '')) == 'foo='
http_build_query(array('foo' => null)) == ''
In the latter case, the generation of an URI in `HttpKernel::generateInternalUri()`
generates an URI that could not be matched by the corresponding route (ex.
`_internal/Controller/.html` opposed to `_internal/Controller/none.html` which
should be expected).
This commit adds a possible solution as well as a simple test for this issue.
Commits
-------
9bcce9f fix tests
fc4787a fix non-extensible router
Discussion
----------
Router fix
Right now, the router is hard to overwrite (you need always a compiler pass). This commit fixes this.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 01:15:36 -0700
Why do you need a complier pass to override the router?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 01:47:47 -0700
How would you suggest to overwrite it?
Basically, I want to do something like this:
```yml
services:
router:
parent: router.default
class: MyClass
calls:
- [moreDeps, []]
```
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 05:07:19 -0700
Then maybe we should somehow support redefining services with the same name while keeping the old one as parent, otherwise we need this foo.default for every service out there?
---------------------------------------------------------------------------
by fabpot at 2011/07/18 06:30:34 -0700
as @Seldeak said, why do that for the router and not all services?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 06:38:39 -0700
I have designed the SecurityBundle this way where extension is encouraged.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 11:15:57 -0700
I should add that this is mainly a problem for services where you still want to use the semantic configuration that is provided by the bundle. For services which are not configured by the extension, this is not so much of an issue.
Anyway, if you don't want to merge it, just close the PR. I have no problem with using a compiler pass.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 11:55:11 -0700
We already have such a case with translator and translator.real. I will review the existing services to see where it makes sense to implement the same strategy.
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 12:20:55 -0700
I guess you'd do it anyway, but we should pick a winner between .real and .default
---------------------------------------------------------------------------
by lsmith77 at 2011/07/18 12:26:52 -0700
I would prefer ".default" as ".real" always confused me.
