[WIP][Form] Add theming support for collections #4733
Conversation
|
hum... this would not work for nested collections, need some more work |
|
I don't think the FormType should be cluttered with logic to theme collections. It's an evaluation that would have to be tested for every form field rendered, even though it would evaluate to true only rarely. What's your motivation for writing a new PR over #2806? |
Kind of agree but changing With this PR you can (or you will be able to) theme any form under the collection: It needs some more work so let's keep on discussing this tomorrow. |
|
I have push a new implementation in some other branch. In works in the same way as the current theming works:
It also works with nested collections and prototypes. Internals:
If we can agree on this, I'll finish the PR based on this code. |
|
@vicb does your alternate implementation supports theming a particular child of a collection ? |
|
@stof the current code does not but this is a topic I would like to discuss before finalizing the code - implementing it would be very easy the question is to know if this is useful, only the extension (/helper) code would need to be modified. If you ask the question, you should have a use case, right ? |
|
@vicb I don't have a use case. It was simply to be sure as you talked about this possibility in the todo-list of the current PR. |
|
This measure actually brings a huge performance boost, since now the templating engine doesn't have to check for every block in a row if it has been overridden for that specific row. For this specific form, this measure decreases rendering time from 7.7 to 2.5 seconds on my machine. The conclusion is that overriding blocks per row certainly won't be supported. |
|
@vicb Do you have time to continue this work ? |
|
@stof I implemented it now, although slightly differently. |
Commits ------- 69e5e58 [Form] Individual rows of CollectionType cannot be styled anymore for performance reasons Discussion ---------- [Form] Individual rows of CollectionType cannot be styled anymore Bug fix: no Feature addition: no Backwards compatibility break: **yes** Symfony2 tests pass: yes Fixes the following tickets: #2806, #4733 Todo: - Individual theming of blocks in a row of a collection form is now unsupported: ``` {% block _author_tags_0_label %} {# ... #} {% endblock %} {% block _author_tags_1_label %} {# ... #} {% endblock %} ``` Instead, it is now possible to define a generic template for all rows, where the word "entry" replaces the previous occurence of the row index: ``` {% block _author_tags_entry_label %} {# ... #} {% endblock %} ``` The main motivation for this change is performance. Looking up whether individual styles exist for each single block within each row costs a lot of time. Because the row index is included in the block names, caching is virtually impossible. For [this specific, heavy form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1), this PR decreases rendering time from **7.7** to **2.5 seconds** on my machine. --------------------------------------------------------------------------- by fabpot at 2012-07-14T10:55:29Z @bschussek Can you also create a PR on symfony docs to update the documentation?
This is a work in progress
This is an attempt to allow form collection theming.
Before this PR, it was not possible to apply a theme to all the children of a collection, you would have needed to cretate one block per child:
You can now create a single theme that will be applied to all the children:
@Burgov, @bschussek, everybody, any feedback ?
Todo:
fix: #2806