Update docs in order to avoid calling deprecated methods `setTemplate()` and `setTemplates()` in `AbstractAdmin` #6538

phansys · 2020-10-24T12:45:51Z

Subject

Update docs about templates.

PR #6387 deprecates methods AbstractAdmin::setTemplate() and AbstractAdmin::setTemplates(), but the documentation still recommends to use them.
These calls were updated in order to use the template registry services.

I am targeting this branch, because these changes respect BC.

Related to #6387.

Changelog

### Fixed
- Deprecated calls to `AbstractAdmin::setTemplate()` and `AbstractAdmin::setTemplates()` in docs.

greg0ire · 2020-10-24T13:50:02Z

Documentation is not that different from code: it does deserve separate commits for grammar fixes and for other things. Also, it does deserve descriptive commit messages that explain what you are doing, not just which area of the docs you are working on. Typically, this should appear in your commit message:

deprecates methods AbstractAdmin::setTemplate() and AbstractAdmin::setTemplates(), but the documentation still recommends to use them.

phansys · 2020-10-24T14:23:44Z

The commit and the PR description were updated. Please, let me know if it accomplish your expectations.

docs/cookbook/recipe_row_templates.rst

docs/cookbook/recipe_customizing_a_mosaic_list.rst

docs/cookbook/recipe_row_templates.rst

docs/reference/templates.rst

greg0ire · 2020-10-24T15:10:01Z

docs/reference/templates.rst

+is available through ``$this->getTemplateRegistry()`` within the ``Admin``.
+Using the service container the template registries can be accessed outside an ``Admin``.
+Use the ``Admin`` code + ``.template_registry`` as the service ID (i.e.
+"app.admin.post" uses the template registry "app.admin.post.template_registry").


I'd use code markup here, but it's funny, that's the second time I have this discussion today, so don't hesitate to tell me if you feel strongly otherwise.

Suggested change

"app.admin.post" uses the template registry "app.admin.post.template_registry").

``app.admin.post`` uses the template registry ``app.admin.post.template_registry``).

I think there is no established rule for the case where we need to refer to service names, parameter names, package names, etc. (since they are names, sometimes it feels natural to use double quotes and treat them a literal strings).
Personally, I try to be consistent with this, but in some cases it depends on the context, I think.
In the same reasoning, I try to use backticks when referencing code snippets (with partial or complete fragments, IE AdminInterface::id()).

FYI the discussion I linked resolved in using backticks (there was no debate, we needed both backticks and quotes). I tend to use backticks for everything. So to me you can write "admin class", you can also write Admin class, but you can't write Admin class, because now you are using a technical name as it appears in the code, and names that appear in code may contain special characters that have meaning in markdown like underscores or stars, but also in normal language, for example dots. When you use backticks, a monospace font will be used, and the reader knows you are talking about something that will appear in the code, and not approximately referring to something using a high level term like "unit of work" or "repository interface".

