I was sure I understand this process, but when I dug deeper I saw I am wrong ;(
Let's take simple form, please notice that this form contains 3 fields
$form = $this->createFormBuilder($defaultData, ['csrf_protection' => false])
->add('email', 'email')
->add('name', 'text')
->add('message', 'textarea')
->getForm()
->createView();
which is rendered as
{{ form(form, {'attr': {'novalidate': 'novalidate'}}) }}
into
Built in "form" block from vendor\symfony\symfony\src\Symfony\Bridge\Twig\Resources\views\Form\form_div_layout.html.twig looks like:
{% block form %}
{% spaceless %}
{{ form_start(form) }}
{{ form_widget(form) }}
{{ form_end(form) }}
{% endspaceless %}
{% endblock form %}
and form_widget(form)
{% block form_widget %}
{% spaceless %}
{% if compound %}
{{ block('form_widget_compound') }}
{% else %}
{{ block('form_widget_simple') }}
{% endif %}
{% endspaceless %}
{% endblock form_widget %}
{% block form_widget_simple %}
{% spaceless %}
{% set type = type|default('text') %}
<input type="{{ type }}" {{ block('widget_attributes') }} {% if value is not empty %}value="{{ value }}" {% endif %}/>
{% endspaceless %}
{% endblock form_widget_simple %}
Let's modify form and form_widget a bit:
{% block form %}
{% spaceless %}
{{ form_start(form) }}
-form_widget before-
{{ form_widget(form) }}
-form_widget after-
{{ form_end(form) }}
{% endspaceless %}
{% endblock form %}
{% block form_widget %}
{% spaceless %}
- form_widget call -
{% if compound %}
- form_widget compound-
{{ block('form_widget_compound') }}
{% else %}
- form_widget simple-
{{ block('form_widget_simple') }}
{% endif %}
{% endspaceless %}
{% endblock form_widget %}
then as an output I got (listing 5):
<form name="form" method="post" action="" novalidate="novalidate">
-form_widget before-
- form_widget call -
- form_widget compound-
<div id="form" novalidate="novalidate">
<div>
<label for="form_email" class="required">Email</label>
<input type="email" id="form_email" name="form[email]" required="required" />
</div>
<div>
<label for="form_name" class="required">Name</label>
- form_widget call -
- form_widget simple-
<input type="text" id="form_name" name="form[name]" required="required" />
</div>
<div>
<label for="form_message" class="required">Message</label>
<textarea id="form_message" name="form[message]" required="required">Type your message here</textarea>
</div>
</div>
-form_widget after-
</form>
we can easly notcie the flow
form -> form_widget (input parameter is the whole form) -> form_widget_compound -> form_rows (iterates form elements into next function) -> form_row -> form_widget (this call form element is passed as parameter)
so here is the time for question, if form_widget is called 4 times (or more), once for form, 3 times for fields then why in listing 5 'form_widget call' text appears only 2 times?
or other words how email and message were rendered?
The form theming in SF2 uses inheritance. That means that if blocks named email_widget and textarea_widget are defined, neither your e-mail nor your textarea fields will use form_widget. They will rather respectively use their own widget blocks: email_widget and textarea_widget.
Well, in form_div_layout.twig, these two widget blocks are defined. Thus form_widget is not called for 2 of your fields. Thus your message is displayed 2 times instead of 4.
If you want to customize the rendering of these fields, you will have to create your own block definitions email_widget and textarea_widget in your custom form theme file.
Edit:
The default form theme files are defined under Symfony\Bridge\Twig\Resources\views\Form. The default file used is form_div_layout.html.twig.
Although the inheritance logic itself is indeed in the PHP code of the TWIG bridge, it does not define which block inherit from which other block.
Inheritance is actually defined in your FormType classes. Each form type class sports a getParent() method that return the name of the form from which it inherits. The name of a form type is the result of the method getName() of its associated form type class. For instance, with a built-in example, Symfony\Component\Form\Extension\Core\Type\TextareaType:
Textarea >> Text >> Field >> Form
All you have to do is to look for the methods getParent() and getName(). Thus, by default, when rendering the textarea row, Twig will search the block textarea_row, text_row, field_row and finally form_row (the base default row). The first of these blocks that is defined in your form theme is rendered.
The definition of the blocks themselves happen in the form theme files.
I need my symfony2/twig forms to adhere to a certain condition: All form rows must look similar to this:
{% block form_row %}
<div class="CONSTANT_CLASS class_based_on_field_type class_based_on_error">
{{ form_label(form) }}
{{ form_widget(form) }}
...
</div>
{% endblock form_row %}
Notice that I need to get the field type within the form_row block. Alas, the field type is only defined at the widget level.
I definitely need a way to let my form_row know what type of field it is dealing with.
So i suppose it would be best to somehow override the form_row twig function.
Where can the default twig functions be overridden? And how could this be done?
Remember, this is not about customizing a form. I need to know how to add to existing form variables for existing field types.
#nifr:
The key answer for you seems to be the {% set typeClass ... %}. But there is not a defined variable text anywhere for the template. Look at form_div_layout.html.twig at line 158ff, I think the type really gets set only at the form_widget level and is thus capsulated to be there. That means using the type at the form_row level will aways result in the given default (So it occurred to me while testing). If you can prove this wrong I will happily accept your answer.
How to override the form_row block in Twig adding attributes by field-type?
Though you say this is not about form customization it can be achieved with it ... Quick Introduction for others reading this now.
The default symfony twig form extensions can be found here.
The default twig form theme can be found at Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig.
General information on how to override forms can be found in the How to Customize Form Rendering chapter of the Book but i will sum this up shortly.
form_row Default
{% block form_row %}
{% spaceless %}
<div>
{{ form_label(form) }}
{{ form_errors(form) }}
{{ form_widget(form) }}
</div>
{% endspaceless %}
{% endblock form_row %}
Overriding Form Level
Add this to the form template you want to customize:
{% form_theme form _self %}
If you want to put the {% block form_row %} into another bundle/template use this:
{% form_theme form 'AcmeDemoBundle:Form:fields.html.twig' %}
Now insert your custom form_row block after the form_theme declaration or put it into the specified template (in our case this would be AcmeDemoBundle:Form:fields.html.twig).
In my example we will add the class 'error' if there is an error in the form row and a another classname nameely the type name of the current field-type.
{% block form_row %}
{% spaceless %}
{# set class to 'error' if errors exist #}
{% set attr = attr|merge({'class': attr.class|default('') ~ (errors|length > 0 ? ' error' : '') }) %}
{% set typeClass = ' ' ~ type|default('text') %}
{#
you could also implement a logic matching input types with an array of their
desired classname-representations here.
#}
{% set attr = attr|merge({'class': attr.class|default('') ~ type) }) %}
<div class="{% for class in attr.class %}{{ class }}{% endfor %}{{ typeClass }}">
{{ form_label(form) }}
{{ form_errors(form) }}
{{ form_widget(form) }}
</div>
{% endspaceless %}
{% endblock form_row %}
if you want to apply your form_row block system-wide add your AcmeDemoBundle:Form:fields.html.twig to your twig.templating.form.resources !
# app/config/config.yml
framework:
templating:
form:
resources:
- 'AcmeDemoBundle:Form'
In the form_row block you can use :
{{ form.vars.block_prefixes[2] }}
form.vars.block_prefixes gives you an array with more information and it might change with versions. But from what I have seen so far it is always index 2
I have a base Twig template that has a search bar form in it at the top of the page in a Twig block. I have another block later on named "content" that my children pages fill out. Currently, my base template looks like this:
{% block admin_bar %}
<div id="search">
<form action="{{ path('search') }}" method="post" {{ form_enctype(search_form) }}>
{{ form_widget(search_form.term) }}
{{ form_widget(search_form.type) }}
{{ form_widget(search_form.pool) }}
{{ form_widget(search_form._token) }}
<input type="submit" value="Search" />
</form>
</div>
{% endblock %}
{% block content %}
{% endblock %}
However, when trying to render a child template I need to pass in the search_form variable along with it. Is there anyway (short of writing out the HTML tags myself) I can avoid having to create this search_form variable and pass it in everytime I want to render a child view? I'm using Twig in conjunction with Symfony2.
Thanks!
Embedded Controller is what you need. Put your admin_bar block into separate file:
{# src/Acme/AcmeBundle/Resources/views/Search/index.html.twig #}
<div id="search">
<form action="{{ path('search') }}" method="post" {{ form_enctype(search_form) }}>
{{ form_widget(search_form.term) }}
{{ form_widget(search_form.type) }}
{{ form_widget(search_form.pool) }}
{{ form_widget(search_form._token) }}
<input type="submit" value="Search" />
</form>
</div>
Create controller for this template:
class SearchController extends Controller
{
public function indexAction()
{
// build the search_form
return $this->render('AcmeAcmeBundle:Search:index.html.twig', array('search_form' => $searchForm));
}
}
And then embed controller into your original template:
{% block admin_bar %}
{% render "AcmeAcmeBundle:search:index" %}
{% endblock %}
{% block content %}
{% endblock %}
I've got a collection of hidden fields in my form.
<ul id="user_roles">
<li><hidden field value="role1"></li>
<li><hidden field value="role2"></li>
(...)
</ul>
I use jQuery (and data-prototype) to add new roles.
The problem is that I would like to render something like this:
<ul id="user_roles">
<li>role1 <hidden field value="role1"></li>
<li>role2 <hidden field value="role2"></li>
(...)
</ul>
No problem with the initial rendering: i just put:
{% for role in roles %}
<li> {{ role }} {{ form_row(role) }} </li>
{% endfor %}
But the default data-prototype will render only {{ form_row(role) }} (a hidden field).
Where am I supposed to change the default data-prototype?
There is no {% block prototype %} in form_div_layout.html that i could customize....
The collection widget is defined as follows:
{% block collection_widget %}
{% spaceless %}
{% if prototype is defined %}
{% set attr = attr|merge({'data-prototype': form_row(prototype) }) %}
{% endif %}
{{ block('form_widget') }}
{% endspaceless %}
{% endblock collection_widget %}
So you can override this to gain control on how you want to rendre the prototype.
You can also access prototype from inside template by calling roles.vars.prototype and use it later in your JS. If you want to put it into data-prototype attribute of div (as it is normally rendered) you have to remember to escape it:
<div data-prototype="{{ form_row(roles.vars.prototype) | escape }}">
{% for role in roles %}
<li> {{ role }} {{ form_row(role) }} </li>
{% endfor %}
</div>
The method recommended in the docs allows you to easily customize each collection independently inside your app, all within the same file.
Create a file prototype_layout.html.twig:
{% block _myform_mycollection_entry_row %}
<div class="row">
<div class="col-sm-6">{{ form_row(form.title) }}</div>
<div class="col-sm-6">{{ form_row(form.author) }}</div>
</div>
{% endblock %}
The name of the block is important. The first part will be _myform if your parent form is called MyformType and the second part _mycollection if your form field owning the collection is called so. The third part must always be _entry_row in order for this to work.
For example, if you have a UserType form with a collection of 'books' the block name might be _user_books_entry_row
To make sure you got the name right, add a subform (by clicking the add button adding subforms with javascript) and inspect the id of the corresponding select html element using the inspector tool of your browser.
If it looks like user_books_0_title, then the block name will be _user_books_entry_row
Declare this file as a global form theme in the twig section of config.yml:
twig:
form_themes:
- 'AppBundle:Form:prototype_layout.html.twig' #adapt this path if you saved your file elsewhere
You can also use the file directly in your form view:
{% use "AppBundle:Form:prototype_layout.html.twig" %}
Since umpteens days, I block on a problem with Symfony 2 and forms.
I got a form of websites entities. "Websites" is a collection of website's entities and each website contains two attributes : "type" and "url".
If I want to add more of one website in my database, I can click on a "Add another website" link, which add another website row to my form. So when you click on the submit button, you can add one or X website(s) at the same time.
This process to add a row use the data-prototype attribute, which can generate the website sub-form.
The problem is that I customize my form to have a great graphic rendering... like that :
<div class="informations_widget">{{ form_widget(website.type.code) }}</div>
<div class="informations_error">{{ form_errors(website.type) }}</div>
<div class="informations_widget">{{ form_widget(website.url) }}</div>
<div class="informations_error">{{ form_errors(website.url) }}</div>
But the data-prototype doesn't care about this customization, with HTML and CSS tags & properties. I keep the Symfony rendering :
<div>
<label class=" required">$$name$$</label>
<div id="jobcast_profilebundle_websitestype_websites_$$name$$">
<div>
<label class=" required">Type</label>
<div id="jobcast_profilebundle_websitestype_websites_$$name$$_type">
<div>
<label for="jobcast_profilebundle_websitestype_websites_$$name$$_type_code" class=" required">label</label>
<select id="jobcast_profilebundle_websitestype_websites_$$name$$_type_code" name="jobcast_profilebundle_websitestype[websites][$$name$$][type][code]" required="required">
<option value="WEB-OTHER">Autre</option>
<option value="WEB-RSS">Flux RSS</option>
...
</select>
</div>
</div>
</div>
<div>
<label for="jobcast_profilebundle_websitestype_websites_$$name$$_url" class=" required">Adresse</label>
<input type="url" id="jobcast_profilebundle_websitestype_websites_$$name$$_url" name="jobcast_profilebundle_websitestype[websites][$$name$$][url]" required="required" value="" />
</div>
</div>
</div>
Does anyone have an idea to make that hack ?
A bit old, but here is a deadly simple solution.
The idea is simply to render the collection items through a Twig template, so you have full ability to customize the prototype that will be placed in your data-prototype="..." tag. Just as if it was a normal, usual form.
In yourMainForm.html.twig:
<div id="collectionContainer"
data-prototype="
{% filter escape %}
{{ include('MyBundle:MyViewsDirectory:prototype.html.twig', { 'form': form.myForm.vars.prototype }) }}
{% endfilter %}">
</div>
And in MyBundle:MyViewsDirectory:prototype.html.twig:
<div>
<!-- customize as you wish -->
{{ form_label(form.field1) }}
{{ form_widget(form.field1) }}
{{ form_label(form.field2) }}
{{ form_widget(form.field2) }}
</div>
Credit: adapted from https://gist.github.com/tobalgists/4032213
I know this question is quite old, but I had the same problem and this is how I soved it. I'm using a twig macro to accomplish this. Macros are like functions, you can render them with different arguments.
{% macro information_prototype(website) %}
<div class="informations_widget">{{ form_widget(website.type.code) }}</div>
<div class="informations_error">{{ form_errors(website.type) }}</div>
<div class="informations_widget">{{ form_widget(website.url) }}</div>
<div class="informations_error">{{ form_errors(website.url) }}</div>
{% endmacro %}
now you can render this macro wherever you want. Note that information_prototype() is just the name of the macro, you can name it whatever you want. If you want to use the macro to render the given items and the prototype the same way, do something like this:
<div class="collection" data-prototype="{{ _self.information_prototype(form.websites.vars.prototype)|e }}">
{% for website in form.websites %}
{{ _self.information_prototype(website) }}
{% endfor %}
<button class="add-collection">Add Information</button>
</div>
form.websites.vars.prototype holds the prototype data of the form with the prototype_name you specified. Use _self.+macroname if you want to use the macro in the same template.
You can find out more about macros in the Twig documentation
You probably have found out since but here is the solution for others.
Create a new template and copy/paste this code in it:
https://gist.github.com/1294186
Then in the template containing the form you want to customise, apply it to your form by doing this:
{% form_theme form 'YourBundle:Deal:Theme/_field-prototype.html.twig' %}
I've run into similar problem recently. Here's how you can override the collection prototype without having to explicitly set it in the html:
{% set customPrototype %}
{% filter escape %}
{% include 'AcmeBundle:Controller:customCollectionPrototype.html.twig' with { 'form': form.collection.vars.prototype } %}
{% endfilter %}
{% endset %}
{{ form_label(form.collection) }}
{{ form_widget(form.collection, { 'attr': { 'data-prototype': customPrototype } }) }}
You can do whatever you want then in your custom twig. For example:
<div data-form-collection="item" data-form-collection-index="__name__" class="collection-item">
<div class="collection-box col-sm-10 col-sm-offset-2 padding-top-20">
<div class="row form-horizontal form-group">
<div class="col-sm-4">
{{ form_label(form.field0) }}
{{ form_widget(form.field0) }}
</div>
<div class="col-sm-3">
{{ form_label(form.field1) }}
{{ form_widget(form.field1) }}
</div>
<label class="col-sm-3 control-label text-right">
<button data-form-collection="delete" class="btn btn-danger">
<i class="fa fa-times collection-button-remove"></i>{{ 'form.collection.delete'|trans }}
</button>
</label>
</div>
</div>
Useful when you only have to do it in specific places and don't need a global override that's applicable to all collections.
I know that answer is very late but it maybe useful for visitors.
on your theme file you can simply use one block for rendering every collection entry of websites widget as following:
{% block _jobcast_profilebundle_websitestype_websites_entry_widget %}
<div class="informations_widget">{{ form_widget(form.type.code) }}</div>
<div class="informations_error">{{ form_errors(form.type) }}</div>
<div class="informations_widget">{{ form_widget(form.url) }}</div>
<div class="informations_error">{{ form_errors(form.url) }}</div>
{% endblock %}
also create theme block for your collection widget row as following:
{% block _quiz_question_answers_row %}
{% if prototype is defined %}
{%- set attr = attr | merge({'data-prototype': form_row(prototype) }) -%}
{% endif %}
{{ form_errors(form) }}
{% for child in form %}
{{ form_row(child) }}
{% endfor %}
{% endblock %}
now the prototype and the rendered collection entry will be the same.
I had a somewhat similar issue. You might have to tweak this to work for your case, but someone may find it helpful.
Create a new template file to hold your custom form 'theme'
./src/Company/TestBundle/Resources/views/Forms/fields.html.twig
Normally, you can use the form_row function to display a field's label, error, and widget. But in my case I just wanted to display the widget. As you say, using the data-prototype feature would also display the label, so in our new fields.html.twig type your custom code for how you want the field to look:
{% block form_row %}
{% spaceless %}
{{ form_widget(form) }}
{% endspaceless %}
{% endblock form_row %}
I removed the container div, and the label and error, and just left the widget.
Now in the twig file that displays the form, simply add this after the {% extends ... %}
{% form_theme form 'CompanyTestBundle:Form:fields.html.twig' %}
And now the form_widget(form.yourVariable.var.prototype) will only render the field and nothing else.
Application wide form theming will be applied to the prototype.
See Making Application-wide Customizations
Here is sample code for custom data-prototype:
{{ form_widget(form.emails.get('prototype')) | e }}
where emails — your collection.
To customize differently existing collection items VS prototype, you can override collection_widget like this:
{%- block collection_widget -%}
{% if prototype is defined %}
{%- set attr = attr|merge({'data-prototype': form_row(prototype, {'inPrototype': true} ) }) -%}
{% endif %}
{{- block('form_widget') -}}
{%- endblock collection_widget -%}
And then in your custom entry:
{% block _myCollection_entry_row %}
{% if(inPrototype is defined) %}
{# Something special only for prototype here #}
{% endif %}
{% endblock %}
If you do not need to define a template system-wide, simply set a template in your twig template, and ask twig to use it.
{# using the profiler, you can find the block widget tested by twig #}
{% block my_block_widget %}
<div >
<p>My template for collection</p>
<div >
{{ form_row(form.field1)}}
</div>
<div>
{{ form_row(form.field2)}}
</div>
</div>
{% endblock %}
{% form_theme form.my_collection _self %}
<button data-form-prototype="{{ form_widget(form.my_collection.vars.prototype) )|e }}" >Add a new entry</button>
There are two blocks that you can possibly target to add a custom theme to a collection field:
_myCollection_row and _myCollection_entry_row
_myCollection_row - renders the whole collection.
_myCollection_entry_row - renders a single item.
The prototype relies on _myCollection_entry_row so if you theme _myCollection_row only your theme will appear in the form, but not the prototype. The prototype uses _myCollection_entry_row.
So it's best to theme _myCollection_entry_row first, and then theme _myCollection_row only if required. BUT - if you theme _myCollection_row make sure it calls _myCollection_entry_row to render each item in your collection.
This post focuses on using pre-existing conventions within the twig template.
Basing off "How to Embed a Collection of Forms" from the Symfony Cookbook (http://symfony.com/doc/master/cookbook/form/form_collections.html), you can just enter whatever html_escaped form data you wish in the data-prototype (maybe considered a hack, but works wonderfully) and only pages using that template will change.
In the example, they tell you to put:
<ul class="tags" data-prototype="{{ form_widget(form.tags.vars.prototype)|e }}">
...
</ul>
This can be successfully replaced with something such as:
<table class="tags" data-prototype="<tr> <td><div><input type="text" id="task_tags__name__tagId" name="task[tags][__name__][taskId]" disabled="disabled" required="required" size="10" value="" /></div></td> <td><div><input type="text" id="task_tags__name__tagName" name="task[tags[__name__][tagName]" required="required" value="" /></div></td></tr>">
<tr>
<th>Id</th>
<th>Name</th>
</tr>
<tr>
...pre existing data here...
</tr>
</table>
Where the data-type attribute of the table with the class "tags" above is the html-escaped version (and line breaks removed though spaces are ok and required) of:
<tr>
<td><div><input type="text" id="task_tags__name__tagId" name="task[tags][__name__][taskId]" disabled="disabled" required="required" size="10" value="" /></div></td>
<td><div><input type="text" id="task_tags__name__tagName" name="task[tags[__name__][tagName]" required="required" value="" /></div></td>
</tr>
...but you must also adjust the javascript in the example to add tr's instead of li elements:
function addTagForm(collectionHolder, $newLinkTr) {
...
// Display the form in the page in an tr, before the "Add a question" link tr
var $newFormTr = $('<tr></tr>').append(newForm);
...
};
...
// setup an "add a tag" link
var $addTagLink = $('Add a tag');
var $newLinkTr = $('<tr></tr>').append($addTagLink);
...
For me, the next step is figuring out how to define the prototype in an external file that I can somehow call in the twig template for the data-prototype that dynamically works with the form. Something like:
<table class="tags" data-prototype="{{somefunction('App\Bundle\Views\Entity\TagsPrototypeInTable')}}">
So if one of the other posts is describing this and I am too dense or if someone knows how to do such, say so!
There is a link to something from gitHub from Francois, but I didn't see any explanation so I think that is probably the more dynamic method I'll get to one of these near-future days.
Peace,
Steve
Update:
One can also use just parts of the prototype:
data-prototype="<tr> <td>{{ form_row(form.tags.vars.prototype.tagId) | e }}</td> <td>{{ form_row(form.tags.vars.prototype.tagName) | e }}</td></tr>"
Where the data-type attribute of the table with the class "tags" above is the html-escaped version (and line breaks removed though spaces are ok and required) of:
<td>{{ form_row(form.tags.vars.prototype.tagId) | e }}</td>
<td>{{ form_row(form.tags.vars.prototype.tagName) | e }}</td>
(I used http://www.htmlescape.net/htmlescape_tool.html.)
Symfony will replace the information between the {{}} with an html_escaped (because of the "|e") rendered field when the page is rendered. In this way, any customization at the field-level is not lost, but! you must manually add and remove fields to the prototype as you do so with the entity :)