Sales module MassAction refactoring

[ldusan84]

I think that the MassAction feature in the Sales module is not correctly architectured as it contains hidden dependencies.

Description

If you try to create your own mass action in the sales grid you need to extend the base MassAction class. If you do that you will end up with a fatal error when you use it in admin panel:

<?php
namespace ExampleVendor\ExampleModule\Controller\Adminhtml;

class Example extends \Magento\Sales\Controller\Adminhtml\Order\AbstractMassAction
{

}

"Fatal error: Call to a member function create() on a non-object"

The problem is this:

abstract class AbstractMassAction extends \Magento\Backend\App\Action
{
    /**
    ***
     */
    public function __construct(Context $context, Filter $filter)
    {
        parent::__construct($context);
        $this->filter = $filter;
    }
    /**
     * Execute action
     *
     * @return \Magento\Backend\Model\View\Result\Redirect
     * @throws \Magento\Framework\Exception\LocalizedException|\Exception
     */
    public function execute()
    {
        try {
            $collection = $this->filter->getCollection($this->collectionFactory->create());
            return $this->massAction($collection);
        } catch (\Exception $e) {
            $this->messageManager->addError($e->getMessage());
            /** @var \Magento\Backend\Model\View\Result\Redirect $resultRedirect */
            $resultRedirect = $this->resultFactory->create(ResultFactory::TYPE_REDIRECT);
            return $resultRedirect->setPath($this->redirectUrl);
        }
    }
}

So the collectionFactory should be injected into constructor but you realize that only after you examine the entire class. We shouldn't do that as we have dependency injection in order to make dependencies visible.

You can find out more about this on my blog post http://dusanlukic.com/magento-2-hidden-dependency-refactoring

I moved the dependency into abstract method making it mandatory for child classes to provide the collection.

This feature needs more refactoring, this would be the first step.

No tests needed as public api remains unchanged.

[avoelkl]

It seems the only subclass from \AbstractMassAction using the OrderManagmentInterface is \MassHold where it is injected via constructor. I don't see a need to declare it as param here.

[ldusan84]

@avoelkl exactly, thanks, will remove those two.

[avoelkl]

Hi Dusan!
Thanks for the PR! As mentioned earlier I really like the blogpost you've created earlier. Seeing a PR resulting from it is even bette :)
Actually I would prefer moving DI into the constructor but given the current state the abstract method+child classes are good to go i think.
I will clarify this with the Magento team to get their opinion on this, though.

[ldusan84]

Hi @avoelkl thank you for the review.

Yes, I agree, this is only one step and some refactoring after this should follow.

Looking forward to hearing Magento team's opinion.

[avoelkl]

Hi @ldusan84,
Some update on this: There are some errors in the tests for EE as there are dependencies on the refactored classes. Do you have an EE installation ready to verify this?
Otherwise we can have the Magento team looking at this and resolving it.

[ldusan84]

Hi @avoelkl

Thanks for looking into this. I'll check what's happening on EE and let you know, no worries.

[ldusan84]

Hi @avoelkl

I have fixed the issues in EE, can you please tell me what would be the best way to submit those changes?

[avoelkl]

Hi @ldusan84,
You can add those commits to this PR and then we can run the acceptance tests on the latest updates here.

[ldusan84]

Hi @avoelkl

The thing is that those files that should be changed are EE files that do not exist in the community edition. I don't think that I can commit those here?

[avoelkl]

Ah sorry, you're right. My fault.
Let me check :)

[avoelkl]

We'll give you access to the EE repo, I'll contact you with further details :)

[okorshenko]

Hello @ldusan84
Unfortunately we can not accept this pull request since it introduces BiC. We agree that having a hidden dependency in abstract controller is an issue. We will deprecate this controller in 2.2. There is no big value from this controller.

Thank you for your everyone collaboration!