…()` and `setTemplates()` in `AbstractAdmin` PR sonata-project#6387 deprecates methods `AbstractAdmin::setTemplate()` and `AbstractAdmin::setTemplates()`, but the documentation still recommends to use them. These calls were updated in order to use the template registry services.

phansys · 2020-10-30T17:51:04Z

I am trying to test this change locally and I cannot make it work as I supposed.
@wbloszyk, could you please take a look in order to confirm?

wbloszyk · 2020-10-30T18:30:59Z

I busy today. I have to finish some of my commercial works. I will try to find some time for it tomorrow. IMO it is problem with template registry which is created by compiler pass and do not exist when config is loaded.

phansys · 2020-10-30T18:57:59Z

I agree with that suspicion.
Thank you.

wbloszyk · 2020-10-30T19:13:00Z

My idea is create one, global admin template registry and force people to create own (by override default) if they want override templates.

<service id="sonata.media.admin.media.template_registry">
    <tag name="sonata.teplate_registry"/>
    <call method="setTemplates">
       ...
    </call>
</service>
<service id="sonata.media.admin.media">
    <tag name="sonata.admiun"/>
    <call method="setTemplateRegistry">
       <argument type="service" id="sonata.media.admin.media.template_registry"> 
    </call>
</service>

Im feature will be nice to add multiple registry for one admin. Support for role, destiny (chooseable show as table or thumbnail etc.)

phansys · 2020-10-30T20:33:47Z

I understand. But I also think that we shouldn't deprecate AbstractAdmin::setTemplate() in favor of this approach, if isn't working yet.

jordisala1991 · 2020-10-30T20:42:03Z

I understand. But I also think that we shouldn't deprecate AbstractAdmin::setTemplate() in favor of this approach, if isn't working yet.

Agree with that, IMO we should undeprecate this until a fully working solution can be provided, and only if it is better than simply calling setTemplate

wbloszyk · 2020-10-30T20:46:08Z

I will try do it tomorrow.

wbloszyk · 2020-10-30T20:46:36Z

Miss click 😆

wbloszyk · 2020-10-31T18:23:54Z

@phansys
I found resolve for it.
At first global template registry should be non changeable:
#6556

At second:
MutableTemplateRegistry should have parent property. (for global settings)

At third:
User will be able to create MutableTemplateRegistry by own. Compiler pass will create or call setters then.

phansys · 2020-11-01T14:59:43Z

At third:
User will be able to create MutableTemplateRegistry by own. Compiler pass will create or call setters then.

Could you please share an example about the required DI configuration to customize an admin template?

IE:

BEFORE:

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

AFTER:

# ...

wbloszyk · 2020-11-01T16:49:17Z

Compiler pass will auto inject admin_code.template_registry to admin_code when setTemplateRegistry is not call. So user will be able to set it with custom name too. Set template will be able by arguments too. I want add parent template registry (to reference for global values) or add template manager.

BEFORE:

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

AFTER:

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

phansys · 2020-11-01T19:15:51Z

Currently, the custom definition of admin.foo.template_registry is being overridden by the default definition. What do you suggest to fix that?
I insist that, if we aren't able to provide a working solution with this approach, we MUST undeprecate the previous one #6538 (comment), #6538 (comment).

wbloszyk · 2020-11-01T21:41:53Z

@phansys IMO this should resolve problem with config. Can you check it? #6561

VincentLanglet · 2020-11-01T23:09:24Z

It seems that we are discussing 2 different things here.
IMO, we must focus on fix the current situation: we've deprecated an existing feature indicating that other approach must be followed, and that approach isn't working. So, we must undeprecate the previous working feature.
When that issue is solved, we can invest our effort in providing the new feature in a proper way (adding the required tests to ensure it is working, this time).

Could you please confirm that's how you've set your priorities about this?

After reading all this discussion, I just feel like this feature is not ready and was maybe not discuss enough.
IMHO this should not be in the next major (which we try to release ASAP).

This PR:

Fix TemplateRegistry usages #6387
seems to be the first of many
Make TemplateRegistry not mutable #6556
Add trigger_error and fix some comments #6393
Remove admin and templateRegistry CRUDController properties #6467

IMHO, we should just revert it and delay these changes for 5.0 if it's not ready and fully working.

Plus now I (maybe) start to understand it, I don't see the interest in this feature.
The change

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

to

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry']

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

does not seem a good thing to me.

Setting a templating is actually so easy that it doesn't need a service for this.

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry']

admin.foo_bar:
   class: App\FooBarAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry']

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

Can just be done this way

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]  
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

admin.foo_bar:
   class: App\FooBarAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]  
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

and I find this simpler.

Personally when I override show/edit template, it's alway for one single Admin. Asking me to create a service everytime I need to override a template would be counter productive. Did I missunderstood something @wbloszyk @phansys ?

Maybe both way should co-exist:

if you want to override template for one admin: use setTemplate
if you want to override template for multiple admin: use service

phansys · 2020-11-02T00:43:26Z

@phansys IMO this should resolve problem with config. Can you check it? #6561

I can confirm it isn't working. You could check locally by introspecting the compiled debug container in your environment (var/cache/{env}/Kernel{env}DebugContainer.xml) and searching for admin.product.template_registry.

Personally when I override show/edit template, it's alway for one single Admin. Asking me to create a service everytime I need to override a template would be counter productive. Did I missunderstood something @wbloszyk @phansys ?

I understand exactly the same. Please, note that I've created this PR by guessing what was done at #6387, but I'm not have certainty about the required steps to replace the deprecated feature.
I agree that AbstractAdmin::setTemplate() seems much more simpler than the approach introduced in that PR.

wbloszyk · 2020-11-02T08:10:20Z

#6556 should in 3.x. Other step in master or in 4.x.

IMO keep this methods is bad decision. Templates should be manage by templates registry. But we can keep calling setters by catching this args, inject it by argument and remove and remove calling in compiler pass.

WDYT?

VincentLanglet · 2020-11-02T11:00:00Z

IMO keep this methods is bad decision. Templates should be manage by templates registry.

Why should it be ?
Creating a service to change the templates of multiple admins is not a bad idea.
But creating a service for changing one template seems over-engineered.

But we can keep calling setters by catching this args, inject it by argument and remove and remove calling in compiler pass.

I'm not sure to fully understand. Do you want to auto-generate a templateRegistry if we provide setTemplate ?

Can you provide a way to have both this config

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry']

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

and this config

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]  
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

working ?

VincentLanglet · 2020-11-02T11:04:22Z

I just thought about a special case

admin.foo1:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]  
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

admin.foo2:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

admin.foo3:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]

With template registry, you need to create 3 services because admin.foo1 can't set multiple templateRegistry.
Wouldn't it be better to use a collection of templateRegistry ?

admin.foo1:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [addTemplateRegistry, '@admin.foo.template_registry2']
       - [addTemplateRegistry, '@admin.foo.template_registry3']

admin.foo2:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [addTemplateRegistry, '@admin.foo.template_registry2']

admin.foo3:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [addTemplateRegistry, '@admin.foo.template_registry3']

phansys · 2020-11-02T12:14:51Z

None of the proposed solutions (#6556, #6561) fix the issue, so until it is resolved, I must rollback the latest release I made in one of my projects, and declare a conflict against sonata-project/admin-bundle:>=3.76.0.

wbloszyk · 2020-11-02T12:15:33Z

IMO keep this methods is bad decision. Templates should be manage by templates registry.

Why should it be ?
Creating a service to change the templates of multiple admins is not a bad idea.

IMO keep AbstractAdmin::setTemlate(s) is bad idea. Templates should be manage by template registry. This will keep model more clear.

But creating a service for changing one template seems over-engineered.

Agree. That why we should keep setTemplate(s) only in config. Compiler pass will delete calls for them and move call templates to TemplateRegistry argument. (hack)

But we can keep calling setters by catching this args, inject it by argument and remove and remove calling in compiler pass.

I'm not sure to fully understand. Do you want to auto-generate a templateRegistry if we provide setTemplate ?

TemplateRegistry can be create by user or will be auto-generated. In both way templates from setTemplate(s) will override TemplateRegistry argument.

Can you provide a way to have both this config

I can provide something like this:

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry'] # optional
       - [setTemplate, ['edit', 'admin/bar/edit.html.twig']] # this template will override templates from template registry

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

Update for @VincentLanglet
I want add addTemplateRegistry to allow use multiple registry in 5.0 milestone.

wbloszyk · 2020-11-02T12:17:10Z

None of the proposed solutions (#6556, #6561) fix the issue, so until it is resolved, I must rollback the latest release I made in one of my projects, and declare a conflict against sonata-project/admin-bundle:>=3.76.0.

@phansys I can fix in the evening if you agree with #6538 (comment)

phansys · 2020-11-02T12:30:20Z

@phansys I can fix in the evening if you agree with #6538 (comment)

I agree that it could be a working solution, but I'm in doubt since the template registry approach was not working in any of the related PRs yet.
Regarding the hack of removing the call to setTemplate() and setTemplates() in the admin service definition and passing them to the template registry service, I think we should chose a different name for these methods in the service calls to avoid confusions and make the situation a little bit clear. Maybe something like registerTemplate() or something that isn't a real method name in the admin class.

VincentLanglet · 2020-11-02T12:42:51Z

But creating a service for changing one template seems over-engineered.

Agree. That why we should keep setTemplate(s) only in config. Compiler pass will delete calls for them and move call templates to TemplateRegistry argument. (hack)

Not sure if this hack will be natural for developer who won't understand why adding a setTemplate is allowed in calls when there is no setTemplate method in the AbstractAdmin class.

Regarding the hack of removing the call to setTemplate() and setTemplates() in the admin service definition and passing them to the template registry service, I think we should chose a different name for these methods in the service calls to avoid confusions and make the situation a little bit clear. Maybe something like registerTemplate() or something that isn't a real method name in the admin class.

I agree. Best would be a templates key in the config, but I assume it's not possible ?

Can you provide a way to have both this config

I can provide something like this:

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplateRegistry, '@admin.foo.template_registry'] # optional
       - [setTemplate, ['edit', 'admin/bar/edit.html.twig']] # this template will override templates from template registry

admin.foo.template_registry:
   class: Sonata\AdminBundle\Templating\MutableTemplatingRegistry # IMO this can be set by tag, then class will be optional
   tags: 
       - [name: "sonata.template_registry"]
   calls:
       - [setTemplate, ['show', 'admin/foo/show.html.twig']]
       - [setTemplate, ['edit', 'admin/foo/edit.html.twig']]

Seems great

Update for @VincentLanglet
I want add addTemplateRegistry to allow use multiple registry in 5.0 milestone.

Ok.

phansys · 2020-11-02T12:58:26Z

I agree. Best would be a templates key in the config, but I assume it's not possible ?

Maybe we could transmit the "magic" concept by using __templates as method name.

wbloszyk · 2020-11-02T13:09:51Z

I agree. Best would be a templates key in the config, but I assume it's not possible ?

Maybe we could transmit the "magic" concept by using __templates as method name.

🤔

I found the best solution:
https://symfony.com/doc/current/service_container/tags.html#adding-additional-attributes-on-tags

We can use additional templates atributes on sonata.template_registry tag.

VincentLanglet · 2020-11-02T13:16:19Z

We can use additional templates atributes on sonata.template_registry tag.

Can you give an example of the config you have in mind @wbloszyk ?

If it's on sonata.template_registry I'm not sure it resolve our concern about the AbstractAdmin::setTemplate method

admin.foo:
   class: App\FooAdmin
   arguments: [null, App\Entity\Foo, null]
   calls:
       - [setTemplate, ['edit', 'admin/bar/edit.html.twig']]

wbloszyk · 2020-11-02T13:23:05Z

We can use additional templates atributes on sonata.template_registry tag.

Can you give an example of the config you have in mind @wbloszyk ?

If it's on sonata.template_registry I'm not sure it resolve our concern about the AbstractAdmin::setTemplate method

admin.foo:
    class: App\FooAdmin
        tags: 
            - [name: "sonata.template_registry", templates: ['edit': 'admin/bar/edit.html.twig', 'show': 'admin/bar/show.html.twig'] ]
        arguments: [null, App\Entity\Foo, null]

Of course in 3.x AbstractAdmin::templates property are used. In this case we have to set it by AbstractAdmin (in CompillerPass).

VincentLanglet · 2020-11-02T13:27:01Z

admin.foo:
    class: App\FooAdmin
        tags: 
            - [name: "sonata.template_registry", templates: ['edit': 'admin/bar/edit.html.twig', 'show': 'admin/bar/show.html.twig'] ]
        arguments: [null, App\Entity\Foo, null]

Seems great.
Could you implement this @wbloszyk ?

With this, I think we don't have to revert the deprecation @phansys.

phansys · 2020-11-02T13:30:51Z

With this, I think we don't have to revert the deprecation @phansys.

Agreed.

wbloszyk · 2020-11-02T13:35:17Z

Seems great.
Could you implement this @wbloszyk ?

I will try to do it today.

Additional this will add the same functionality to MutableTemplateRegistryAwereInterface.

wbloszyk · 2020-11-04T20:31:30Z

Some update: #6566

tag attribute can not be array, I used virtual_template_method instead
I have some problem with current AddDependencyCallsCompilerPass:fixTemplates() but I found solution

Thursday is family day. I will finish it in Friday.

kirya-dev · 2020-11-14T22:55:18Z

admin.foo:
    class: App\FooAdmin
        tags: 
            - [name: "sonata.template_registry", templates: ['edit': 'admin/bar/edit.html.twig', 'show': 'admin/bar/show.html.twig'] ]
        arguments: [null, App\Entity\Foo, null]

Seems great.

Could you implement this @wbloszyk ?

Me seams that its too complex to programming.
Configuring sonata admin job for very hard programmers?

kirya-dev · 2020-11-14T23:04:20Z

What about configure templates in php code?

In FooBarAdmin::configure make something: (see symfony 5 way - zero yml configuration for new services)

<?php
declare(strict_types=1);

namespace App\Admin;

use App\Entity\FooBar;

class FooBarAdmin extends AbstractAdmin
{
    public function __construct()
    {
        parent::__construct('foo-bar', FooBar::class);
    }

    public function configure(): void
    {
        $this->getTemplateRegistry()->setTemplates([
            'list' => '@FooBar/list.html.twig',
        ]);
    }
}

VincentLanglet · 2020-11-15T20:28:44Z

What about configure templates in php code?

In FooBarAdmin::configure make something: (see symfony 5 way - zero yml configuration for new services)

<?php
declare(strict_types=1);

namespace App\Admin;

use App\Entity\FooBar;

class FooBarAdmin extends AbstractAdmin
{
    public function __construct()
    {
        parent::__construct('foo-bar', FooBar::class);
    }

    public function configure(): void
    {
        $this->getTemplateRegistry()->setTemplates([
            'list' => '@FooBar/list.html.twig',
        ]);
    }
}

You can do it with configure indeed. But it's not bad to allow user to use yaml too.
Everybody will use his prefer way.

kirya-dev · 2020-11-16T07:43:07Z

What about configure templates in php code?
In FooBarAdmin::configure make something: (see symfony 5 way - zero yml configuration for new services)
<?php
declare(strict_types=1);

namespace App\Admin;

use App\Entity\FooBar;

class FooBarAdmin extends AbstractAdmin
{
    public function __construct()
    {
        parent::__construct('foo-bar', FooBar::class);
    }

    public function configure(): void
    {
        $this->getTemplateRegistry()->setTemplates([
            'list' => '@FooBar/list.html.twig',
        ]);
    }
}
You can do it with configure indeed. But it's not bad to allow user to use yaml too.
Everybody will use his prefer way.

Its possible add my example to documentation?

kirya-dev · 2020-11-17T12:49:32Z

Whyt ?

    protected function configureTemplateRegistry(MutableTemplateRegistryInterface $registry): void
    {
        $registry->setTemplate('edit', '@FooBar/FooBarAdmin/edit.html.twig');
    }

kirya-dev · 2020-11-17T13:31:00Z

Also found problem: When call setTemplates() this fully discard previous (global) templates

VincentLanglet · 2020-11-17T13:35:25Z

There is no real need to discuss about this PR before #6566

phansys · 2020-12-02T14:51:30Z

@wbloszyk, could I close this PR in favor of #6566? I think you can add the required documentation there.

phansys added the docs label Oct 24, 2020

phansys requested a review from a team October 24, 2020 12:45

phansys marked this pull request as ready for review October 24, 2020 12:48

phansys force-pushed the pr_6387 branch from d03a0bb to ae95461 Compare October 24, 2020 14:18

phansys changed the title ~~Update docs about templates~~ Update docs in order to avoid calling deprecated methods setTemplate() and setTemplates() in AbstractAdmin Oct 24, 2020

phansys requested a review from greg0ire October 24, 2020 14:22

greg0ire reviewed Oct 24, 2020

View reviewed changes

phansys added 2 commits October 24, 2020 13:44

Small grammar fixes in docs

f01517c

phansys force-pushed the pr_6387 branch from ae95461 to f01517c Compare October 24, 2020 16:47

phansys requested review from greg0ire and a team October 24, 2020 16:49

VincentLanglet approved these changes Oct 24, 2020

View reviewed changes

phansys requested a review from a team October 25, 2020 06:18

wbloszyk closed this Oct 30, 2020

wbloszyk reopened this Oct 30, 2020

VincentLanglet added this to the 4.0 milestone Nov 2, 2020

VincentLanglet closed this Dec 4, 2020

phansys deleted the pr_6387 branch December 4, 2020 20:13

	"app.admin.post" uses the template registry "app.admin.post.template_registry").
	``app.admin.post`` uses the template registry ``app.admin.post.template_registry``).

Update docs in order to avoid calling deprecated methods setTemplate() and setTemplates() in AbstractAdmin #6538

Update docs in order to avoid calling deprecated methods setTemplate() and setTemplates() in AbstractAdmin #6538

Conversation

phansys commented Oct 24, 2020 • edited Loading

Subject

Changelog

greg0ire commented Oct 24, 2020

phansys commented Oct 24, 2020

greg0ire Oct 24, 2020 • edited Loading

Choose a reason for hiding this comment

phansys Oct 24, 2020

Choose a reason for hiding this comment

greg0ire Oct 24, 2020

Choose a reason for hiding this comment

phansys commented Oct 30, 2020

wbloszyk commented Oct 30, 2020

phansys commented Oct 30, 2020

wbloszyk commented Oct 30, 2020

phansys commented Oct 30, 2020

jordisala1991 commented Oct 30, 2020

wbloszyk commented Oct 30, 2020

wbloszyk commented Oct 30, 2020

wbloszyk commented Oct 31, 2020

phansys commented Nov 1, 2020

wbloszyk commented Nov 1, 2020

phansys commented Nov 1, 2020

wbloszyk commented Nov 1, 2020 • edited Loading

VincentLanglet commented Nov 1, 2020

phansys commented Nov 2, 2020

wbloszyk commented Nov 2, 2020

VincentLanglet commented Nov 2, 2020

VincentLanglet commented Nov 2, 2020

phansys commented Nov 2, 2020

wbloszyk commented Nov 2, 2020 • edited Loading

wbloszyk commented Nov 2, 2020

phansys commented Nov 2, 2020

VincentLanglet commented Nov 2, 2020

phansys commented Nov 2, 2020

wbloszyk commented Nov 2, 2020

VincentLanglet commented Nov 2, 2020

wbloszyk commented Nov 2, 2020 • edited Loading

VincentLanglet commented Nov 2, 2020

phansys commented Nov 2, 2020

wbloszyk commented Nov 2, 2020

wbloszyk commented Nov 4, 2020

kirya-dev commented Nov 14, 2020 • edited Loading

kirya-dev commented Nov 14, 2020 • edited Loading

VincentLanglet commented Nov 15, 2020

kirya-dev commented Nov 16, 2020

kirya-dev commented Nov 17, 2020 • edited Loading

kirya-dev commented Nov 17, 2020

VincentLanglet commented Nov 17, 2020

phansys commented Dec 2, 2020

Update docs in order to avoid calling deprecated methods `setTemplate()` and `setTemplates()` in `AbstractAdmin` #6538

Update docs in order to avoid calling deprecated methods `setTemplate()` and `setTemplates()` in `AbstractAdmin` #6538

phansys commented Oct 24, 2020 •

edited

Loading

greg0ire Oct 24, 2020 •

edited

Loading

wbloszyk commented Nov 1, 2020 •

edited

Loading

wbloszyk commented Nov 2, 2020 •

edited

Loading

wbloszyk commented Nov 2, 2020 •

edited

Loading

kirya-dev commented Nov 14, 2020 •

edited

Loading

kirya-dev commented Nov 14, 2020 •

edited

Loading

kirya-dev commented Nov 17, 2020 •

edited

Loading