Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Deprecate some AbstractAdmin methods #6885
Deprecate some AbstractAdmin methods #6885
Changes from all commits
aac9099
a28aab1
21a75ed
762ccdd
340fa08
c533ae0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to remove this one?
IMO looks better to use a method to check this rather than substitute this call with
null !== $object && $this->hasAccess('x', $object)
everywhere.There is also this check inside the
canAccessObject
method:if (!$this->id($object)) { }
, that I don't know if can be removed.EDIT: Looking at the calls, I think we can even add in that method a check for
$this->hasRoute('route')
to make thoseif
smaller.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
access
notion in both theAccessRegistryInterface
and theAdminInterface
hasAccess('edit', $object)
andcanAccessObject('edit', $object)
). How to know which one I should use ? If you look at the code, sometimes we were using one, sometimes the second one, this is really confusing.Maybe deprecating this method is not the right thing to do.
AccessRegistryInterface::hasAccess($action, $object)
toAccessRegistryInterface::hasAccess($action)
? This way it's clear, if you're concerned about the action access, use hasAccess ; if you're concerned about the object, use canAccessObject.canAccessObject
method ?And we could also move the
canAccessObject
method to theAccessRegistryInterface
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I take a new look at the code.
Firstly, the check
$this->id($object)
is needed.Secondly, when you look at the following code
Nothing can guarantee that
canAccessObject
, and thengenerateObjectUrl
will give a TypeError.canAccessObject
andgenerateObjectUrl
are related. There are in different interfaces.So I still think it's better to deprecate canAccessObject and using explicit checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I don't understand the reasoning behind removing a meaningful method name in favor of explicit checks:
vs:
Every time there is a call to
canAccessObject
, there is also ahasRoute
call, so I guess that method (don't know ifcanAccessObject
or other) could also check that.IMHO (for the sake of maintainability) it is better to have a method as a concept that the developer can understand when looking at it rather than several checks.
I think this is different, in this case if there is a call to
generateObjectUrl
that needs an object, makes sense to check if that exists.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not always calling
$this->canAccessObject
, you're often calling$admin->canAccessObject
, so you're calling this in theAdminInterface
, not theAbstractAdmin
. You don't know how the developer will implement this method.I should be allowed to have this implementation:
Does the SonataAdmin code still works with this implementation ? No. We rely on a specific implementation. So this method shouldn't be in the interface. It could be in a service, but since we're not using it a lot, using specific checks seems enough to me.
Still, If you do this, you'll rely on a specific implementation of
canAccessObject
which is against the purpose of an interface.If a method should exist, it would be
canGenerateObjectUrl
and be in theUrlGeneratorInterface
.With the implementation I gave you, the twig template is giving a TypeError.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is precisely what I meant with my previous comment, in case we need to check that object is not null (because there is call that needs that object), make sense to add that extra check (
admin.whatever and object != null
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I misunderstood that part. But the rest of my message is still valid.
We're relying on the implementation of
canAccessObject
when it's not even in the same interface.For a
list
, we're doinghasRoute
andhasAccess
.If for a
show
, you're doinghasRoute
andcanAccessObject
or worst, just doingcanAccessObject
it won't be consistent with thelist
, it could lead to weird behavior if I override thecanAccessObject
method.That's why I think it's better to keep the checks we need instead of hiding them inside a method which is in the public API. Given that fact, only the
$this->id($object) !== null
is useful to keep inside this method. Does it worth a method ? I'm not sure about this.If you look more at it, you can even see that the
$this->id($object) !== null
check is wrong. SincegenerateObjectUrl
is relying ongetUrlSafeIdentifier
.If we want to keep abstraction, the only method to provide would be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Friendly ping @franmomu @sonata-project/contributors WDYT ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we add a
@deprecated
annotation, just in case the users are overriding this method without callingparent
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about
buildShow()
?