Added a new Range
form type
The HTML5 range
form field was missing from the list of built-in Symfony
Form types. This new type is rendered as a slider in browsers that support HTML5
form controls. Use the min
and max
attributes to constraint the selectable
values:
1 2 3
$builder->add('rating', 'Symfony\Component\Form\Extension\Core\Type\RangeType', [
'attr' => ['min' => 0, 'max' => 10]
]);
Added the prototype_data
option to collection type
Forms that contain collections allow to customize the HTML used to add new items
(prototype option) and the name of the placeholder used in that template
(prototype_name option). Symfony 2.8 allows to also define the default data
of each new collection row thanks to the prototype_data
option:
1 2 3 4 5
$builder->add('tags', 'Symfony\Component\Form\Extension\Core\Type\CollectionType', [
// ...
'by_reference' => false,
'prototype_data' => '...',
]);
Added choice_translation_domain
option for date-related types
In Symfony 2.7 we added the choice_translation_domain
option to define how
should choice values be translated. In Symfony 2.8, this option was enabled for
date related types too (DateType
, TimeType
and DateTimeType
):
1 2 3 4
$builder->add('publishedAt', 'Symfony\Component\Form\Extension\Core\Type\DateTimeType', [
// ...
'choice_translation_domain' => 'messages',
]);
The choice_translation_domain
option allows several types of values:
true
= use the current translation domain;false
= don't translate the values;null
= use the parent translation domain or the default domain;- any other string value = use that exact translation domain.
Allowed to return null
for query_builder
Sometimes it's useful to display an empty list of entries for entity
form types.
In Symfony 2.7 you needed to pass an empty list to its choices
option. In
Symfony 2.8, you can return null
in the query_builder
closure to display
an empty list of entries:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
$event->getForm()->add('events', 'Symfony\Component\Form\Extension\Core\Type\EntityType', [
'class' => 'AppBundle:Event',
'property' => 'title',
'query_builder' => function(EntityRepository $er) {
return $er->getEventQueryBuilder();
}
]));
// ...
public function getEventQueryBuilder()
{
if ( ... some condition ... ) {
return null;
}
$qb = $this->getEntityManager()->createQueryBuilder();
return $qb->select(...)->...;
}
Foundation 5 form theme
In Symfony 2.6 we introduced a form theme for applications which use the ubiquitous Bootstrap CSS framework. In Symfony 2.8 we expanded our CSS framework support by adding a new form theme for Foundation 5 CSS framework.
Use the form_themes
configuration option to apply this theme to all your forms:
1 2 3 4
# app/config/config.yml
twig:
form_themes:
- 'foundation_5_layout.html.twig'
foundation 6 is released=)
If I'm right (hope so), this is the first blogpost where the FQCN is used to add types to the builder. As the plan is to remove it in 3.0, it would be nice to mention this over here?
https://github.com/symfony/symfony/blob/2.8/UPGRADE-2.8.md#form
Nice additions !
@Richard van Laak - I think it's other way around - type 'names' like 'entity' are deprecated - not FQCN
Yeah, you're right. The "to remove it" refers to the old way of adding types, by their name instead of FQCN. Didn't follow the decision process around this deprecation, so would love to have some consise explanation around that :-)
Richard van Laak, it's mentioned on the second bullet point in the link you posted.
the example mentions
Symfony\Component\Form\Extension\Core\Type\EntityType
but this class doesn't exist in current release s2.8 or s3.0. shouldn't it beSymfony\Bridge\Doctrine\Form\Type\EntityType
?FQCN instead of type names is really radical change for my taste. This is the only thing, which prevents me to migrate to 3.0. I have to redo all my custom form types. I understand the desire to remove extra code, but can't see how $builder->add('field', FooType::class) is as easy as $builder->add('field', 'foo').
@Dmitri Lakachauskis - I'd agree with those sentiments as well. It's very confusing to me how the form type change to a FQCN was branded as DX. This seems to make writing bundles compatible with multiple Symfony versions more complex. Not to mention not everyone uses a IDE that does all the auto-completion for them. Searching for class names is not so fun.