Skip to content
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.

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

Improve "sonata.admin.template_registry" tag #6566

Closed

Conversation

wbloszyk
Copy link
Member

@wbloszyk wbloszyk commented Nov 3, 2020

Subject

After move templates from AbsractAdmin to TemplateRegistry some methods were deprecated (like setTemplate and setTemplates). To allow configuration templates in easy way like it was before some important change are require.

Additional attributes on tag

Usages

with TemplateRegistryInterface

You MUST set templates by argument but you can override it by tag.

with MutableTemplateRegistryInterface

You CAN set templates by argument, override it by call setTemplate or setTemplates method and than override it again by tag.

with TemplateRegistryAwareInterface

  • You CAN NOT use tag when setTemplateRegistry is called. You should override template directly on this template registry then.
  • You CAN use tag when setTemplateRegistry is not called. In this case TemplateRegistry will be auto generate with id equal to tagged_service_id + .template_registry.

with MutableTemplateRegistryAwareInterface

  • You CAN use tag when setTemplateRegistry is called but it is not recommended.
  • You CAN use tag when setTemplateRegistry is not called. In this case MutableTemplateRegistry will be auto generate with id equal to tagged_service_id + .template_registry.

Examples

Sonata\AdminBundle\Tests\App\Admin\FooAdmin:
    arguments: [~, Sonata\AdminBundle\Tests\App\Model\Foo, ~]
    tags:
        - {name: sonata.admin, manager_type: test, label: Foo}
        - {name: sonata.admin.template_registry, template_name:'edit', template_path: '@FooAdmin/CRUD/edit.html.twig'}
        - {name: sonata.admin.template_registry, template_name:'list', template_path: '@FooAdmin/CRUD/list.html.twig'}

I am targeting this branch, because this change respect BC and should be done in 3.x.

Changelog

### Added
- Added `Sonata\AdminBundle\DependencyInjection\Compiler\TemplateRegistryCompilerPass` 

To do

  • Update the tests;
  • Update the documentation;
  • Update the documentation - new tags description;
  • Fix problem with order template override

@VincentLanglet
Copy link
Member

Sonata\AdminBundle\Tests\App\Admin\FooAdmin:
    arguments: [~, Sonata\AdminBundle\Tests\App\Model\Foo, ~]
    tags:
        - {name: sonata.admin, manager_type: test, label: Foo}
        - {name: sonata.template_registry, virtual_templates_method: 'my_custom_templates' }
        - {name: sonata.template_registry, virtual_templates_method: 'other_custom_templates' }
    calls:
        - my_custom_templates: [[
                show: '@@FooAdmin/CRUD/show.html.twig',
                edit: '@@FooAdmin/CRUD/show.html.edit'
            ]]
        - other_custom_template: [[edit: '@@FooAdmin/CRUD/other_show.html.edit']]

Since array are not allowed inside tags, WDYT about this solution ?

Sonata\AdminBundle\Tests\App\Admin\FooAdmin:
    arguments: [~, Sonata\AdminBundle\Tests\App\Model\Foo, ~]
    tags:
        - {name: sonata.admin, manager_type: test, label: Foo}
        - {name: sonata.template_registry, type: show, template:  '@@FooAdmin/CRUD/show.html.twig'}
        - {name: sonata.template_registry, type: edit, template:  '@@FooAdmin/CRUD/edit.html.twig'}

If this is confusing with

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

We maybe could have two tag, like sonata.template_registry and sonata.admin_template_registry

@wbloszyk
Copy link
Member Author

wbloszyk commented Nov 5, 2020

I think about type => template too.

IMO we should add sonata.template_registry_aware which will be create template registry not only for admin but for each aware interface implementing - also this by people. It is good solutions becouse we do not need this functionality in sonata.template_registry tag.

@VincentLanglet
Copy link
Member

I think about type => template too.

IMO we should add sonata.template_registry_aware which will be create template registry not only for admin but for each aware interface implementing - also this by people. It is good solutions becouse we do not need this functionality in sonata.template_registry tag.

Nice
Can you make a try with type/template and sonata.template_registry_aware ? 👍

@phansys
Copy link
Member

phansys commented Nov 6, 2020

I just have a consideration about the proposed service sonata.template_registry_aware, since this name does not accomplish with the standard.
IMO, it should be sonata_admin.template_registry_aware.
For the tags, I'd change sonata.template_registry with sonata_admin.template_registry.

@wbloszyk
Copy link
Member Author

wbloszyk commented Nov 6, 2020

I just have a consideration about the proposed service sonata.template_registry_aware, since this name does not accomplish with the standard.
IMO, it should be sonata_admin.template_registry_aware.
For the tags, I'd change sonata.template_registry with sonata_admin.template_registry.

Current we have tags like: sonata.admin, sonata.block, sonata.page. IMO we should add sonata.template_registry_aware and consider change all tags in sonata 4.

WDYT? @sonata-project/contributors

@VincentLanglet
Copy link
Member

I just have a consideration about the proposed service sonata.template_registry_aware, since this name does not accomplish with the standard.
IMO, it should be sonata_admin.template_registry_aware.
For the tags, I'd change sonata.template_registry with sonata_admin.template_registry.

Current we have tags like: sonata.admin, sonata.block, sonata.page. IMO we should add sonata.template_registry_aware and consider change all tags in sonata 4.

WDYT? @sonata-project/contributors

Indeed. Consistency is the key.

@phansys
Copy link
Member

phansys commented Nov 6, 2020

I think the tags prefixed with sonata.admin. are intended to be interpreted by SonataAdminBundle, the tags prefixed with sonata.block. are intended to be interpreted by SonataBlockBundle, and so.
I see no problem in using sonata.admin.template_registry as tag name for this case.
The main concern I think must be considered is about the service name.

IMO, it should be sonata_admin.template_registry_aware.

@VincentLanglet
Copy link
Member

I think the tags prefixed with sonata.admin. are intended to be interpreted by SonataAdminBundle, the tags prefixed with sonata.block. are intended to be interpreted by SonataBlockBundle, and so.
I see no problem in using sonata.admin.template_registry as tag name for this case.
The main concern I think must be considered is about the service name.

IMO, it should be sonata_admin.template_registry_aware.

Why not using sonata.admin.template_registry and sonata.admin.template_registry_aware then ?

@phansys
Copy link
Member

phansys commented Nov 6, 2020

I'm sorry. Didn't noticed before that our services are not following the standard.
I agree that currently, our main goal must be the consistency.

@wbloszyk wbloszyk changed the title Improve sonata.template_registry tag Template registry tags Nov 7, 2020
Copy link
Member

@VincentLanglet VincentLanglet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upgrade note / Doc updates will be required. But this seems a great solution.

