Magento 2: Quelle est la différence entre les deux fournisseurs de données des composants de grille?


16

Dans Magento 2.1, il y a au total 25 fournisseurs de listes / composants de données d'interface utilisateur configurés et utilisés. Leurs classes et ui_componentfichiers de fournisseur de données sont répertoriés ci-dessous

Magento\Bundle\Ui\DataProvider\Product\BundleDataProvider                     bundle_product_listing.xmlMagento\Catalog\Ui\DataProvider\Product\Attributes\Listing                    product_attributes_grid.xml
Magento\Catalog\Ui\DataProvider\Product\ProductCustomOptionsDataProvider      product_custom_options_listing.xml
Magento\Catalog\Ui\DataProvider\Product\ProductDataProvider                   configurable_associated_product_listing.xml
Magento\Catalog\Ui\DataProvider\Product\ProductDataProvider                   product_listing.xml
Magento\Catalog\Ui\DataProvider\Product\Related\CrossSellDataProvider         crosssell_product_listing.xml
Magento\Catalog\Ui\DataProvider\Product\Related\RelatedDataProvider           related_product_listing.xml
Magento\Catalog\Ui\DataProvider\Product\Related\UpSellDataProvider            upsell_product_listing.xml
Magento\Cms\Ui\Component\DataProvider                                         cms_block_listing.xml
Magento\Cms\Ui\Component\DataProvider                                         cms_page_listing.xml
Magento\ConfigurableProduct\Ui\DataProvider\Attributes                        product_attributes_listing.xml
Magento\Customer\Ui\Component\DataProvider                                    customer_listing.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          customer_online_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_creditmemo_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_invoice_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_shipment_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_view_creditmemo_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_view_invoice_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          sales_order_view_shipment_grid.xml
Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider          search_synonyms_grid.xml
BraintreeTransactionsDataProvider (virtual type)                              braintree_report.xml
    Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider    
Magento\GroupedProduct\Ui\DataProvider\Product\GroupedProductDataProvider     grouped_product_listing.xml
Magento\Review\Ui\DataProvider\Product\ReviewDataProvider                     review_listing.xml
Magento\Theme\Ui\Component\Design\Config\DataProvider                         design_config_listing.xml

Sur la base de ces informations, il semble qu'il existe deux classes de base que les programmeurs utilisateurs finaux peuvent utiliser pour baser leurs composants de grille sur

  • Magento \ Framework \ View \ Element \ UiComponent \ DataProvider \ DataProvider
  • Magento \ Ui \ DataProvider \ AbstractDataProvider

La Magento\Ui\DataProvider\AbstractDataProviderclasse semble plus simple des deux, et (semble-t-il?) Ne nécessite que la configuration d'un modèle de ressource Magento. Le Magento\Customer\Ui\Component\DataProvidermodule de grille client est basé sur cette classe et semble avoir toutes les fonctionnalités de tri, de filtrage, etc. nécessaires pour une liste de grille.

Y a-t-il une raison à cela Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider- ou s'agit-il simplement d'un code plus ancien / plus récent qui adopte une approche différente pour créer un fournisseur de données? En d'autres termes, l'utilisation du Magento\Framework\View\Element\UiComponent\DataProvider\DataProviderapporte-t-elle des fonctionnalités supplémentaires à la table ou permet-elle à d' autres parties du système de faire des choses avec la grille? En regardant le code source, cela Magento\Framework\App\RequestInterfacesemble intrigant - car cela implique que vous pourriez signaler des fonctionnalités "gratuitement" avec ces grilles. Cependant, sans un safari de code approfondi, je ne sais pas si c'est vrai ou non, et j'espère que quelqu'un a une explication claire de la raison pour laquelle vous utiliseriez une classe par rapport à l'autre.


Bonne question d'ailleurs, cela m'a aidé à résoudre un problème d'export pour mon module personnalisé en admin. J'utilisais en quelque sorte le mauvais type de Dataprovider "Magento \ Ui \ DataProvider \ AbstractDataProvider".
Sanjay Chaudhary

Réponses:


14

Pour moi, cette principale différence est que le Magento/Framework/View/Element/UiComponent/DataProvider/DataProviderutilise l'API de recherche.

Les classes suivantes sont utilisées dans cette classe:

  • Magento\Framework\Api\FilterBuilder
  • Magento\Framework\Api\Search\ReportingInterface
  • Magento\Framework\Api\Search\SearchCriteria
  • Magento\Framework\Api\Search\SearchCriteriaBuilder
  • Magento\Framework\Api\Search\SearchResultInterface

Qui sont utilisés pour filtrer / ordonner / paginer:

public function addFilter(\Magento\Framework\Api\Filter $filter)
{
    $this->searchCriteriaBuilder->addFilter($filter);
}

public function addOrder($field, $direction)
{
    $this->searchCriteriaBuilder->addSortOrder($field, $direction);
}

public function setLimit($offset, $size)
{
    $this->searchCriteriaBuilder->setPageSize($size);
    $this->searchCriteriaBuilder->setCurrentPage($offset);
}

Et aussi évidemment pour la recherche:

public function getData()
{
    return $this->searchResultToOutput($this->getSearchResult());
}

protected function searchResultToOutput(SearchResultInterface $searchResult)
{
    $arrItems = [];

    $arrItems['items'] = [];
    foreach ($searchResult->getItems() as $item) {
        $itemData = [];
        foreach ($item->getCustomAttributes() as $attribute) {
            $itemData[$attribute->getAttributeCode()] = $attribute->getValue();
        }
        $arrItems['items'][] = $itemData;
    }

    $arrItems['totalRecords'] = $searchResult->getTotalCount();

    return $arrItems;
}

public function getSearchResult()
{
    return $this->reporting->search($this->getSearchCriteria());
}

Ce qui est intéressant si cela Magento/Ui/DataProvider/AbstractDataProvidermentionne l'API de recherche mais ne l'utilisez pas du tout:

public function getSearchCriteria()
{
    //TODO: Technical dept, should be implemented as part of SearchAPI support for Catalog Grids
    return null;
}

public function getSearchResult()
{
    //TODO: Technical dept, should be implemented as part of SearchAPI support for Catalog Grids
    return $this->getCollection();
}

Maintenant, si vous vérifiez l'historique de ces fichiers dans GitHub, voici ce que vous obtenez:

Comme vous pouvez le voir, la plupart des validations pour ces deux fichiers sont liées au ticket interne suivant: MAGETWO-39905: UI components compatibility with Search API

Même si cela a été fait pour le Magento/Frameworkfichier, cela n'a jamais été fait pour le Magento/Uifichier.

En dehors de cela, je ne vois aucune différence entre ces fichiers. L'un travaille directement sur la collection, l'autre utilise l'API de recherche pour générer les résultats.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.