[Form] Deprecated FormTypeInterface::getName() and passing of type instances #15079

webmozart · 2015-06-23T16:45:39Z

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	#5321, #15008
License	MIT
Doc PR	TODO

Type Names

This PR deprecates the definition of the getName() method of form types. See #15008 for a more detailed description.

Before:

class MyType extends AbstractType
{
    public function getName()
    {
        return 'mytype';
    }

    // ...
}

After:

class MyType extends AbstractType
{
    // ...
}

You should always reference other types by their fully-qualified class names. Thanks to PHP 5.5, that's easy:

Before:

$form = $this->createFormBuilder()
    ->add('name', 'text')
    ->add('age', 'integer')
    ->getForm();

After:

$form = $this->createFormBuilder()
    ->add('name', TextType::class)
    ->add('age', IntegerType::class)
    ->getForm();

Type Instances

Furthermore, passing of type instances is deprecated.

Before:

$form = $this->createForm(new AuthorType());

After:

$form = $this->createForm(AuthorType::class);

DIC Aliases

When registering a type in the DIC, you should omit the "alias" attribute now.

Before:

<service id="my.type" class="Vendor\Type\MyType">
    <tag name="form.type" alias="mytype" />
    <argument type="service" id="some.service.id" />
</service>

After:

<service id="my.type" class="Vendor\Type\MyType">
    <tag name="form.type" />
    <argument type="service" id="some.service.id" />
</service>

Types without dependencies don't need to be registered in the DIC as they can be instantiated right away.

Template Block Prefixes

By default, the class name of the type in underscore notation minus "Type" suffix is used as Twig template block prefix (e.g. UserProfileType => user_profile_*). If you want to customize that, overwrite the new getBlockPrefix() method in your type:

class UserProfileType extends AbstractType
{
    public function getBlockPrefix()
    {
        return 'profile';
    }

    // ...
}

Tobion · 2015-06-23T21:49:19Z

I think you can simply add the service id to the $types additionally to the class name. This way both work as alias and there is no BC break.

Tobion · 2015-06-23T21:50:47Z

src/Symfony/Component/Form/FormFactory.php

+
+        if (false === ($pos = strrpos($typeName, '\\'))) {
+            // No FQCN - leave unchanged for BC
+            $name = $typeName;


are we going to remove that in 3.0? Then we could also remove the FormType::getName completely, or?

webmozart · 2015-06-24T13:32:52Z

Updated. Ping @symfony/deciders

stof · 2015-06-24T13:42:40Z

UPGRADE-2.8.md

+   {
+       public function getParent()
+       {
+           return new ParentType();


this was more likely to return an alias though

ah sorry, I misread the deprecation message. I confused with the deprecation of type names (which is the main goal of this PR even though this other change went in)

Returning an instance in getParent was indeed a bad idea by forcing to resolve types again and again.

I think stof missed that this is describing the deprecated way.

javiereguiluz · 2015-06-24T13:59:07Z

@webmozart I have a question. You say that when using PHP 5.5, the needed changes are minimal:

Before:

$form = $this->createFormBuilder()
    ->add('name', 'text')
    ->add('age', 'integer')
    ->getForm();

$form = $this->createForm(new AuthorType());

After:

use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\Extension\Core\Type\IntegerType;
use AppBundle\Form\Type\AuthorType;

$form = $this->createFormBuilder()
    ->add('name', TextType::class)
    ->add('age', IntegerType::class)
    ->getForm();

$form = $this->createForm(AuthorType::class);

My question is: if you use PHP 5.3 or PHP 5.4, you should use the following?

$form = $this->createFormBuilder()
    ->add('name', 'Symfony\Component\Form\Extension\Core\Type\TextType')
    ->add('age', 'Symfony\Component\Form\Extension\Core\Type\IntegerType')
    ->getForm();

$form = $this->createForm('AppBundle\Form\Type\AuthorType');

stof · 2015-06-24T14:01:13Z

@javiereguiluz yes

webmozart · 2015-06-24T14:01:58Z

@javiereguiluz Exactly. However, passing "text" or similar type names is still supported until Symfony 3.0 (although you'll get deprecation notes). Symfony 3.0 has a higher minimum PHP version anyway so there this is not a problem anymore.

javiereguiluz · 2015-06-24T14:04:01Z

@webmozart the original idea of this change was to improve DX by getting rid of the getName(). However, I find this change anti-DX because you now have to type a lot more.

stof · 2015-06-24T14:04:26Z

@webmozart can you fix the SecurityBundle form login test failures ? These tests are passing on the current 2.8 branch

Koc · 2015-06-24T14:04:41Z

Does it possible use dynamic form names? Currently we are using inline editing for cities in grid:

$form = $this->container->get('form.factory')->createNamed(
            CityInlineEditType::getNameForCity($city),
            new CityInlineEditType(),
            $city
        );

Is this code still walid after this PR?

webmozart · 2015-06-24T14:05:43Z

@Koc Sure, you can use any form name you like. However, the type needs to be passed as FQCN, i.e.

$form = $this->container->get('form.factory')->createNamed(
    CityInlineEditType::getNameForCity($city),
    CityInlineEditType::class,
    $city
);

stof · 2015-06-24T14:05:44Z

@Koc this PR is about type names, not about forms names.

@webmozart how does this impact the block names in form themes ?

DavidBadura · 2015-06-24T14:06:12Z

Is it still possible to use alias? What if you have a type and you want then use this with various dependencies? I have to extend my class to solve this problem?

webmozart · 2015-06-24T14:09:39Z

@javiereguiluz That's FUD. As I've shown above, you are writing less code than before. As of using types in forms, instead of typing 'text' (6 chars) you now type TextT + ENTER and let the IDE do the rest. That's one character less + type safety.

dosten · 2015-06-24T14:09:44Z

@DavidBadura you should add the type as a service

<service id="my.type" class="Vendor\Type\MyType">
    <tag name="form.type" />
    <argument type="service" id="some.service.id" />
</service>

and do something like this

$form = $this->createFormBuilder()
    ->add('name', MyType::class)¿
    ->getForm();

Tobion · 2015-07-01T13:50:44Z

src/Symfony/Component/Form/AbstractType.php

+     * The block prefixes defaults to the underscored short class name with
+     * the "Type" suffix removed (e.g. "UserProfileType" => "user_profile").
+     *
+     * @return string|null The prefix of the template block name or `null` to


the null part is not relevant anymore

Tobion · 2015-07-01T14:12:05Z

I think the old way of forcing people to implement getName was NOT good for three reasons:

there is already a class name to identify it, meaning getName is redundant
as we know, naming things is hard. thus forcing people to invent a name just creates a burden
easily creates conflicting names

This is why I proposed to remove/deprecate this concept completely instead of just making it optional.
The new way also has another advantage: It makes code self-documenting.
Writing/seeing code like $formBuilder->add('property', 'entity') is not expressive (what options are available, what does entity do?), but $formBuilder->add('property', EntityType::class) is. It allows you to easily open the EntityType class to look at documention and exposed options.
So I think it is DX-friendly. IDEs could even go futher now and propose/autocomplete all classes in your project that implement FormTypeInterface when building a form. Such things wouldn't be easily possible to automate when using abstract names which are resolved at runtime.

The only disadvantage I see is that using the class name does not correspond to type extensions. Using a class name as reference (in contrast to an abstract name) makes people assume it's really just this class. But type extensions can do anything on top of it which somehow clashes with the object-oriented way of using a class name. But I think type extensions are not so common anyway (esp. in user-defined ones).

All in all, I'm 👍

webmozart · 2015-07-01T15:58:31Z

src/Symfony/Component/Form/Extension/Core/Type/BaseType.php

+                array_unshift($blockPrefixes, $type->getBlockPrefix());
+            } else {
+                @trigger_error(get_class($type).': The ResolvedFormTypeInterface::getBlockPrefix() method will be added in version 3.0. You should add it to your implementation.', E_USER_DEPRECATED);
+                array_unshift($blockPrefixes, $type->getName());


This code needs to deal with FQCNs.

stof · 2015-07-01T16:16:43Z

The only disadvantage I see is that using the class name does not correspond to type extensions. Using a class name as reference (in contrast to an abstract name) makes people assume it's really just this class. But type extensions can do anything on top of it which somehow clashes with the object-oriented way of using a class name. But I think type extensions are not so common anyway (esp. in user-defined ones).

not only type extension but also type inheritance. but this is just a documentation thing IMO.

aderuwe · 2015-07-01T16:26:12Z

This looks really good. Thanks @webmozart.

…stances

webmozart · 2015-07-02T08:03:29Z

Updated.

Tobion · 2015-07-02T09:15:26Z

src/Symfony/Component/Form/AbstractType.php

+    /**
+     * Returns the prefix of the template block name for this type.
+     *
+     * The block prefixes defaults to the underscored short class name with


typo: default without s

fixed in 8d049c5

fabpot · 2015-08-01T06:44:31Z

Thank you @webmozart.

…sing of type instances (webmozart) This PR was merged into the 2.8 branch. Discussion ---------- [Form] Deprecated FormTypeInterface::getName() and passing of type instances | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #5321, #15008 | License | MIT | Doc PR | TODO #### Type Names This PR deprecates the definition of the `getName()` method of form types. See #15008 for a more detailed description. Before: ```php class MyType extends AbstractType { public function getName() { return 'mytype'; } // ... } ``` After: ```php class MyType extends AbstractType { // ... } ``` You should always reference other types by their fully-qualified class names. Thanks to PHP 5.5, that's easy: Before: ```php $form = $this->createFormBuilder() ->add('name', 'text') ->add('age', 'integer') ->getForm(); ``` After: ```php $form = $this->createFormBuilder() ->add('name', TextType::class) ->add('age', IntegerType::class) ->getForm(); ``` #### Type Instances Furthermore, passing of type instances is deprecated. Before: ```php $form = $this->createForm(new AuthorType()); ``` After: ```php $form = $this->createForm(AuthorType::class); ``` #### DIC Aliases When registering a type in the DIC, you should omit the "alias" attribute now. Before: ```xml <service id="my.type" class="Vendor\Type\MyType"> <tag name="form.type" alias="mytype" /> <argument type="service" id="some.service.id" /> </service> ``` After: ```xml <service id="my.type" class="Vendor\Type\MyType"> <tag name="form.type" /> <argument type="service" id="some.service.id" /> </service> ``` Types without dependencies don't need to be registered in the DIC as they can be instantiated right away. #### Template Block Prefixes By default, the class name of the type in underscore notation minus "Type" suffix is used as Twig template block prefix (e.g. `UserProfileType` => `user_profile_*`). If you want to customize that, overwrite the new `getBlockPrefix()` method in your type: ```php class UserProfileType extends AbstractType { public function getBlockPrefix() { return 'profile'; } // ... } ``` Commits ------- 3d9e5de [Form] Deprecated FormTypeInterface::getName() and passing of type instances

Hanmac · 2015-11-19T10:29:34Z

with this change how will i do now that my Type has some dependency injection stuff as constructor or otherwise?

before i did this in service.yml:

    mybundle.form.type.address:
        class: %mybundle.form.type.address.class%
        arguments: [ @mybundle.service.transformator_factory ]
        tags:
            - { name: form.type, alias: address }

the transformator_factory did return a DataTransformerInterface i did use for addModelTransformer
(i need that because ParamConverter did had problems with my Object because i need an object inside a object)

now does the FormBuilder respect my service definition, and if not how can i get that working again in future symfony 2.8+ or 3.0?

nicolas-grekas · 2015-11-19T10:33:51Z

@Hanmac please open an issue, comments in closed PRs are hard to track

stof · 2015-11-19T10:37:38Z

@Hanmac this works exactly as before (except that you don't need the alias anymore in the tag if you use only the 2.8+ API)

…eahDude) This PR was merged into the 3.1-dev branch. Discussion ---------- [FrameworkBundle] Deprecated form types as services | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | ~ | License | MIT | Doc PR | ~ These services are needless in regard of #15079. If they have no dependencies, whatever are the registered extensions, `FormTypeInterface` instances will be autoloaded by their FQCN. Commits ------- dfe4f53 [FrameworkBundle] Deprecated form types as services

TomasVotruba · 2020-07-13T15:21:57Z

UPGRADE-2.8.md

+   from your form types.
+
+   If you want to customize the block prefix of a type in Twig, you should now
+   implement `FormTypeInterface::getBlockPrefix()` instead:


What exactly does "block prefix of a type in Twig" mean?

I'm upgrading old Symfony projects and this line is a mystery for me. Can I remove the getName() or not?
I'd appreciated some Twig snippet example what exactly is meant here.

This refers to how form fragment names are generated. By default, the value is derived from the class name (see e.g. https://symfony.com/doc/current/form/form_themes.html#form-fragment-naming where textarea is derived from TextareaType class). If you have your own TextareaType class, you will maybe want to override the getBlockPrefix() method to not reuse the blocks used by the core TextareaType.

I never used such fragments and docs is very confusing for me. I don't see any twig sample for textarea_widget keyword. I also checked PRs referecing this PR when upgrading, but it seems nobody ever used it on custom types.

I look for 3 lines of twig sample, so I can just scan twig templates with regualar expression. There are no Twig tests that could tell us what broke.

{{ form_widget(form.age) }} {{ textarea_widget(form.age) }}

So for custom:

class SomeType extends FormType { public function getName() { return 'yolo'; } }

↓

{{ yolo_widget(form.age) }}

Like this?

So it's string from getName() + somehow _widget magically added?

If you just looking for a way to automatically update the code of the form type class, I would compare the value returned in getName() with what the automatically computed name would be (see

symfony/src/Symfony/Component/Form/AbstractType.php

Line 55 in ba4d57b

return StringUtil::fqcnToBlockPrefix(static::class) ?: '';

). Only if both values differ, you will need to rename the getName() method to getBlockPrefix(). Otherwise it can be removed.

That's what I already do with rectorphp/rector#3705 I made it just before reading your comment :D

I want to take it further and remove all the getBlockPrefix() that:

don't have standard name

are never used in the twig templates

That's why I ask how can I find it in the twig templates.

Any example for that?

The special block names are *_row, *_label, *_widget and *_errors (nowadays there is also *_help, but I guess you are addressing 2.8 applications here). But you need to be careful as the block prefix is also used to build block names for CollectionType entries (see https://symfony.com/doc/2.8/form/form_customization.html#form-custom-prototype).

webmozart added Form DX DX = Developer eXperience (anything that improves the experience of using Symfony) labels Jun 23, 2015

webmozart mentioned this pull request Jun 23, 2015

[Form] Add default implementation for AbstractType::getName() #15008

Closed

webmozart force-pushed the issue15008 branch from d6a009c to e33fcd2 Compare June 23, 2015 16:55

Tobion reviewed Jun 23, 2015
View reviewed changes

webmozart force-pushed the issue15008 branch 2 times, most recently from de9a855 to f516801 Compare June 24, 2015 13:25

webmozart changed the title ~~[Form] Added default implementation of AbstractType::getName()~~ [Form] Deprecated FormTypeInterface::getName() and passing of type instances Jun 24, 2015

webmozart force-pushed the issue15008 branch from f516801 to 08f2b44 Compare June 24, 2015 13:30

webmozart added the Ready label Jun 24, 2015

stof reviewed Jun 24, 2015
View reviewed changes

Tobion reviewed Jul 1, 2015
View reviewed changes

webmozart reviewed Jul 1, 2015
View reviewed changes

[Form] Deprecated FormTypeInterface::getName() and passing of type in…

3d9e5de

…stances

webmozart force-pushed the issue15008 branch from 80a7e5d to 3d9e5de Compare July 2, 2015 08:02

Tobion reviewed Jul 2, 2015
View reviewed changes

fabpot merged commit 3d9e5de into symfony:2.8 Aug 1, 2015

xabbuh mentioned this pull request Aug 1, 2015

FormTypeInterface::getName() is deprecated symfony/symfony-docs#5588

Closed

craue mentioned this pull request Aug 3, 2015

avoid deprecation notices with Symfony 2.8 craue/CraueConfigBundle#22

Merged

ogizanagi mentioned this pull request Oct 9, 2015

Define FormType class instead of a classic type EasyCorp/EasyAdminBundle#385

Closed

hiddewie mentioned this pull request Oct 24, 2015

[Form][2.8,3.0] Type guesser guesses alias instead of FQCN #16332

Closed

fabpot mentioned this pull request Nov 16, 2015

Release v2.8.0-BETA1 #16550

Merged

weaverryan mentioned this pull request Nov 20, 2015

[Form][2.8 and 3.0] Form type usage #16611

Closed

tamasnyulas mentioned this pull request Jan 28, 2016

FormType dependency injection #17592

Closed

This was referenced Mar 29, 2016

[FrameworkBundle] Deprecated form types as services #18343

Closed

[DoctrineBundle] Deprecated form types and guessers as services doctrine/DoctrineBundle#528

Closed

[FrameworkBundle] Deprecated form types as services #18356

Merged

ste93cry mentioned this pull request Jul 24, 2016

[ResourceBundle] ResourceFormFactory is not compatible with Symfony 2.8+ Sylius/Sylius#5590

Closed

escopecz mentioned this pull request Nov 25, 2018

Send example as contact mautic/mautic#6090

Closed

TomasVotruba reviewed Jul 13, 2020

View reviewed changes

[Form] Deprecated FormTypeInterface::getName() and passing of type instances #15079

[Form] Deprecated FormTypeInterface::getName() and passing of type instances #15079

Conversation

webmozart commented Jun 23, 2015

Type Names

Type Instances

DIC Aliases

Template Block Prefixes

Tobion commented Jun 23, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

webmozart commented Jun 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiereguiluz commented Jun 24, 2015

stof commented Jun 24, 2015

webmozart commented Jun 24, 2015

javiereguiluz commented Jun 24, 2015

stof commented Jun 24, 2015

Koc commented Jun 24, 2015

webmozart commented Jun 24, 2015

stof commented Jun 24, 2015

DavidBadura commented Jun 24, 2015

webmozart commented Jun 24, 2015

dosten commented Jun 24, 2015

Choose a reason for hiding this comment

Tobion commented Jul 1, 2015

Choose a reason for hiding this comment

stof commented Jul 1, 2015

aderuwe commented Jul 1, 2015

webmozart commented Jul 2, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fabpot commented Aug 1, 2015

Hanmac commented Nov 19, 2015

nicolas-grekas commented Nov 19, 2015

stof commented Nov 19, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomasVotruba Jul 13, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomasVotruba Jul 13, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomasVotruba Jul 13, 2020 •

edited

Loading

TomasVotruba Jul 13, 2020 •

edited

Loading