@@ -102,6 +102,8 @@ protected function configureContainer(ContainerBuilder $containerBuilder, Loader
'strict_variables' => '%kernel.debug%',
'exception_controller' => null,
'form_themes' => ['@SonataAdmin/Form/form_admin_fields.html.twig'],
'paths' => ['%kernel.project_dir%/Resources/views'],

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this extra line

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WIP. I will probably need it in functional tests. Set templates must exists.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about the blank line

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😄

{
const TEMPLATE_REGISTRY_TAG = 'sonata.admin.template_registry';
const MUTABLE_TEMPLATE_REGISTRY_TAG = 'sonata.admin.template_registry';
const TEMPLATE_REGISTRY_AWARE_TAG = 'sonata.admin.template_registry_aware';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both tags sound very technical / related to the concrete implementation. Maybe just sonata.admin.template?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They look like related to the concreate implementation but thye have diffrence functionality too.
"Nonmutable" tags sets template by constructor argument.
"Mutable" tags set template by setTemplate method.
"Nonaware" tags are for mark template registry service.
"Aware" tags will auto generate template registry.

I will think about it.

@VincentLanglet
Copy link
Member

Hi @wbloszyk, what's missing to finish the PR ?
This is really a need currently since we've introduced deprecation for setTemplate method.

CC @sonata-project/contributors, any review is good to take.

@VincentLanglet VincentLanglet added this to the 4.0 milestone Nov 14, 2020
$templates = [];

foreach ($tags as $attributes) {
if (isset($attributes['type'], $attributes['template'])) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the name "type" for this option is too restrictive. Shouldn't this be "template_name"?
My concern is about scenarios where the passed template could be considered something more general than the "type" concept.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

template_name seems better indeed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sonata.admin.template_registry.template tag with name and value arguments.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't name reserved ?

I mean, you currently used

- {name: sonata.admin.mutable_template_registry_aware, type:'edit', template: '@@FooAdmin/CRUD/edit.html.twig'}

So how could we use name instead of type since name is already used ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad. template_name and template_value to be consider. I will finish it in friday evening or in saturday.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd use other name than template_value. Maybe template_path or just template.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

template_path will be the best.

$templateRegistryDefinition = $container->getDefinition($reference->__toString());

if (!is_a($templateRegistryDefinition->getClass(), $templateRegistryInterface, true)) {
throw new \Exception(sprintf(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this exception could use a less generic type (something like \InvalidArgumentException, \BadMethodCallException or similar.
I don't know if we have domain specific exceptions available under the Symfony\Component\DependencyInjection\ NS for cases like this.

@wbloszyk wbloszyk force-pushed the template_registry_tag_improve branch from fc8cda9 to d4324c2 Compare November 21, 2020 17:52
@kirya-dev
Copy link
Contributor

What do you think about make simplest template configuration?

@SonataCI
Copy link
Collaborator

Could you please rebase your PR and fix merge conflicts?

@VincentLanglet
Copy link
Member

@wbloszyk the changelog should be updated

@wbloszyk wbloszyk force-pushed the template_registry_tag_improve branch from 351717e to cff51fb Compare December 23, 2020 20:11
@SonataCI
Copy link
Collaborator

Could you please rebase your PR and fix merge conflicts?

@VincentLanglet
Copy link
Member

Is it ok for you now @phansys @core23 ? :)

@SonataCI
Copy link
Collaborator

SonataCI commented Jan 2, 2021

Could you please rebase your PR and fix merge conflicts?

Tags
======

sonata.admin.template_registry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand this doc.

In the first case you defined a app.admin.post.template_registry but you never use it.
If it's not well documented, it will never be used.

Instead of a technical documentation about the tag, it seems better to have a functional documentation about the feature related: how to override an admin template.

  • First case, directly in the configuration: thanks to the sonata.admin.template_registry tag.
  • Second case, with a re-usable template registry (and how to do this).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the first case you do not have to use template registry with admin. This service can be standalone registry. Service name is confusing, I will change it.

IMO template registry should be move to sonata-project/twig-extensions with this tags.rst file and documentation dedicated for override admin template should be add.

WDYT? @sonata-project/contributors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't understand how to use a template registry, so I cannot say if it's better in sonataAdmin or twigExtensions.

But currently, it's the only blocking point for Sonata 4.0.
So if we can't solve the situation, we should just un-deprecate setTemplate, remove templateRegistry and delay this feature to the next major.

arguments: [~, Sonata\AdminBundle\Tests\App\Model\Foo, ~]
tags:
- {name: sonata.admin, manager_type: test, label: Foo}
- {name: sonata.admin.template_registry, template_name:'edit', template_path: '@FooAdmin/CRUD/edit.html.twig'}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- {name: sonata.admin.template_registry, template_name:'edit', template_path: '@FooAdmin/CRUD/edit.html.twig'}
- {name: sonata.admin.template_registry, template_name: 'edit', template_path: '@FooAdmin/CRUD/edit.html.twig'}

tags:
- {name: sonata.admin, manager_type: test, label: Foo}
- {name: sonata.admin.template_registry, template_name:'edit', template_path: '@FooAdmin/CRUD/edit.html.twig'}
- {name: sonata.admin.template_registry, template_name:'list', template_path: '@FooAdmin/CRUD/list.html.twig'}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- {name: sonata.admin.template_registry, template_name:'list', template_path: '@FooAdmin/CRUD/list.html.twig'}
- {name: sonata.admin.template_registry, template_name: 'list', template_path: '@FooAdmin/CRUD/list.html.twig'}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In yaml need use double @

@wbloszyk
Copy link
Member Author

Close in favor of #6766

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants