-
Notifications
You must be signed in to change notification settings - Fork 10
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
See https://github.com/extdn/extdn-phpcs/issues/49 #51
See https://github.com/extdn/extdn-phpcs/issues/49 #51
Conversation
return [ | ||
[ | ||
'class' => 'Magento\Backend\Block\Widget\Form\Generic', | ||
'advice' => 'Refactor this to a UiComponent.' |
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 think it will not be clear for people who just started working with magento. I think it's better to add there any link to
explanation "why?" with example how to refactor it. Maybe it will be a good idea to update issue description with this info and add link to it?
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.
We use a standardized URL to document sniffs in the repo (it would be Extdn/Sniffs/Blocks/DeprecatedParentsSniff.md
, but is missing from this PR)
But good question: shouldn't we show this URL in the messages?
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.
Doc has now been added: jissereitsma@f831df3 And the rule warning now refers to the actual URL (which is not there yet): jissereitsma@078417c
/** | ||
* @var string | ||
*/ | ||
protected $message = 'The ObjectManager should not be injected into the constructor'; |
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.
yes, but.. no 😁
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.
No, but now yes: jissereitsma@6cf3243
include_once($phpcsFile->getFilename()); | ||
|
||
$class = Reflection::getClass($className); | ||
$parentClass = $class->getParentClass(); |
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.
does reflection with the parent class work if it is not present?
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.
Yes, in my case it did. The benefit here is that you don't need to parse the use
statement and class X extends Y implements Z
construct. So no dependency with Magento.
In the Reflection utilities that I've used here, I've added exception handling so that when Magento is not present (or something else fails) the rule can be bypassed: https://github.com/extdn/extdn-phpcs/blob/master/Extdn/Utils/Reflection.php#L35 So, the rules that depend on this Reflection could work (report stuff) when Magento is present, but they will also work (but not report stuff) when Magento is not there. Kind of makes sense to me personally.
An entirely different point: This rule expects the code to be compliant with Magento 2.2 (hence the classes are deprecated, while under M2.1 they wouldn't be). But it would be much nicer if there is code in the rule itself to see whether this is the case. Using Reflection, this could be made possible. When the Magento code is present, for example a call |
#49