Zend feed refactoring

[ldusan84]

Refactoring in order to move hardcoded Zend_Feed dependency into interface for further refactoring. Ticket #9240

Description

I have created an interface that replaces Zend_Feed::importArray static call. The concrete class takes Zend_Feed object and returns it's own result that's a wrapper around Zend_Feed_Abstract.

I am not sure what the policies are on this type of things so I just went with the bare minimum of what is required.

Would appreciate hearing your thoughts on this one.

[dmanners]

@ldusan84 I think this is a great start! I would love to see it migrated over to https://github.com/zendframework/zend-feed but I understand with going with the bare minimum to start with.

[ldusan84]

@dmanners thanks, yes, that would be the next step and I would like to do that after this one.

[adragus-inviqa]

Should just use __($e->getMessage). It's the same thing, but shorter.

[ldusan84]

Nice one, makes sense, thanks 👍

[ldusan84]

There is an error on Travis CI - "The command "phpenv global 7.1" failed and exited with 1 during .", anything I can do about it?

[ishakhsuvarov]

@ldusan84 Looks like it was some temporary error with the Travis CI. I've restarted the job in question and its green now.

[maghamed]

That's backward incompatible, new parameter should be added last into the list, and that parameter should be optional. You can read more about it here - http://devdocs.magento.com/guides/v2.1/ext-best-practices/extension-coding/backwards-compatible-development/index.html "Adding a constructor parameter" section

[ldusan84]

Makes sense, it's fixed now.

[maghamed]

better to make variable as private

[ldusan84]

Agreed, fixed.

[maghamed]

it's not correct to translate low level exception providing its output to translation function.
Because there is no guarantee that the phrase would be translated .

All you need to do - is to log initial exception.
And provide new description which says about the problem in general words

[ldusan84]

This is done, can you please check?

[maghamed]

don't think that we need to introduce new exception type. It's better to re-use some of the existing ones.

Or at least to introduce new exception for ImportException

[ldusan84]

If you look at the Zend_Feed module Zend_Feed_Exception can be thrown for a lot of things. The only common exception for all those cases would be RuntimeException, so I picked that one. Let me know what you think.

[maghamed]

it's not good from interface point of view, that 'atom' passed as a default parameter.

What other formats does this Importer support?
It's not clear from the interface.
And not clear how to check this out.
Interface should be clear enough to get this knowledge

[ldusan84]

I see your point but I did it because I wanted to replicate the original importArray method from Zend_Feed which has those arguments. What would be the best thing to do in this case?

[maghamed]

It's not always a good Idea to replicate contracts from Zend. Because sometimes we would provide a wider contract than Zend does, and sometimes their contracts are not so ideal.
Above I described my idea what we can do with this

[maghamed]

please provide a precise description what this method is actually do

[ldusan84]

Done.

[maghamed]

maybe make sense to rename this interface to
FeedFactoryInterface ?

[ldusan84]

I am not sure about this, why do you think that it should be renamed to factory, it doesn't create new objects?

[maghamed]

Looks like it creates. Description from the importArray method says:
Get a new \Magento\Framework\App\Feed object from a custom array
and implementation looks like:

$feed = $this->feedProcessor->importArray($data, $format);
 return $this->feedFactory->create(['feed' => $feed]);

for now it's not clear why it's called importer? From where it imports data?
Looking at the interface and implementation I see FeedFactory which accepts array of data and format

For me it's not clear why we need to keep both objects
\Magento\Framework\App\Feed\Importer
and
FeedFactory

Because both of them responsible for \Magento\Framework\App\FeedInterface creation.

I propose to get rid of \Magento\Framework\App\Feed\Importer and move it's logic to FeedFactory.

Thus, FeedFactoryInterface would look like:

class FeedFactoryInterface
{
public function importArray(array $data, $format = SupportedFeedFormatsInterface::DEFAULT_FORMAT)
}

[maghamed]

hey @ldusan84 , sorry for late response.
Just provided feedback for your PR. Hope you are still interested to deliver these changes

[ldusan84]

Hi @maghamed no problem, thanks for the feedback. I'll look into the stuff you mentioned.

[ldusan84]

Hi @maghamed I made some changes and posted comments to your feedback. Let me know what you think please.

[ldusan84]

@ishakhsuvarov @maghamed @dmanners any news on this one guys?

[benmarks]

@maksek can your team check?

[ishakhsuvarov]

@ldusan84 @benmarks We are looking into this PR. Review takes somewhat more time then usual, since it introduces updates to the API, which must be in ideal desired-state if updated. We attempt to design APIs which would not require and additional changes in foreseeable future.

Thank you for your patience.

[maghamed]

Looks like it creates. Description from the importArray method says:
Get a new \Magento\Framework\App\Feed object from a custom array
and implementation looks like:

$feed = $this->feedProcessor->importArray($data, $format);
 return $this->feedFactory->create(['feed' => $feed]);

for now it's not clear why it's called importer? From where it imports data?
Looking at the interface and implementation I see FeedFactory which accepts array of data and format

For me it's not clear why we need to keep both objects
\Magento\Framework\App\Feed\Importer
and
FeedFactory

Because both of them responsible for \Magento\Framework\App\FeedInterface creation.

I propose to get rid of \Magento\Framework\App\Feed\Importer and move it's logic to FeedFactory.

Thus, FeedFactoryInterface would look like:

class FeedFactoryInterface
{
public function importArray(array $data, $format = SupportedFeedFormatsInterface::DEFAULT_FORMAT)
}

[maghamed]

I prefer to see this method as

public function getFormatedContentAs($format = SupportedFeedFormatsInterface::DEFAULT_FORMAT);

Naming could be changed, but main idea is to make FeedInteface agnostic to the possible representation formats.
Because we no need to have coupling between Data and different ways how these data could be presented.
Thus, all that we need to have is kind of "output" method which accepts a format in which data should be presented. And we need to have a dedicated interface/entity responsible for format registration.
I mentioned SupportedFeedFormatsInterface here

[maghamed]

It's not always a good Idea to replicate contracts from Zend. Because sometimes we would provide a wider contract than Zend does, and sometimes their contracts are not so ideal.
Above I described my idea what we can do with this

[maghamed]

hey @ldusan84 do you have some time to make requested changes for current PR?

[ldusan84]

Hi @maghamed yes sure, I would like to, sorry I read your comments but didn't have time to respond these days.

[maghamed]

Cool, thanks! Take your time

[magento-engcom-team]

@ldusan84 thank you for contributing. Please accept Community Contributors team invitation here to gain extended permissions for this repository.

[ihor-sviziev]

Hi,

Currently ZF1 zend feed usage was replaced with ZF 2 Zend\Feed in magento-engcom/php-7.2-support#89 and we have conflicts in this PR.
@ishakhsuvarov @maghamed @okorshenko will it be handled by magento team, or adjusting this PR is required?

[okorshenko]

Hi @ldusan84
Thank you for your patience. We fixed some broken code in your branch and sent the fix to QA department. We are waiting for QA report now. If everything is ok, this Pull Request should be merged soon. @sidolov is working on this PR now

Please do not change or modify the code in your branch till merge.

[magento-engcom-team]

Hi @ldusan84. Thank you for your contribution.
Changes from your Pull Request will be available with the upcoming 2.3.0 release.