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

See https://github.com/extdn/extdn-phpcs/issues/49 #51

Merged
merged 4 commits into from
Jul 30, 2018

Conversation

jissereitsma
Copy link
Contributor

#49

return [
[
'class' => 'Magento\Backend\Block\Widget\Form\Generic',
'advice' => 'Refactor this to a UiComponent.'
Copy link

@ihor-sviziev ihor-sviziev Jul 16, 2018

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?

Copy link
Collaborator

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?

Copy link
Contributor Author

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';
Copy link
Collaborator

Choose a reason for hiding this comment

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

yes, but.. no 😁

Copy link
Contributor Author

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();
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

@jissereitsma
Copy link
Contributor Author

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 MagentoUtils::getMagentoVersion() could be used to return the current version. When the result is a string (or similar), there could be a check to see if Magento 2.1 or older is used, and then the rule logic is ignored. When the result is null, the rule could be applied anyway.

@schmengler schmengler merged commit e287f41 into extdn:master Jul 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants