Support for non-FQN classes on web-API interfaces.

[phoenix128]

This commit provides a support for "use" statement in web-API interfaces and the usage of non-FQN class names in doctypes. It also provides a fix for MSI-1524 and MSI-1537.

Description

Before this commit you were not able to import class names in interfaces used for web-API.

For example, the following interface was not working with the non-FQN name MyClass imported through the use alias definition.

namespace ...;

use My\Module\MyClass;

interface SomeInterface
{
...
/**
 * @param MyClass $param
 * ...
 */
 public function getMyMethod()
 ...
...
}

Now, through a new method \Magento\Framework\Reflection\TypeProcessor::resolveFullyQualifiedClassName, the FQN is automatically resolved if an alias or a short name is provided.

Fixed Issues (if relevant)

1. Provide robust fix for nested object instantiation via Web API inventory#1537: Provide robust fix for nested object instantiation via Web API
2. POST V1/inventory/source-selection-algorithm-result throws exception inventory#1524: POST V1/inventory/source-selection-algorithm-result throws exception

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)

[magento-engcom-team]

Hi @phoenix128. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento-engcom-team give me test instance - deploy test instance based on PR changes
• @magento-engcom-team give me {$VERSION} instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

[maghamed]

@phoenix128 looks like the Integration build is broken on your latest PR

[phoenix128]

@maghamed , trying to understand why it breaks the integration tests.

[phoenix128]

@maghamed , it should be fixed now.

[phoenix128]

@ishakhsuvarov , I have some failing tests in the code quality of test classes I use as fixture, should I ignore it?

[phoenix128]

@ishakhsuvarov , any news here? Thanks.

[ishakhsuvarov]

@phoenix128 Sorry for the delay. I don't have any major comments, hopefully it's getting merge soon enough.

[sidolov]

Please, consider making methods private, looks like they used only in the private implementation

[phoenix128]

Hi @sidolov ,
it is used in \Magento\Framework\Reflection\Test\Unit\TypeProcessorTest. We have two options: remove tests or eject this method to a dedicated service.

[navarr]

I can't help but feel like this should be a check against a dictionary of reserved words...

Wouldn't something like use \Magento\Framework\App\ObjectManager as om; cause weird problems and error messages that wouldn't make sense?

While it's not the way one should be writing code (subjective), I think we can still prevent the issue if its tackled here?

[magento-engcom-team]

Hi @sidolov, thank you for the review.
ENGCOM-4046 has been created to process this Pull Request

[ghost]

Hi @phoenix128, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.