Zend feed refactoring #9347
Zend feed refactoring #9347
Conversation
|
@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. |
|
@dmanners thanks, yes, that would be the next step and I would like to do that after this one. |
| return $this->feedFactory->create(['feed' => $feed]); | ||
| } catch (\Zend_Feed_Exception $e) { | ||
| throw new \Magento\Framework\Exception\FeedImporterException( | ||
| new \Magento\Framework\Phrase($e->getMessage()), |
adragus-inviqa
Apr 30, 2017
Contributor
Should just use __($e->getMessage). It's the same thing, but shorter.
Should just use __($e->getMessage). It's the same thing, but shorter.
ldusan84
Apr 30, 2017
Author
Contributor
Nice one, makes sense, thanks 👍
Nice one, makes sense, thanks
|
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? |
|
@ldusan84 Looks like it was some temporary error with the Travis CI. I've restarted the job in question and its green now. |
| * @param SerializerInterface|null $serializer | ||
| */ | ||
| public function __construct( | ||
| \Magento\Framework\App\CacheInterface $cache, | ||
| \Magento\Framework\App\FeedImporterInterface $feedImporter, |
maghamed
May 21, 2017
Contributor
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
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
May 24, 2017
Author
Contributor
Makes sense, it's fixed now.
Makes sense, it's fixed now.
| @@ -34,6 +34,27 @@ class RssTest extends \PHPUnit_Framework_TestCase | |||
| ]; | |||
|
|
|||
| /** | |||
| * @var string | |||
| */ | |||
| protected $feedXml = '<?xml version="1.0" encoding="UTF-8"?> | |||
maghamed
May 21, 2017
Contributor
better to make variable as private
better to make variable as private
ldusan84
May 24, 2017
Author
Contributor
Agreed, fixed.
Agreed, fixed.
| return $this->feedFactory->create(['feed' => $feed]); | ||
| } catch (\Zend_Feed_Exception $e) { | ||
| throw new \Magento\Framework\Exception\FeedImporterException( | ||
| __($e->getMessage()), |
maghamed
May 21, 2017
Contributor
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
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
May 24, 2017
Author
Contributor
This is done, can you please check?
This is done, can you please check?
| * Copyright © Magento, Inc. All rights reserved. | ||
| * See COPYING.txt for license details. | ||
| */ | ||
| namespace Magento\Framework\Exception; |
maghamed
May 21, 2017
Contributor
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
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
May 24, 2017
Author
Contributor
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.
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.
| * @param string $format | ||
| * @return FeedInterface | ||
| */ | ||
| public function importArray(array $data, $format = 'atom'); |
maghamed
May 21, 2017
Contributor
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
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
May 24, 2017
Author
Contributor
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?
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
Jul 6, 2017
Contributor
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
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
| interface FeedImporterInterface | ||
| { | ||
|
|
||
| /** |
maghamed
May 21, 2017
Contributor
please provide a precise description what this method is actually do
please provide a precise description what this method is actually do
ldusan84
May 24, 2017
Author
Contributor
Done.
Done.
| */ | ||
| namespace Magento\Framework\App; | ||
|
|
||
| interface FeedImporterInterface |
maghamed
May 21, 2017
Contributor
maybe make sense to rename this interface to
FeedFactoryInterface ?
maybe make sense to rename this interface to
FeedFactoryInterface ?
ldusan84
May 24, 2017
Author
Contributor
I am not sure about this, why do you think that it should be renamed to factory, it doesn't create new objects?
I am not sure about this, why do you think that it should be renamed to factory, it doesn't create new objects?
maghamed
Jul 6, 2017
Contributor
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)
}
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)
}
|
hey @ldusan84 , sorry for late response. |
|
Hi @maghamed no problem, thanks for the feedback. I'll look into the stuff you mentioned. |
|
Hi @maghamed I made some changes and posted comments to your feedback. Let me know what you think please. |
|
@ishakhsuvarov @maghamed @dmanners any news on this one guys? |
|
@maksek can your team check? |
|
@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. |
| */ | ||
| namespace Magento\Framework\App; | ||
|
|
||
| interface FeedImporterInterface |
maghamed
Jul 6, 2017
Contributor
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)
}
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)
}| /** | ||
| * @return string | ||
| */ | ||
| public function asXml(); |
maghamed
Jul 6, 2017
Contributor
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
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
| * @param string $format | ||
| * @return FeedInterface | ||
| */ | ||
| public function importArray(array $data, $format = 'atom'); |
maghamed
Jul 6, 2017
Contributor
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
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
|
hey @ldusan84 do you have some time to make requested changes for current PR? |
|
Hi @maghamed yes sure, I would like to, sorry I read your comments but didn't have time to respond these days. |
|
Cool, thanks! Take your time |
|
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. |
|
Hi @ldusan84 Please do not change or modify the code in your branch till merge. |
magento-engcom-team
merged commit 4462eaf
into
magento:2.3-develop
|
Hi @ldusan84. Thank you for your contribution. |
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.