Refactored the Grid component #9470

mickaelandrieu · 2018-08-21T16:21:18Z

Questions	Answers
Branch?	develop
Description?	Some parts are not consistents in terms of naming + missing Hooks
Type?	improvement
Category?	CO
BC breaks?	no
Deprecations?	no
How to test?	Logs page should works, see PrestaShop/docs#116 for details.

This change is

mickaelandrieu · 2018-08-21T17:35:43Z

src/Core/Grid/GridFactory.php

    /**
     * @param GridDefinitionFactoryInterface $definitionFactory
-     * @param GridDataProviderInterface      $dataProvider
+     * @param GridDataFactoryInterface      $dataFactory


PHPDoc is missing here

sarjon

I may join to help you with update if needed. 👍

sarjon · 2018-08-22T06:32:17Z

src/Core/Grid/Definition/Definition.php

+    /**
+     * @param ColumnCollectionInterface $columns
+     */
+    public function setColumns($columns)


are you sure we need these setters?

they are not part of contract

you can do columns and actions modification using$definition->getColumns()->add(..add column) or $definition->getColumns()->remove(...column to remove)

I don't need them to be part of the contract as we retrieve a Definition instance and not a DefinitionInterface.

We need at least setName, isn't it? And people will expect setColumns() for sure

but shouldnt Definition be final as it implements DefinitionInterface?

Regarding setName(), i guess you should be able to change it, but with other setter, i dont know.. :/
Definition already has ColumnCollection set (in constructor when created), there is no need to be able to set it again, because if you want to change something in it, you can do using $definition->getColumns().

ok so the module and the docs should describe that: I keep the setter for the name.

Also, there is no link between implementing an interface and being final. The way I see it:

implementing the interface means you have access to methods available into the interface, you'll see that in the end the DefinitionFactory create a concrete implementation of Definition class :) This is why it's ok to have a setter into our concrete implementation that is not part of contract because we never assume we have this setter on something that expect the interface.

it is true that I'd use to make my final classes implement an interface to let developers use their own implementations: we're doing an extensible CMS and I'm removing overrides system

for me, making my class final means "this class have and only have the behavior we expect for it, if you want to alter it, rely on the contract and not on our own"

this is really defensive programming, I try to stabilize a 10 years old software and I need to ensure that what we provide can't be broken :)

sarjon · 2018-08-22T06:37:07Z

src/Core/Grid/Definition/Factory/AbstractGridDefinitionFactory.php


    /**
     * {@inheritdoc}
     */
-    final public function create()
+    final public function getDefinition()


hmm, isnt create() or createNew() a better name? It is a factory, it's responsibility is to create new instances every time you ask for it, getDefinition() is weird imo. 🤔

no, create or createNew isn't giving me any information on what I retrieve.

$productsDefinition = $productsGridDefinitionFactory->createNew() it gives information when variable naming is correct :) as getDefinition() does not give information whether we get new or same instance every time (my opinion).

it's a factory: what do you expect to retrieve from a factory? 👼

sarjon · 2018-08-22T06:40:12Z

src/Core/Grid/GridFactory.php

    }

    /**
     * {@inheritdoc}
     */
-    public function createUsingSearchCriteria(SearchCriteriaInterface $searchCriteria)
+    public function getGrid(SearchCriteriaInterface $searchCriteria)


same here with naming, are you getting or creating new grid. What's more, we should not repeat Grid in method names is guess?

it's consistent naming:

getDefinition() : DefinitionInterface

getGrid() : GridInterface

...

this way people can't be wrong on what they expect to get using these methods, even if there have no access to docs.

sarjon · 2018-08-22T06:41:48Z

src/Core/Grid/GridFactory.php

+        $definition = $this->definitionFactory->getDefinition();
+
+        $this->hookDispatcher->dispatchForParameters('action'.$definition->getId().'GridDefinitionModifier', [
+            'definition' => &$definition,


you dont need to pass $definition as a reference since it is object, all modifications performed inside hooks will be applied either way.

I'm not really sure of it, this needs to be tested carefully (and so on, some objects should be available for edition and other ones only for read)

sarjon · 2018-08-22T06:42:09Z

src/Core/Grid/GridFactory.php


        $filterForm = $this->filterFormFactory->create($definition);
-        $filterForm->setData($searchCriteria->getFilters());
+        $this->hookDispatcher->dispatchForParameters('action'.$definition->getId().'GridFilterFormModifier', [
+            'filterForm' => &$filterForm,


same with reference here.

sarjon · 2018-08-22T06:44:23Z

src/Core/Grid/GridFactory.php


-        $data = $this->dataProvider->getData($searchCriteria);
+        $filterForm->setData($searchCriteria->getFilters());


maybe setData before hook is dispatched?

sarjon · 2018-08-22T06:56:53Z

src/PrestaShopBundle/Controller/Admin/Configure/AdvancedParameters/EmailController.php

@@ -97,7 +97,7 @@ public function indexAction(Request $request, EmailLogsFilter $filters)
    public function searchAction(Request $request)
    {
        $definitionFactory = $this->get('prestashop.core.grid.definition.factory.email_logs');
-        $emailLogsDefinition = $definitionFactory->create();
+        $emailLogsDefinition = $definitionFactory->getDefinition();


since hook GridDefinitionModifier were move from DefinitionFactory to GridFactory we have an issue here.

Imagine some module updated grid definition with new filter/column, the changes wont be reflected here, but when presenting grid, they would be as hooks are dispatched in Presenter only.
That's why I wanted to keep hooks in factories to make sure that each time you create new instance, hook is dispatched and you have final instance.

not really, it's because we're doing object construction in controllers when we shouldn't do it: we should rely on the grid directly instead of rebuilding the form from grid definition :/

in all cases, depending on hook dispatcher everywhere is a terrible idea: it's like having access to the context

it's because we're doing object construction in controllers when we shouldn't do

agree, but if we were to create whole grid, we would need to do unnecessary SQL queries even though db data is not used here, only filter form is important. :/

At the end:

“There are no solutions. There are only trade-offs.”
― Thomas Sowell

As I can't find (right now) a better way to do this, I change but I'm not satisfied :(

sarjon · 2018-08-22T06:59:13Z

src/PrestaShopBundle/Resources/config/services/core/grid.yml

@@ -1,3 +1,5 @@
+parameters:


at some point this file could be split into several files, like grid/data_factory.yml, grid/definition_factory.yml & etc. Similar as we did with forms in bundle, as there will be quite a few service definitions regarding grid, wdyt? :)

I agree, but looking at services I'm pretty sure we can experiment auto configuration instead: don't you think?

you mean autowire?

sarjon · 2018-08-22T07:01:34Z

src/Core/Grid/Exception/InvalidDataException.php

+
+use Exception;
+
+class InvalidDataException extends Exception implements ExceptionInterface


i guess we could have base GridException extends Exception implements ExceptionInterface and instead class InvalidDataException extends GridException? other exceptions would need to be updated too.

Agreed with @sarjon 👍

sarjon · 2018-08-22T07:03:12Z

src/Core/Grid/Presenter/GridPresenter.php

+            'grid' => $grid,
+        ]);
+
+        return $presentedGrid;


according to our schema, it should produce immutable view, but array is mutable. What if we had GridView instance? Similar as Forms do, except much simpler.

sarjon · 2018-08-22T07:13:20Z

@mickaelandrieu regarding component update, i have few ideas :)

Grid/Collection/AbstractCollection i think we can either get rid of it or move somewhere else, as it is very generic class and can be used anywhere in core.
Actions that are under Grid/Actions namespace could be unified maybe? There are 3 groups of actions: grid, bulk & row. Could we keep one ActionInterface instead of 3 different?

mickaelandrieu · 2018-08-22T07:58:39Z

Grid/Collection/AbstractCollection i think we can either get rid of it or move somewhere else, as it is very generic class and can be used anywhere in core.

And this will make the component dependent of the core => meh

Actions that are under Grid/Actions namespace could be unified maybe? There are 3 groups of actions: grid, bulk & row. Could we keep one ActionInterface instead of 3 different?

Don't get caught into this trap! Every use case can evolve and have his own lifecycle, from a domain point of view, Grid actions, Bulk actions and Row actions are different things

sarjon · 2018-08-22T08:01:43Z

And this will make the component dependent of the core => meh

then lets get rid of it? 😃 it is not really that useful (as it seemed before) and not even sure methods provided by this abstract collection are used at all.

mickaelandrieu · 2018-08-22T08:08:41Z

then lets get rid of it?

we need the collections to be countable and iterable and I'm pretty sure we will add some helpers like filter(), map(), something you can retrieve in Laravel Collections for instance :)

But I want the community to ask for it before introduce the features

PierreRambaud

@sarjon Is it ok for you?

mickaelandrieu · 2018-08-24T14:41:16Z

@sarjon we'll address the AbstractException question if we need to add more exceptions, the scope of this pull request was to be compliant with docs about Hooks and naming.

But now it's merged, you can rebase your pull request about data ~~providers~~ factories improvements ;)

mickaelandrieu · 2018-08-24T14:41:41Z

ping @eternoendless this don't needs QA, in case of error, I'll fix it.

Refactored the Grid component

2b6656c

mickaelandrieu commented Aug 21, 2018

View reviewed changes

sarjon reviewed Aug 22, 2018

View reviewed changes

mickaelandrieu mentioned this pull request Aug 22, 2018

Improve grid data providers #9402

Merged

mickaelandrieu added 3 commits August 24, 2018 11:04

Added common hooks and depends on HookDispatcherInterface

7744de4

Fixed merge conflicts

1bdc126

Removed deprecated dispatchForParameters uses in Grid component

b78f453

prestonBot added develop Branch improvements labels Aug 24, 2018

PierreRambaud approved these changes Aug 24, 2018

View reviewed changes

PierreRambaud added this to the 1.7.5.0 milestone Aug 24, 2018

mickaelandrieu merged commit c389519 into PrestaShop:develop Aug 24, 2018

mickaelandrieu deleted the grid/docs-compliancy branch August 24, 2018 14:41

matks added the migration symfony migration project label Sep 19, 2018

prestonBot added the Improvement Type: Improvement label Oct 19, 2018


		$data = $this->dataProvider->getData($searchCriteria);
		$filterForm->setData($searchCriteria->getFilters());


		use Exception;

		class InvalidDataException extends Exception implements ExceptionInterface

Refactored the Grid component #9470

Refactored the Grid component #9470

Conversation

mickaelandrieu commented Aug 21, 2018 • edited by jolelievre

Choose a reason for hiding this comment

sarjon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mickaelandrieu Aug 22, 2018 • edited

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

mickaelandrieu Aug 22, 2018 • edited

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

sarjon commented Aug 22, 2018

mickaelandrieu commented Aug 22, 2018

sarjon commented Aug 22, 2018

mickaelandrieu commented Aug 22, 2018 • edited

PierreRambaud left a comment

Choose a reason for hiding this comment

mickaelandrieu commented Aug 24, 2018 • edited

mickaelandrieu commented Aug 24, 2018

mickaelandrieu commented Aug 21, 2018 •

edited by jolelievre

mickaelandrieu Aug 22, 2018 •

edited

mickaelandrieu Aug 22, 2018 •

edited

mickaelandrieu commented Aug 22, 2018 •

edited

mickaelandrieu commented Aug 24, 2018 •

edited