Fix TemplateRegistry usages

[wbloszyk]

Subject

Based on #6383 (comment) I made some research and I found what can be improve.

• service: admin_code // Admin object
• service admin_code.template_registry // TemplateRegistry object dedicated for specify Admin

It mean We should be able to get TemplateRegistry object directly from admin, becouse we can get it from container.

I also remove some unnecessary NEXT_MAJOR

I am targeting this branch, because this change respect BC.

Changelog

### Added
- `Sonata\AdminBundle\Admin\AbstractAdmin::hasTemplateRegistry(): bool`
### Deprecated
- `Sonata\AdminBundle\Admin\AbstractAdmin::setTemplates()`
- `Sonata\AdminBundle\Admin\AbstractAdmin::setTemplate()`

[jordisala1991]

This should probably be done on master to avoid BC breaks

[wbloszyk]

@jordisala1991

• change protected to public in getTemplateRegistry() is BC becouse it is final
• throw LogicException is BC too becouse otherwise error You cannot call ... on null will be throw

I think I should revert NEXT_MAJOR. Someone can override getTemplate method.

[wbloszyk]

@core23 Can we merge it?

[wbloszyk]

@phansys Sorry for another request for review. I click it before icon refresh. :)

[franmomu]

If the plan is to call getTemplateRegistry from the CRUDController shouldn't be added to the AdminInterface?

[phansys]

Is there any constraint requiring setTemplate() or setTemplates() to be defined? If not, I think we should use TemplateRegistryInterface instead of MutableTemplateRegistryInterface.

[wbloszyk]

In 3.x branch:

    public function setTemplates(array $templates)
    {
        // NEXT_MAJOR: Remove this line
        $this->templates = $templates;

        $this->getTemplateRegistry()->setTemplates($templates);
    }

[phansys]

I understand that's the case for 3.x, but then we should add a NEXT_MAJOR comment explaining how to proceed in the next major release.
The changes at AdminInterface should refer to TemplateRegistryInterface, right?

[wbloszyk]

$admin->getTemplateRegistry() should be equal to admin_code.template_registry service. It is created on:

final class TemplateRegistry implements MutableTemplateRegistryInterface

So MutableTemplateRegistryInterface will be correct.

[jordisala1991]

IMO we should check against null.

[wbloszyk]

Checking will be add in master. We can't throw exeption becouse someone compare getTemplateRegistry() to null. What we can do in 3.x is only add custom description for $this->getTemplateRegistry()->setTemplates($templates); exception.

[jordisala1991]

I mean: return $this->... !== null

[wbloszyk]

done

[franmomu]

I think @phansys is right, there is no need to return MutableTemplateRegistryInterface if we are not using setTemplates or setTemplate.

[wbloszyk]

@franmomu #6387 (comment)

[core23]

Not related to this PR, but we can remove this line

[wbloszyk]

To many change on this PR. Lets do it in another PR. Mybe we should create "Clean up" PR? 😅

@phansys sugestion is made and accepted by @jordisala1991.

[franmomu]

Is this method used outside the AbstractAdmin? If so, should be added to the interface?

[wbloszyk]

It is new method, so it is not used for now. IMO all setTemplateRegistry, getTemplateRegistry and hasTemplateRegistry should be add to seperate TemplateRegistryOwnerInterface. AdminInterface should inplemented it.