Navigation Menu

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

Fix error when generating urn catalog for empty misc.xml #11686

Merged

Conversation

tdgroot
Copy link
Member

@tdgroot tdgroot commented Oct 24, 2017

Fix error when generating urn catalog for empty misc.xml

Description

Fix error when generating urn catalog for existing empty misc.xml. I fixed this by creating another DomDocumentFactory, for PhpStorm specific misc.xml. This factory checks if the passed data is empty, and if so, create the misc.xml xml structure that \Magento\Developer\Model\XmlCatalog\Format\PhpStorm expects.

I also changed \Magento\Framework\DomDocument\DomDocumentFactory to follow the Magento 2 guidelines and added a Test class for this factory to define the behavior.

Fixed Issues (if relevant)

  1. Error generating URN-catalog when blank one exists #5188

Manual testing scenarios

  1. rm .idea/misc..xml
  2. touch .idea/misc.xml
  3. bin/magento dev:urn-catalog:generate .idea/misc.xml

Contribution checklist

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

@tdgroot
Copy link
Member Author

tdgroot commented Oct 25, 2017

Codacy is not successful, because I used an } else { statement. Any suggestions?

@dmanners dmanners self-assigned this Nov 1, 2017
@dmanners
Copy link
Contributor

dmanners commented Nov 1, 2017

@tdgroot thanks for the PR. I will start to process this now. Do not worry about the codacy check for the else that result seems a bit odd to me.

@dmanners dmanners added this to the November 2017 milestone Nov 1, 2017
@dmanners dmanners added Release Line: 2.2 2.2.x Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release labels Nov 1, 2017
Copy link
Contributor

@dmanners dmanners left a comment

Choose a reason for hiding this comment

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

At least 1 change to be made for BC reasons. I will get back to you about the changes to the factory class.

*/
public function __construct(
ReadFactory $readFactory,
\Magento\Framework\Filesystem\File\WriteFactory $fileWriteFactory
FileWriteFactory $fileWriteFactory,
DomDocumentFactory $domDocumentFactory
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

I was already wondering how BC was being handled! I'll make the constructor parameter optional for BC.

Copy link
Contributor

Choose a reason for hiding this comment

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

It might also be a good idea to revert the change made to \Magento\Framework\Filesystem\File\WriteFactory $fileWriteFactory as this is not specific to your change and I am not 100% sure how BC would work in this case.

*/
public function create()
public function create($data = null)
Copy link
Contributor

Choose a reason for hiding this comment

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

I will need to double check if this will break BC also as according to http://devdocs.magento.com/guides/v2.2/contributor-guide/backward-compatible-development/index.html#adding-parameters-in-public-methods you cannot add new parameters to public methods. Though all BC breaks can be approved let me check internally here and get back to you on this one.

@dmanners
Copy link
Contributor

dmanners commented Nov 1, 2017

Ok @tdgroot here is what I am thinking so that we do not break BC and then this can be merged into 2.2.

  1. It is not recommended to use inheritance inside of Magento2 but rather composition. So what I would suggest we do here is update app/code/Magento/Developer/Model/XmlCatalog/Format/PhpStorm/DomDocumentFactory.php so that it does not extends the lib/internal/Magento/Framework/DomDocument/DomDocumentFactory.php.
  2. Revert the changes to lib/internal/Magento/Framework/DomDocument/DomDocumentFactory.php as I am not sure how we can make these without breaking BC.
  3. Add all the required methods into the new factory so that it will work as expected.

After this has been done and merged we could consider making the more detailed change into the 2.3 release in which case we can make a few more changes with regards to BC.

How does that sound to you?

@tdgroot
Copy link
Member Author

tdgroot commented Nov 7, 2017

@dmanners thank you for your feedback.

They seem fair points, I'll need to find some time coming week to propose the changes based on your feedback. I have one question, though.

How did the changes in lib/internal/Magento/Framework/DomDocument/DomDocumentFactory.php break BC? The $data parameter is optional, so it should work fine for piece of code that uses the method. Or is it just against Magento's guidelines?

@dmanners
Copy link
Contributor

dmanners commented Nov 9, 2017

@tdgroot yes sorry that was my mistake I missed the fact it was optional. That will be fine.

@tdgroot
Copy link
Member Author

tdgroot commented Nov 11, 2017

Hi @dmanners. I added BC to the code and tweaked some parts as well!

* DomDocumentFactory constructor.
* @param \Magento\Framework\ObjectManagerInterface $objectManager
*/
public function __construct(\Magento\Framework\ObjectManagerInterface $objectManager)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to make the changes to this file or are we always using the new Dom factory class? My worry here is that a change like this will break backwards compatibility.

Copy link
Member Author

Choose a reason for hiding this comment

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

I see, this breaks BC. I can make the $objectManager dependency optional?

Copy link
Contributor

Choose a reason for hiding this comment

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

Technically this is a private class so we could choose to break BC in this case. Otherwise you could also make the object manager a static call. Another thing to note is that the factory should only be concerned with creating the object and not filling it. In this case initializeDocument in the other factory and calling $dom->loadXML($data) load in the other factory is not really the way to go in my mind.

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right. Factories should only instantiate objects. Wouldn't it be better to migrate all the domain specific code back to \Magento\Developer\Model\XmlCatalog\Format\PhpStorm?

Sorry for all the corrections, refactorings, etc. I'm learning a lot from creating Magento 2 pull requests :).

Copy link
Contributor

Choose a reason for hiding this comment

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

No worries. I see two options here.

  1. Migrate all the domain specific code back to the \Magento\Developer\Model\XmlCatalog\Format\PhpStorm.
  2. Create our own classes for the two dom documents that have the public methods that we need. Then change the new factories to instantiate these new objects.

Not sure what you would prefer to do. If you do go with the idea of new classes then please have a look through http://devdocs.magento.com/guides/v2.2/coding-standards/technical-guidelines/technical-guidelines.html#2-class-design and of course let me know if you need some assistance.

Copy link
Contributor

Choose a reason for hiding this comment

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

@tdgroot do you think you will have time to look into this?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dmanners I'm currently too busy to get working on this PR. Next week I hope to find some time.

@dmanners
Copy link
Contributor

Hi @tdgroot if you would like help with this pull request I would be happy to take over and see if we can get this sorted before the end of 2018. How does that sound?

@tdgroot
Copy link
Member Author

tdgroot commented Dec 20, 2017

@dmanners Sure! Rounding up 2017 is getting really busy unfortunately..

@magento-team magento-team merged commit b85b91e into magento:2.2-develop Dec 22, 2017
@magento-engcom-team magento-engcom-team added the Fixed in 2.2.x The issue has been fixed in 2.2 release line label Dec 22, 2017
@tdgroot tdgroot deleted the 2.2-develop-fix_empty_idea_misc_xml branch June 2, 2018 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed in 2.2.x The issue has been fixed in 2.2 release line Progress: accept Release Line: 2.2 Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants