Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rande opened this issue Nov 20, 2015 · 9 comments
Closed

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

rande opened this issue Nov 20, 2015 · 9 comments
Labels
Form

Comments

@rande
Copy link
Contributor

rande commented Nov 20, 2015

I am working on Sonata Project migration to work on symfony2.8 and symfony3.0. I get an architectural issue with the new method signature for the FormFactory. The type must be a FQCN, the FQCN has one major drawback, you have a 1:1 relation between the type and the class/instance. With the previous signature you have a N:N relation between types and the class, ie you can have different types handled by the same class but with different instance configurations.

With sf2.7,

new Symfony\Component\Form\Extension\DependencyInjection\DependencyInjectionExtension($this, array(
'sonata_classification_api_form_category' => 'sonata.classification.api.form.type.category', 
'sonata_classification_api_form_collection' => 'sonata.classification.api.form.type.collection', 
'sonata_classification_api_form_tag' => 'sonata.classification.api.form.type.tag', 
'sonata_classification_api_form_context' => 'sonata.classification.api.form.type.context',
);

The class behind the service is Sonata\CoreBundle\Form\Type\DoctrineORMSerializationType with different configurations per instance...

With > SF2.8:

new Symfony\Component\Form\Extension\DependencyInjection\DependencyInjectionExtension($this, array(
'Sonata\CoreBundle\Form\Type\DoctrineORMSerializationType' => 'sonata_classification_api_form_context' );

Of course, we are loosing definitions as the FQCN overlap keys. Is the best practice is to create a class per type ? If so we are loosing the benefit of OOP.

This change make very hard to have one bundle version working with Symfony 2.7, 2.8 and 3.0. And I don't see any benefit of it.

Can you explain or point to the valid PR which explain this choice?
@weaverryan
Copy link
Member

I believe the idea is that you should have one form type and then configure it in 4 different ways when you use it. Or, have 1 base class (DoctrineORMSerializationType), then sub-class that 4 times, where each changes the option values passed to the parent type.

I don't know if this fully helps @rande - but this is a starting point. Obviously, we need SonataAdminBundle to be able to upgrade :)

For reference: #15079.

@rande
Copy link
Contributor Author

rande commented Nov 20, 2015

@weaverryan Thanks for your reply. Looks like there are a lot of thread about this.

I still feel it is wrong: DX is bad, not OOP friendly, and this will not help to have support for SF2.7 and SF3.0 with the same bundle version. I am almost forced to create major version of sonata's bundles just for that (as far as I am with deprecated issues on 2.8).

@weaverryan
Copy link
Member

@rande I don't disagree (or necessarily agree, though I think this will be a big annoying upgrade problem for people). What's your approach then: create multiple sub-classes for each? Is that the BC break that you'll be introducing?

@rande
Copy link
Contributor Author

rande commented Nov 20, 2015

@weaverryan I will create empty class for each type. 20 so far ... this will solve integration with 3.0. but I will still need to find a hack to not used the FCQN to avoid breaking tone of Admin instances ...

@Tobion
Copy link
Contributor

Tobion commented Nov 20, 2015

@rande I think you can still register different instances of the same form type via DI just as before. The name must not be a real existing FQCN. This is just the case for most use-cases and all core form types (which avoids to force people invent names for getName() - this is the major DX).

But you can still do the same as before. Just register the form types with different names and then reference them in the factory.

@rande
Copy link
Contributor Author

rande commented Nov 20, 2015

@Tobion not sure I understand your solution. With symfony3, you must have one class per type: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/FormRegistry.php#L109-L124. So the only solution is to create empty classes to the fqcn array will be populated properly.

@Tobion
Copy link
Contributor

Tobion commented Nov 20, 2015

Hm I see. I think that is wrong. It should still use the $name as index of the types as given to getType($name). Otherwise it's strange that there can be many names that all resolve to the same class and type.

@rande
Copy link
Contributor Author

rande commented Nov 20, 2015

@Tobion for now: #16615

@xabbuh xabbuh added the Form label Nov 22, 2015
@xabbuh xabbuh mentioned this issue Nov 25, 2015
Closed
@rande
Copy link
Contributor Author

rande commented Nov 25, 2015

For the record, the architectural form changes will not be altered/reverted. Update your application/bundles or use a mapping bundle (soon to be announced) to restore the feature. At least the Symfony Core team will not be in charge of that.

@rande rande closed this as completed Nov 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Form
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rande @weaverryan @Tobion @xabbuh