Commits
-------
9546ee6 Removed the IndexedReader
ea2cf73 Refactored the validator initializer
c6063ec [DoctrineBundle] Updated the code to use the new registry
a1784c2 [DoctrineBridge] Updated the code to use the new registry
Discussion
----------
Doctrine registry
This updates the Doctrine bridge and DoctrineBundle to use the new ManagerRegistry interface and its methods instead of using the old methods which are marked as deprecated.
The ORM now supports using a standard reader and does the needed logic
internally.
The IndexedReader is also available in Common for people needing it.
Commits
-------
41ab1f7 updated RegistryInterface for https://github.com/doctrine/common/pull/68
Discussion
----------
[Doctrine] updated RegistryInterface
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
We tweaked the ManagerRegistry interface in https://github.com/doctrine/common/pull/68
So this PR just fixes the RegistryInterface as the PR was merged
Commits
-------
dc5772d use ORM master
4364463 use doctrine-common master
55b572d fixed getting the alias for a namespace
2b89e15 use getObjectNamespace() in getEntityNamespace()
0217a0e updated base class name
e8f3c21 updated vendors to point to lsmith77's fork of doctrine-common until its merged
6e87d01 fix tests
13c2f33 added a default implementation of the ManagerRegistry integrating the container
Discussion
----------
[Doctrine] added a default implementation of the ManagerRegistry
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes (minor change in the interface see below)
Symfony2 tests pass: yes
Fixes the following tickets: -
added a default implementation of the ManagerRegistry integrating the container
attempted to maintain BC as good as possible, but RegistryInterface::getRepository() had to be dropped from RegistryInterface. Its still part of the ManagerRegistry, so its only a BC break for people using RegistryInterface to create their own implementation as I ran into https://bugs.php.net/bug.php?id=43200
all implementation (ORM/ODM) will need to match the changes to the ClassMetadataFactory interface
ORM, PHPCR, CouchDB have been upgraded already.
The Bundles also need to be updated. ORM is covered with this PR, I have a PR ready for PHPCR:
https://github.com/symfony-cmf/symfony-cmf/pull/108
also note that before merging the change to vendors.php needs to be fixed to point to the right repo again
For MongoDB it currently does not yet have a registry and I can take care of CouchDB once this is all merged.
---------------------------------------------------------------------------
by lsmith77 at 2011/09/23 00:40:07 -0700
still a few failing tests and details still need to be discussed ..
---------------------------------------------------------------------------
by lsmith77 at 2011/09/23 00:53:23 -0700
ok .. tests are passing now
---------------------------------------------------------------------------
by lsmith77 at 2011/10/11 10:27:52 -0700
ok Doctrine/ORM updates are done .. PR updated .. ready to be merged.
Without this, the exception is eventually thrown in EntityChoiceList::getIdentifierValues() with a very a message that doesn't really suit the real error: "Entities passed to the choice field must be managed"
Commits
-------
3f8e8c9 fixes a session max lifetime handling
3abb7f3 fixed some conflicts with garbage collection
a1888b2 added a dbal session storage
Discussion
----------
Dbal session storage
Adds a session storage based on Doctrine DBAL.
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 13:39:28 -0700
guess it would be nice to then provide a service inside the DoctrineBundle that reuses a global DoctrineDBAL connection, guess the connection to use would then need to be configured via the doctrine app config.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 13:42:34 -0700
I haven't found a sane way to provide automatic configuration that's why I left this to the user to implement. It's also relatively easy:
```yml
services:
dbal_session_storage:
class: Symfony\Bridge\Doctrine\HttpFoundation\DbalSessionStorage
arguments: [@database_connection]
framework:
session: { storage_id: dbal_session_storage }
---------------------------------------------------------------------------
by stof at 2011/09/14 13:57:48 -0700
@lsmith77 There is an issue about reusing another DBAL connection: if the transaction is aborted by the ORM, the session could be aborted too as you cannot have 2 independent transactions AFAIK
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 13:59:57 -0700
not sure how this is relevant. i mean why does the transaction need to be left open? just begin, write, commit ..
---------------------------------------------------------------------------
by stof at 2011/09/14 14:02:39 -0700
and what if the transaction of the ORM is still opened (let's say you use SimpleThingsTransactionalBundle) ?
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 14:06:12 -0700
well thats a bit of an edge case imho. also i wonder if SimpleThingsTransactionalBundle shouldn't make sure that its transaction is closed before the session is written.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 14:06:56 -0700
It closes them.
On Wed, Sep 14, 2011 at 11:06 PM, Lukas Kahwe Smith <
reply@reply.github.com>wrote:
> well thats a bit of an edge case imho. also i wonder if
> SimpleThingsTransactionalBundle shouldn't make sure that its transaction is
> closed before the session is written.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/2182#issuecomment-2098100
>
---------------------------------------------------------------------------
by stof at 2011/09/14 14:15:02 -0700
@schmittjoh Does it close them **before** writing the session ?
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 14:44:15 -0700
I think either commit, or rollback is called, but @beberlei can probably answer that better.
Anyway, it is not really related to this PR because it is up to the user which connection is used.
---------------------------------------------------------------------------
by stof at 2011/09/14 14:58:48 -0700
I know that one of them is called. But if they are called after the session is persisted to the DB, a rollback is an issue as it will rollback the session persistence as well.
The PR is indeed fine. What need to be changed is the doc about how to use it, to advocate using a separate connection instead of the default one (which is used in your example)
---------------------------------------------------------------------------
by schmittjoh at 2011/09/15 02:57:34 -0700
There is no doc yet, but lets see what @fabpot thinks of all of this first.
---------------------------------------------------------------------------
by fabpot at 2011/09/15 04:57:57 -0700
Any benefits over using the PDO session storage?
---------------------------------------------------------------------------
by lsmith77 at 2011/09/15 05:00:50 -0700
cleaner code, potentially better support for niche RDBMS, centralized logging and finally afaik DoctrineDBAL has emulation for nested transactions.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/15 05:11:00 -0700
The benefits (for me) are:
- logging queries
- better interoperability with existing build processes (migrations)
- better database interoperability
- re-using existing connection (I don't have the problem that Stof mentioned above)
---------------------------------------------------------------------------
by beberlei at 2011/09/15 06:18:22 -0700
The nested transactions is the problem here as @stof already said. If you reuse the default connection and use nested transactions that fail then this will make your session not save. That is why the docs should recommend you create a second connection for a dbal based session storage, even if it is using the same database. The PDO session storage would be a second connection besides DBAL aswell.
I like the migrations/schema hook though to create the table automatically through schema commands.
---------------------------------------------------------------------------
by fabpot at 2011/09/15 10:45:31 -0700
ok, looks good to me. Can you add some documentation about its usage (like the possible keys for options)? Is it possible to add some tests too?
---------------------------------------------------------------------------
by jdreesen at 2011/09/22 06:34:11 -0700
why did you close this?
---------------------------------------------------------------------------
by schmittjoh at 2011/09/30 06:26:12 -0700
I can't put more time into this PR, however I'm using it for some time already, and there shouldn't be any major issues as it is basically copy/paste from the PDO session.
Commits
-------
731b28b [composer] add missing deps for FrameworkBundle
9c8f100 [composer] change ext/intl to the new ext-intl syntax
d535afe [composer] fix monolog-bridge composer.json, add more inter-component deps
9ade639 [composer] add composer.json
Discussion
----------
Composer
This PR adds a composer.json file for [composer](https://github.com/composer/composer) ([more info](packagist.org/about-composer)).
For discussion you can also go into #composer-dev on freenode and argue with naderman, seldaek and everzet.
---------------------------------------------------------------------------
by naderman at 2011/09/26 15:51:51 -0700
You haven't entered any keywords, they might come in handy when searching for packages on packagist.
But really this is just a +1 ;-)
---------------------------------------------------------------------------
by stof at 2011/09/26 16:12:21 -0700
See my comments on your previous (non-rebased) commit: f1c0242b5a
---------------------------------------------------------------------------
by igorw at 2011/09/27 00:04:36 -0700
Following dependencies do not have a composer.json yet: Twig, Doctrine (orm, dbal, common), swiftmailer.
Also missing from the standard edition: assetic, twig-extensions, jsm-metadata, SensioFrameworkExtraBundle, JMSSecurityExtraBundle, SensioDistributionBundle, SensioGeneratorBundle, AsseticBundle.
The point is, those can be added later on. Having the components composerized is already a leap forward. Also, doctrine depends on some symfony components, we've got to start somewhere.
---------------------------------------------------------------------------
by Seldaek at 2011/09/27 00:36:41 -0700
Also, just for information, the plan is to have `symfony/framework-bundle` be the "framework", with all dependencies to doctrine etc, though we should really only have strict requirements in there, and then in symfony-standard we ship a composer.json that requires the framework-bundle, doctrine-orm and things like that that are not essential to core. Otherwise people don't have a choice about what they use anymore.
Just a comment btw, the json is invalid, all / should be escaped. However json_decode is nice enough to parse those without complaining, browsers do too, even Crockford's json2.js does, so I'm not sure if we should privilege readability over strictness, since it seems nobody really cares about this escaping.
---------------------------------------------------------------------------
by igorw at 2011/09/27 00:41:39 -0700
So, I've implemented all of @stof's suggestions, except (for reasons stated above):
* doctrine to DoctrineBundle
* swiftmailer to SwiftmailerBundle
* twig to TwigBundle
* doctrine-common to Validator
* FrameworkBundle (what exactly does it depend on?)
---------------------------------------------------------------------------
by stof at 2011/09/27 00:52:31 -0700
@igorw at least HttpKernel, Routing, Templating, EventDispatcher, Doctrine Common (annotations cannot be disabled), Translator, Form (optional), Validator (optional), Console (optional). See the service definitions to see the others
@Seldaek FrameworkBundle does not depend on Doctrine, except for Common
---------------------------------------------------------------------------
by beberlei at 2011/09/27 03:15:34 -0700
What does the symfony/ or ext/ prefix control in composer?
---------------------------------------------------------------------------
by Seldaek at 2011/09/27 03:33:52 -0700
symfony/ is just the (mandatory) vendor namespace. Also ext/ has been renamed to ext- now, so it's not in any vendor, and should avoid potential issues.
---------------------------------------------------------------------------
by beberlei at 2011/09/27 05:07:03 -0700
@Seldaek Mandatory? So every package name is "vendor/package"? I like that because previously i thought package names are not namespaced, and thus clashes could occur between different communities easily.
---------------------------------------------------------------------------
by Seldaek at 2011/09/27 05:16:20 -0700
@beberlei: Mandatory. As of yesterday http://packagist.org/ will tell you you have an invalid package name if there's no slash in it. See 1306d1ca82 (diff-3)
* 2.0:
[Validator] added support for grapheme_strlen when mbstring is not installed but intl is installed
removed separator of choice widget when the separator is null
attempted to maintain BC as good as possible, but RegistryInterface::getRepository() had to be dropped from RegistryInterface. Its still part of the ManagerRegistry, so its only a BC break for people using RegistryInterface to create their own implementation
Commits
-------
a0a97c6 Removed executable bits from all php files
Discussion
----------
Removed executable bits from all PHP files
Some files had a file mode of 755 and this PR changes them to 644. The reason behind this is that git always thinks that those files are changed when accessing the repository via a samba share on windows (tested with PhpStorm).
---------------------------------------------------------------------------
by fabpot at 2011/09/09 05:51:30 -0700
That was on my radar too. Can you do the same for the 2.0 branch?
-- add missing files
-- tweak translation command files
-- dumpers are now responsive for writting the files
-- moved the twig extractor the bridge
-- clear temp files after unit tests
-- check the presence of dumper in translation writer
-- General cleaning of the code
-- clean phpDoc
-- fix PHPDoc
-- fixing class name in configuration
-- add unit tests for extractors (php and twig)
-- moved test to correct location
-- polish the code
-- polish the code
Commits
-------
d19f1d7 [Doctrine] Fix UniqueEntityValidator reporting a false positive by ignoring multiple query results
Discussion
----------
[Doctrine] Fix UniqueEntityValidator reporting a false positive by ignoring multiple query results
An entity should only be considered unique if its search criteria returns no matches or a single, identical entity. Multiple results indicates that conflicting entities exist.
Note: the DoctrineMongoDBBundle's unique validator checks identifier values if the object strict-equality check is false. This may be a worthwhile improvement, as it would prevent reporting a validation error for an enttiy which is going to overwrite its conflicting counter-part in the database.
---------------------------------------------------------------------------
by jmikola at 2011/09/01 14:23:27 -0700
This is the Doctrine bridge equivalent for my fix to DoctrineMongoDBBundle: https://github.com/symfony/DoctrineMongoDBBundle/pull/42
---------------------------------------------------------------------------
by fabpot at 2011/09/02 00:13:52 -0700
As this is a bug fix, can you base your PR on the symfony/2.0 branch? Thanks.
An entity should only be considered unique if its search criteria returns no matches or a single, identical entity. Multiple results indicates that conflicting entities exist.
Commits
-------
6bd1749 Fixed a bug when multiple expanded choices would render unchecked because of the Form Framework's strict type checking.
Discussion
----------
[DoctrineBridge] Entities to array transformer
Fixed a bug when multiple expanded choices would render unchecked because of the Form Framework's strict type checking.
---------------------------------------------------------------------------
by fabpot at 2011/08/31 09:01:47 -0700
Looks good to me. Can you squash your commits before I merge? Thanks.
Commits
-------
c558b78 avoid rendering the `ChoiceType` separator if all `choices` are `preferred_choices`
Discussion
----------
avoid rendering the `ChoiceType` separator if all `choices` are `preferred_choices`
---------------------------------------------------------------------------
by fabpot at 2011/07/24 00:51:21 -0700
The same change should be made to the PHP template.
---------------------------------------------------------------------------
by fabpot at 2011/07/25 00:31:39 -0700
I forgot to ask you to add some unit tests too. Thanks.
---------------------------------------------------------------------------
by craue at 2011/07/25 10:23:34 -0700
Are you asking for PHPUnit tests? If so, unfortunately, I'm not able to add those because I haven't used PHPUnit yet. ;)
---------------------------------------------------------------------------
by lenar at 2011/07/25 12:47:51 -0700
I would prefer ```choises | length``` without spaces as everywhere else.
---------------------------------------------------------------------------
by lenar at 2011/07/25 12:50:32 -0700
@fabpot: Since <option disabled> is unclickable in browser (by HTML spec) this really doesn't change anything (something not there is as unclickable) except the the look when rendered. I have hard time to imagine what could become unit-testable here by this change.
---------------------------------------------------------------------------
by stof at 2011/07/25 13:03:47 -0700
@lenar unit testing is not about what the browser could do. What should be unit-tested is that an example will only preferred choices does not output the separator, which is exactly what this PR is about
---------------------------------------------------------------------------
by stof at 2011/07/25 13:04:03 -0700
@lenar unit testing is not about what the browser could do. What should be unit-tested is that an example will only preferred choices does not output the separator, which is exactly what this PR is about
---------------------------------------------------------------------------
by lenar at 2011/07/25 13:08:33 -0700
@stof: ok, put this way you are definitely right.
---------------------------------------------------------------------------
by craue at 2011/07/25 13:37:50 -0700
@lenar: You're right about the spaces. I'm using them in my projects but will remove them here for the sake of consistency.
---------------------------------------------------------------------------
by stloyd at 2011/07/25 13:40:40 -0700
@craue I will write today/tomorrow test to cover your code and send you PR.
---------------------------------------------------------------------------
by craue at 2011/07/25 14:00:26 -0700
@stloyd: That would be nice. But I'm still not that familiar with Git(Hub). Is there anything I have to take care of?
Also, I'd like to squash my three commits into one ... if this is possible for an open PR and if I find out how to do that easily. :D
---------------------------------------------------------------------------
by fabpot at 2011/07/26 00:18:22 -0700
@craue: yes, you should squash your commits into one and use `--force` when you push (the PR will automatically be updated accordingly).
Commits
-------
85c0087 [TwigBridge] Made the locale configurable for the trans and transchoice tags
3ea31a0 [TwigBridge] Made the locale configurable for the trans and transchoice filters
Discussion
----------
Trans locale
This allows setting the locale when translating in a Twig template. This was already allowed in the Translator and in the PHP templates
Commits
-------
52fdd53 [Bridge/Twig] Add required class to labels that match required fields
Discussion
----------
[Bridge/Twig] Add required class to labels that match required fields
I have used this to simply style labels that are required with a red star behind them using this CSS:
``` css
label.required::after {
content: " *";
color: #c00;
}
```
The problem is that you can't use `input[required] + label::after` as a selector since the label is typically rendered before the input. There is no way to check for an element that is *followed by* another, only elements *following*.
Of course this CSS in particular won't work except in the latest browsers, but you could still use the `label.required` selector to add a background image and so on. I think this is a very common use case and therefore I think it'd benefit the core framework.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:27:49 -0700
Can you also update the PHP templates?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 01:43:33 -0700
How about namespacing these css classes, like for example "sf-form-required"?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 01:50:58 -0700
I would prefer an @schmittjoh naming, or even adding ability to setup it thought options.
---------------------------------------------------------------------------
by fabpot at 2011/07/05 01:54:36 -0700
Please, do not add more options. Prefix with `sf` is actually a good idea but people will argue that this is not a good idea because it gives too much information about the technology used to create the website (that's one of the things that came up pretty often in symfony1).
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:00:11 -0700
An option is not such a good idea imo since you likely want to have a uniform naming strategy across your entire site. How about adding a new service CssNamingStrategy?
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:01:19 -0700
Then this can be some simpler one not giving such informations i.e.: `form-label-required`, `label-required`, `framework-form-required`, `form-required` or whatever else ;-)
---------------------------------------------------------------------------
by fabpot at 2011/07/05 02:16:41 -0700
It cannot be configurable as it would potentially break bundles that come with stylesheets.
---------------------------------------------------------------------------
by stloyd at 2011/07/05 02:21:10 -0700
IMO if we decide to add this one, we could add same to `inputs/selects/etc` with `required` option.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:21:59 -0700
I think it can, consider an interface like this:
```php
interface CssNamingStrategyInterface
{
function getCssName($class);
}
```
This will give people a lot of flexibility, and it also does allow them to exclude classes which for example are provided by third-party bundles.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 02:47:54 -0700
Wow guys, if this turns into a full blown class generator solution, I'm happy to close the PR.
"required" is not a name that's commonly used for main page elements, it's typically associated with forms, and therefore I don't see the need to make it unnecessary longer/namespaced. Similarly I don't see the need to add it to the input/select/.., because they already have an attribute, which you can very easily select as: `input[required]` in CSS. That works everywhere except IE6, but we can't build for the future on very old browsers. If you really want support for IE6, you can override the templates imo. But core should be looking forward, as it already is with HTML5, form markup, etc.
As for calling it form-label-required or label-required, again, I don't see the benefit, you can use `label.required` if you want to avoid conflicts with non-label elements having a required class, or a safer `form .required`. There are plenty of options in CSS itself, let's not make this overly complex.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 02:52:17 -0700
see
http://code.google.com/intl/de-DE/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors
On Tue, Jul 5, 2011 at 11:47 AM, Seldaek <
reply@reply.github.com>wrote:
> Wow guys, if this turns into a full blown class generator solution, I'm
> happy to close the PR.
>
> "required" is not a name that's commonly used for main page elements, it's
> typically associated with forms, and therefore I don't see the need to make
> it unnecessary longer/namespaced. Similarly I don't see the need to add it
> to the input/select/.., because they already have an attribute, which you
> can very easily select as: `input[required]` in CSS. That works everywhere
> except IE6, but we can't build for the future on very old browsers. If you
> really want support for IE6, you can override the templates imo. But core
> should be looking forward, as it already is with HTML5, form markup, etc.
>
> As for calling it form-label-required or label-required, again, I don't see
> the benefit, you can use `label.required` if you want to avoid conflicts
> with non-label elements having a required class, or a safer `form
> .required`. There are plenty of options in CSS itself, let's not make this
> overly complex.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1519#issuecomment-1502560
>
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 03:11:50 -0700
Really? Come on, we're talking about forms, it's not like you have billions of form/input tags per page that have to be parsed by the browser when you select that. Also you don't have to select the elements, if you want true performance just use no stylesheet, your users will thank you.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 03:30:40 -0700
Your CSS selectors not only affect the performance of form elements, but of all elements that have a "required" class. Likewise, the same applies if we decide to add more classes.
Why close the door for people who care about performance? We can easily avoid this by making the css class more specific as suggested earlier. The idea with the renaming strategy is one step further and allows people to "obfuscate" which tool was used to generate the form, or do additional optimizations like shortening the css name.
---------------------------------------------------------------------------
by lenar at 2011/07/05 03:34:34 -0700
@Seldaek: Just for remark I've seen matrix forms spanning multiple screenfuls horizontally and vertically
containing tens of thousands inputs. Not pretty, but they do exist. Basically "poor" man's/company's excel
emulation or something.
---------------------------------------------------------------------------
by Seldaek at 2011/07/05 04:19:13 -0700
@schmittjoh, @lenar: We're catering to the most common use case, for which this will be more than fast enough. Small/medium scale websites don't have to optimize on CSS rules parsing, they usually have much bigger issues to deal with. If you really care about it, overriding the block to remove the class is just as easy as it was to for me to add it, but IMO this is the edge case.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/05 05:37:19 -0700
IMO Symfony should follow best practices by encouraging to use class selectors, and not tag selectors for the reasons explained on the page I linked.
Anyway, I think everybody made his points. Time for @fabpot to make a decision :)
Commits
-------
1cc1027 added @Annotation to UniqueEntity
ee22c5d added a note to update file
efcb435 updated to doctrine changes
Discussion
----------
updated to doctrine changes
---------------------------------------------------------------------------
by excelwebzone at 2011/06/30 06:29:23 -0700
Should also be implemented to the Route class and to all SensioFrameworkExtraBundle annotation classes
Commits
-------
4e3406d Sync with master and clean up
ad5d2c1 Added to `TimeType` extension possibility to render form as `single_text` (similar to DateType option) (issue #1205) Adjusted `DateTimeType` to allow usage of this new feature
Discussion
----------
[Form][TimeType] Added possibility to render form as "single_text"
Added to `TimeType` extension possibility to render form as `single_text` (similar to `DateType` option) (issue #1205)
Adjusted `DateTimeType` to allow usage of this new feature
---------------------------------------------------------------------------
by ouardisoft at 2011/06/17 03:41:18 -0700
+1
---------------------------------------------------------------------------
by stloyd at 2011/06/21 01:05:51 -0700
@fabpot Any decision about this one ? I'm asking because I also have similar fix for #1323 but it requires this one ;-)
---------------------------------------------------------------------------
by fabpot at 2011/06/22 23:32:08 -0700
@stloyd: Can you rebase to master?
---------------------------------------------------------------------------
by stloyd at 2011/06/23 05:03:44 -0700
@fabpot Done.
Commits
-------
2c1108c [Form] Revert the ability to override anything else than the text of the label while rendering a row
da467a6 [Form] Fix the exception message when no block is found while rendering
8670995 [Form] Optimize rendering when the block to render is known
41e07c9 [Form] Optimize rendering
ee5d975 [Form] Remove a test which is no more relevant (after recent FileType refactoring)
f729c6b [Form] Add the ability to override label & widget options when rendering a row
e09ae3f [Form][FrameworkBundle] Make FormHelper::renderSection() recursively callable, introduce FormHelper::renderBlock()
e43fb98 [Form][TwigBridge] Make FormExtension::render() recursively callable to ease theming
Discussion
----------
[Form] Some refactoring of the rendering
# First two commits
## FormExtension::render() can now be called recursively.
The main use case is theming support in for collections. Let's consider that you have a collection of `CustomType`, the type hierarchy while rendering the proto would be `field < form < custom < prototype`. Before this change any theme applied to your custom type (i.e. a `custom_row` block) would not have been taken into account while rendering the prototype because of the structure of the `prototype_row` block:
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ block('field_row') }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
which skip the `custom_row` block rendering to fallback to the `field_row` block rendering.
With this PR `prototype_row` recursively calls `FormExtension::render()`
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ form_row(form) }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
this has for effect to render the block for the parent type (i.e. `custom_row`)
## FormHelper
The `FormHelper` has been updated to more closely match the `FormExtension` architecture and the templates have been modified accordingly. `echo $view['form']->renderBlock(<block name>)` is the php equivalent of `{{ block(<block name>) }}`.
The attributes are now rendered using a template rather than by the `FormHelper::attributes()` method.
Several templates have been fixed.
# Third commit
The `$varStack` property was used to forward options to the label and the widget when rendering a row. The implementation was not working as expected. The proposed way to override label and widget options is to pass these options in the `label` and `widget` keys while callinf `render_row`.
That would be:
`{{ form_row(form.field, {"attr": {<row attributes>}, "label" : {"label": <text>, "attr": {<label attr>}}, "widget" : { "attr" : {<widget attributes}} } }}`
So there is now the ability to set attributes for the row (`<div>` or `<tr>`).
This has been discussed on [the mailing list](http://groups.google.com/group/symfony-devs/browse_thread/thread/17754128ba480545). **I would like to find a compromise with @Seldaek before this gets merged**
The `$varStack` property is now only used when recursively calling `FormExtension::render()`
# Notes
I have preferred to submit several commits in order to ease review and to keep some history.
---------------------------------------------------------------------------
by stof at 2011/06/20 05:20:56 -0700
@vicb On a side note, do you think it would be possible to support form theming in PHP templates too ? Currently, the only way to customize the rendering of forms when using PHP templates is to overwrite the FrameworkBundle's templates, and this impacts all forms. This makes the PHP rendering far less powerful than the Twig one.
I don't know the Form rendering and the PHPEngine well enough to know if it is feasible for 2.1 or not.
---------------------------------------------------------------------------
by vicb at 2011/06/20 05:35:11 -0700
@stof I hope to make it possible but I need a little bit more thinking to find the best possible solution which should not look like a hack.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:13:10 -0700
This should not be merged yet, it might have some issue with the variable stack. I am working on it.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:41:11 -0700
Sorted out the issue, it was linked to some local _optimization_, the code of this PR is ok.
---------------------------------------------------------------------------
by vicb at 2011/06/21 02:01:24 -0700
I have pushed a [POC of php theming based on this PR](https://github.com/vicb/symfony/commits/form%2Fphp-theme) to my repo - it is lacking a configuration and cache layer.
I have open [a thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511) to discuss this.
---------------------------------------------------------------------------
by vicb at 2011/06/21 23:40:21 -0700
@fabpot fixed in the last commit.
