Closed rfaivre closed 4 years ago
What's your use case for admin class without entity ?
The documentation ask for a model: https://sonata-project.org/bundles/admin/master/doc/getting_started/creating_an_admin.html
And we're currently throwing a deprecation if you pass a null
class.
if (!\is_string($class)) {
@trigger_error(sprintf(
'Passing other type than string as argument 2 for method %s() is deprecated since'
.' sonata-project/admin-bundle 3.65. It will accept only string in version 4.0.',
__METHOD__
), E_USER_DEPRECATED);
}
Plus, the AdminInterface::getClass()
have to return a string.
I'm surprised everything works for you cause this function is used almost 100 times in the project, and every methods are using the result as a string
.
If you want to support admin without class you'll need
null
(or cast to ''
) and some phpdoc update too.Read this part of the documentation: https://sonata-project.org/bundles/admin/master/doc/cookbook/recipe_custom_view.html As mentioned in the documentation, providing an entity class is not mandatory for an admin.
There is a lot of use cases. For example, create a specific view to display stats, amongst others, and add it to the sidebar with the rest of my admin pages This page is not related to a specific entity and the logic is specific and I never had a problem with that
Hum, ok. Then how will be managed admin without entity in version 4.0? If providing an entity is mandatory.
BTW, @trigger_error
does not throw an exception, but only a deprecation message.
But my problem is not here. As explained above, I created an extension and I want this to be added to all my entities implementing a specific class.
In the ExtensionCompilerPass
file, it loops on every admin and according to the configuration defined in sonata_admin.yaml
(https://symfony.com/doc/master/bundles/SonataAdminBundle/reference/extensions.html) add the extension to the entity if it matches.
My problem is only related to add an extension to a specific entity and I have some admin without entity.
Of course, I have a workaround (but I find it's not very reusable), if my PR is rejected by adding my extension like that:
app.example.extension:
class: App\Admin\Extension\ExampleExtension
tags:
- { name: sonata.admin.extension, target: admin.product }
- { name: sonata.admin.extension, target: admin.question }
But with this fix, you can use your configuration centralized in the sonata_admin.yaml
sonata_admin:
extensions:
app.example.extension:
implements:
- App\Interface\ExampleInterface
With my entities implementing App\Interface\ExampleInterface
and that's all.
It's more reusable, and if I want to use the extension for another entity, I just have to implement this interface and everything is done.
The current development works well if you don't have a specific custom view without entity.
Look at my PR maybe it's more clear ;)
BTW,
@trigger_error
does not throw an exception, but only a deprecation message.
I know, we're adding deprecation to be BC. But it means, it will throw an exception in next major.
Hum, ok. Then how will be managed admin without entity in version 4.0? If providing an entity is mandatory.
Looks like admin without entity won't be supported.
Even if there is a documentation, the phpdoc was asking for an entity:
https://github.com/sonata-project/SonataAdminBundle/blob/3.x/src/Admin/AbstractAdmin.php#L594
Then, every methods using AdminInterface::getClass()
as argument were expecting a @param string $class
.
And exception are like "something about instance $class"
.
This either doesn't works, either make no sens for null
/''
.
I also found some comment
/* NEXT_MAJOR: remove cast to string, null is not supposed to be supported but was documented as such */
And for example, how do you want this code to work with a null
entity ?
public function getNewInstance()
{
$object = $this->getModelManager()->getModelInstance($this->getClass());
$this->appendParentObject($object);
foreach ($this->getExtensions() as $extension) {
$extension->alterNewInstance($this, $object);
}
return $object;
}
IMHO, even with the documentation, I still have trouble to understand the goal of an admin without entity.
An admin is made to list entities, show an entity, edit an entity or create one.
If you want a custom view, I will recommend to create a custom route and extends the admin_layout
.
Maybe it worked for you, since you were using only a few of Sonata features, but you're already discovering that it doesn't work with everything (Like your bug with admin extension). Your PR is theorically correct, if we want to support admin without entity. But the phpdoc of the Sonata code is not really promoting this... And they're will be a lot of bug with this feature since the developer won't care about the possibly null
value, since it's not documented in the code.
If we want to support admin without entity, we'll need to start to update all the phpdoc of the project from string
to string|null
and then to update a lot of code too. But currently I'm really sorry, but I don't see much interest in this.
@sonata-project/contributors If you agree with me, I think this documentation should be removed.
@rfaivre If you think I'm wrong, I'll be happy to hear how/why.
I understand your point of view. Because working with an admin without entity doesn't use all the power and possibility of an admin, and his main goal is to work with entity. I'm ok with this.
And according to documentation, passing null
seems to be not supported any more in the next versions.
But in my case, I want to use an admin without an entity to keep some features added by an admin like adding it to the sidebar with the rest of my admin page, amongst others features.
And about your proposed solution to create a custom view by extending the admin_layout
, why not. But it's not only for rendering, there is some logic behind not related to only one entity.
So then if sonata contributors agree with you, we can cancel the pull request without a problem. But of course, documentation needs to be updated ;)
And according to documentation, passing
null
seems to be not supported any more in the next versions.
Indeed.
But I can also find some (string) $this->getClass()
as if someone wanted to fix the case where the function wasn't returning a string
value, this is weird.
But in my case, I want to use an admin without an entity to keep some features added by an admin like adding it to the sidebar with the rest of my admin page, amongst others features.
Adding it to the sidebar can be done without creating an admin.
sonata_admin:
dashboard:
groups:
my_group:
items:
- route: my_custom_route
label: my_custom_label
roles: [ ROLE_SOMETHING ]
icon: '<i class="fa fa-foo" aria-hidden="true"></i>'
Can you list the others feature you need ?
And about your proposed solution to create a custom view by extending the
admin_layout
, why not. But it's not only for rendering, there is some logic behind not related to only one entity.
Again, can you list the logic/feature needed ?
Maybe it's already implemented or can be implemented in another/better way :)
Indeed, no need to have an admin in my case.
Can you list the others feature you need?
I use some features of admin but it can be done without using an admin.
Then I use some configuration in sonata_admin.yaml
like you have mentioned and it works well. Thanks for the tip ;)
Thanks for your help @VincentLanglet ;) I think we can close this ticket and cancel the PR
Environment
Symfony 4.4.8 with php 7.2
Sonata packages
SonataAdminBundle: 3.66
Symfony packages
PHP version
Subject
I created many admin classes with and without entity in my project. Until then, no worries, it works well. I want to create an extension and use the configuration in
sonata_admin.yaml
with, for example,implements
as mentioned in the documentation Like that, my extension will be added to every admin with the entity implementing this interface filled out in the configuration.But in the extensionCompilerPass, when it loops on every admin class with tags
sonata.admin
, and check if there are some extensions for admin ingetExtensionsForAdmin
functions,getManagedClass
return null for my admin without an entity (it's correct), but passing null toclass_exists
provokes an errorThe proposed fixed below is straightforward: Add a check if the return is not null in addition to check if the class exists.
Let me know if I'm right or if I forgot a part in documentation ;)
Then I will provide a pull request if the bug is confirmed ;)