Deprecate ContainerBlockService

[VincentLanglet]

Subject

@jordisala1991 The containerBlockService is referencing @SonataBlock/Block/block_container.html.twig here: https://github.com/sonata-project/SonataBlockBundle/blob/4.x/src/Block/Service/ContainerBlockService.php#L89

Do you know what should I do about this template since it always referenced here: https://github.com/sonata-project/SonataBlockBundle/blob/4.x/src/DependencyInjection/SonataBlockExtension.php#L40-L44 and https://github.com/sonata-project/SonataBlockBundle/blob/4.x/src/DependencyInjection/SonataBlockExtension.php#L85-L90

Also, isn't it weird to have

• a container config https://github.com/sonata-project/SonataBlockBundle/blob/4.x/src/DependencyInjection/Configuration.php#L117-L142 should be deprecated/removed too,
• a containerTemplate type https://github.com/sonata-project/SonataBlockBundle/blob/4.x/src/Form/Type/ContainerTemplateType.php
• but no container blocks

I kinda forget the reason of the deprecation of this block. Does it make sens to have all this stuff container-related in BlockBundle even without a ContainerBlock (I dunno what's for) or should we fix the ContainerblockService ?

Closes #1109.

Changelog

### Deprecated
- ContainerBlockService

[jordisala1991]

Maybe we don't have to deprecate this block indeed... We tried to deprecate because the edit form is using a collection type for children. That collection type is coming from sonata form extension, but it is unable to work without SonataAdminBundle, because we need to pass a fourth parameter to make it inline...

But I agree there is a lot of other related classes here that does not make sense to deprecate.

Maybe we need to revert some changes on PageBundle and rely again on this block, but changing the needed stuff to make the collection work. wdyt?

[VincentLanglet]

Maybe we need to revert some changes on PageBundle and rely again on this block, but changing the needed stuff to make the collection work. wdyt?

Is it possible ?

[jordisala1991]

Well we might have to do something like:

$form->remove('collection')
$form->add('collection')...

and redefine all the options...

[SonataCI]

Could you please rebase your PR and fix merge conflicts?

[VincentLanglet]

Well we might have to do something like:

$form->remove('collection')
$form->add('collection')...

and redefine all the options...

If I remember correctly.

In BlockBundle there is

$form->add('children', CollectionType::class);

in PageBundle there is

$form->add('children', CollectionType::class, [], [
            'edit' => 'inline',
            'inline' => 'table',
            'sortable' => 'position',
        ]);

The whole issue is about how SonataAdmin / SonataBlock were splitted. We have a FormMapper interface in SonataBlock which is never implemented and without the 4th parameter. Best would be to have a repository with interface, then SonataBlock would have been able to use the InterfaceBundle and SonataAdmin would have been able to use the SonataBlockBundle...

Here, I remember that

[
     'edit' => 'inline',
     'inline' => 'table',
     'sortable' => 'position',
]

is needed, but I don't remember why. I mean, if this is not working without why it's not the default options when using a CollectionType on a AdminFormMapper ? This way

$form->add('children', CollectionType::class);

would be enough for SonataPage.

[jordisala1991]

Changing the default options for collectionType looks like a bc break to me.

[jordisala1991]

We want to revert the page bundle to start using this class, and not deprecate it.

Question is: can we do better to avoid removing and re adding a field on pagebundle?

1. Somehow we make that options a default (bc break)
2. Maybe we can add those option as a form type options, and then adminBundle can use that to set on the field description?
3. Dont care and just do the remove/ add
4. ...

but the idea would be to not deprecate anything here.

[VincentLanglet]

Changing the default options for collectionType looks like a bc break to me.

Sure it is. I was thinking it could be the long term solution.

Also, if others options are not working for the CollectionType (or this case was special ? I don't remember), changing the option from a not working one to a working one is not a bc break.

Maybe we can add those option as a form type options, and then adminBundle can use that to set on the field description?

How ?

(Fun fact, not sure why but there is already a CollectionType in form-extensions and in sonata admin https://github.com/sonata-project/SonataAdminBundle/blob/4.x/src/Form/Type/CollectionType.php)

4 ...

Add the fourth parameter to the FormMapperInterface (or create a new one...) But it feel more and more like moving the Admin FormMapper interface to BlockBundle :/