Zend feed refactoring #9347

ldusan84 · 2017-04-21T16:14:34Z

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 · 2017-04-24T10:47:00Z

@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 · 2017-04-24T11:37:45Z

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

adragus-inviqa · 2017-04-30T19:40:23Z

lib/internal/Magento/Framework/App/Feed/Importer.php

+            return $this->feedFactory->create(['feed' => $feed]);
+        } catch (\Zend_Feed_Exception $e) {
+            throw new \Magento\Framework\Exception\FeedImporterException(
+                new \Magento\Framework\Phrase($e->getMessage()),


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

Nice one, makes sense, thanks 👍

ldusan84 · 2017-05-15T16:03:52Z

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 · 2017-05-20T12:12:06Z

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

maghamed · 2017-05-20T12:50:29Z

app/code/Magento/Rss/Model/Rss.php

     * @param SerializerInterface|null $serializer
     */
    public function __construct(
        \Magento\Framework\App\CacheInterface $cache,
+        \Magento\Framework\App\FeedImporterInterface $feedImporter,


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

Makes sense, it's fixed now.

maghamed · 2017-05-21T11:12:42Z

app/code/Magento/Rss/Test/Unit/Model/RssTest.php

@@ -34,6 +34,27 @@ class RssTest extends \PHPUnit_Framework_TestCase
    ];

    /**
+     * @var string
+     */
+    protected $feedXml = '<?xml version="1.0" encoding="UTF-8"?>


better to make variable as private

Agreed, fixed.

maghamed · 2017-05-21T11:52:48Z

lib/internal/Magento/Framework/App/Feed/Importer.php

+            return $this->feedFactory->create(['feed' => $feed]);
+        } catch (\Zend_Feed_Exception $e) {
+            throw new \Magento\Framework\Exception\FeedImporterException(
+                __($e->getMessage()),


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

This is done, can you please check?

maghamed · 2017-05-21T11:59:00Z

lib/internal/Magento/Framework/Exception/FeedImporterException.php

+ * Copyright © Magento, Inc. All rights reserved.
+ * See COPYING.txt for license details.
+ */
+namespace Magento\Framework\Exception;


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

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 · 2017-05-21T12:01:06Z

lib/internal/Magento/Framework/App/FeedImporterInterface.php

+     * @param  string $format
+     * @return FeedInterface
+     */
+    public function importArray(array $data, $format = 'atom');


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

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?

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 · 2017-05-21T12:01:39Z

lib/internal/Magento/Framework/App/FeedImporterInterface.php

+interface FeedImporterInterface
+{
+
+    /**


please provide a precise description what this method is actually do

maghamed · 2017-05-21T12:06:30Z

lib/internal/Magento/Framework/App/FeedImporterInterface.php

+ */
+namespace Magento\Framework\App;
+
+interface FeedImporterInterface


maybe make sense to rename this interface to
FeedFactoryInterface ?

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

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 · 2017-05-21T12:13:16Z

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

ldusan84 · 2017-05-21T18:34:32Z

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

ldusan84 · 2017-05-24T15:35:13Z

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

ldusan84 · 2017-06-29T12:18:06Z

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

benmarks · 2017-07-05T17:38:28Z

@maksek can your team check?

ishakhsuvarov · 2017-07-06T07:35:45Z

@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 · 2017-07-06T07:50:49Z

lib/internal/Magento/Framework/App/FeedImporterInterface.php

+ */
+namespace Magento\Framework\App;
+
+interface FeedImporterInterface


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 · 2017-07-06T08:10:40Z

lib/internal/Magento/Framework/App/FeedInterface.php

+    /**
+     * @return string
+     */
+    public function asXml();


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 · 2017-07-06T08:24:04Z

lib/internal/Magento/Framework/App/FeedImporterInterface.php

+     * @param  string $format
+     * @return FeedInterface
+     */
+    public function importArray(array $data, $format = 'atom');


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 · 2017-07-14T12:59:14Z

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

ldusan84 · 2017-07-14T13:00:39Z

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

maghamed · 2017-07-14T13:02:40Z

Cool, thanks! Take your time

magento-engcom-team · 2018-01-26T21:16:10Z

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

ihor-sviziev · 2018-03-23T09:18:32Z

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 · 2018-04-30T11:53:49Z

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 · 2018-05-12T16:34:04Z

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

ldusan84 added 6 commits April 21, 2017 17:54

Zend_Feed refactoring progress

ca9e582

Tests refactoring

ed33b18

Fixed unit test

c7ba65a

Tidying up files

9d0a290

Small CS fix

109047f

Small CS fix

4534a2e

maghamed self-assigned this Apr 24, 2017

maghamed self-requested a review April 24, 2017 10:55

More CS fixes

c413389

adragus-inviqa reviewed Apr 30, 2017

View reviewed changes

Small exception fix

caa4471

maghamed suggested changes May 21, 2017

View reviewed changes

Changes after the code review

66154e6

maghamed suggested changes Jul 6, 2017

View reviewed changes

okorshenko added this to the July 2017 milestone Jul 20, 2017

okorshenko added the develop label Jul 20, 2017

okorshenko self-assigned this Jul 25, 2017

magento-team removed the Progress: needs update label Jan 3, 2018

okorshenko modified the milestones: December 2017, January 2018 Jan 8, 2018

ihor-sviziev requested a review from ishakhsuvarov January 18, 2018 07:18

okorshenko self-assigned this Jan 26, 2018

okorshenko modified the milestones: January 2018, February 2018 Feb 7, 2018

okorshenko mentioned this pull request Feb 7, 2018

magento/zf1 does not support PHP 7.2 magento-engcom/php-7.2-support#22

Closed

vkublytskyi mentioned this pull request Feb 17, 2018

Eliminate usage of Zend_Feed from Magento 2 Open Source magento-engcom/php-7.2-support#70

Closed

okorshenko modified the milestones: February 2018, March 2018 Mar 1, 2018

ihor-sviziev added the Progress: accept label Mar 6, 2018

ihor-sviziev removed the Progress: accept label Mar 23, 2018

okorshenko modified the milestones: March 2018, April 2018 Apr 16, 2018

sidolov self-assigned this Apr 28, 2018

okorshenko unassigned dmanners, maghamed, ishakhsuvarov and okorshenko Apr 30, 2018

magento-engcom-team added the Progress: accept label May 10, 2018

magento-engcom-team merged commit 4462eaf into magento:2.3-develop May 12, 2018

magento-engcom-team pushed a commit that referenced this pull request May 12, 2018

MAGETWO-70886: Zend feed refactoring #9347

7ea0611

magento-engcom-team pushed a commit that referenced this pull request May 12, 2018

MAGETWO-70886: Zend feed refactoring #9347

fd178e8

magento-engcom-team pushed a commit that referenced this pull request May 12, 2018

MAGETWO-70886: Zend feed refactoring #9347

cc52252

magento-engcom-team pushed a commit that referenced this pull request May 12, 2018

MAGETWO-70886: Zend feed refactoring #9347

52f5c4c

Zend feed refactoring #9347

Zend feed refactoring #9347

Conversation

ldusan84 commented Apr 21, 2017 • edited by okorshenko Loading

Description

dmanners commented Apr 24, 2017 • edited Loading

ldusan84 commented Apr 24, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ldusan84 commented May 15, 2017

ishakhsuvarov commented May 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maghamed commented May 21, 2017

ldusan84 commented May 21, 2017

ldusan84 commented May 24, 2017

ldusan84 commented Jun 29, 2017

benmarks commented Jul 5, 2017

ishakhsuvarov commented Jul 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maghamed commented Jul 14, 2017

ldusan84 commented Jul 14, 2017

maghamed commented Jul 14, 2017

magento-engcom-team commented Jan 26, 2018

ihor-sviziev commented Mar 23, 2018 • edited Loading

okorshenko commented Apr 30, 2018 • edited Loading

magento-engcom-team commented May 12, 2018

ldusan84 commented Apr 21, 2017 •

edited by okorshenko

Loading

dmanners commented Apr 24, 2017 •

edited

Loading

ihor-sviziev commented Mar 23, 2018 •

edited

Loading

okorshenko commented Apr 30, 2018 •

edited

Loading