Magento 2: Dlaczego składnik listingu interfejsu użytkownika potrzebuje dwóch kolekcji?

Magento 2 ma nową uiComponentfunkcję „ ”. Umożliwia to dołączenie prostego <uiComponent/>znacznika do plików XML obsługi układu, aby dodać takie rzeczy, jak siatki i formularze do strony aplikacji.

To wydaje się , że konfiguracja dla siatki danych (A listing) wymaga dwóch obiektów kolekcja być skonfigurowany.

Jaka jest rola każdej kolekcji konfiguracji poniżej? Czy też źle rozumiem role tych kolekcji? Czy istnieje sposób na utworzenie obiektu siatki za pomocą tylko jednej kolekcji?

Poniższa konfiguracja konfiguruje komponent interfejsu użytkownika o nazwie cms_page_listing

vendor/magento/module-cms/view/adminhtml/ui_component/cms_page_listing.xml

I następujący wtrysk DI mówi Magento, że cms_page_listingnależy użyć Magento\Cms\Model\ResourceModel\Page\Grid\Collectionkolekcji.

<type name="Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory">
    <arguments>
        <argument name="collections" xsi:type="array">
            <item name="cms_page_listing_data_source" xsi:type="string">Magento\Cms\Model\ResourceModel\Page\Grid\Collection</item>
        </argument>
    </arguments>
</type>

Wydaje się, że jest to główna kolekcja używana do zapełniania siatki.

Jednak jest to również PageGridDataProviderw cms_page_listingkonfiguracji.

<!-- File: vendor/magento/module-cms/view/adminhtml/ui_component/cms_page_listing.xml -->
    <argument name="dataProvider" xsi:type="configurableObject">
        <argument name="class" xsi:type="string">PageGridDataProvider</argument>
        <argument name="name" xsi:type="string">cms_page_listing_data_source</argument>
        <argument name="primaryFieldName" xsi:type="string">page_id</argument>
        <argument name="requestFieldName" xsi:type="string">id</argument>
        <argument name="data" xsi:type="array">
            <item name="config" xsi:type="array">
                <item name="update_url" xsi:type="url" path="mui/index/render"/>
            </item>
        </argument>
    </argument>

W PageGridDataProviderpostanawia o virtualType

<virtualType name="PageGridDataProvider" type="Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider">
    <arguments>
        <argument name="collection" xsi:type="object" shared="false">Magento\Cms\Model\ResourceModel\Page\Collection</argument>
        <argument name="filterPool" xsi:type="object" shared="false">CmsGirdFilterPool</argument>
    </arguments>
</virtualType>

Ten typ wirtualny konfiguruje drugą kolekcję ( Magento\Cms\Model\ResourceModel\Page\Collection).

Nie jest jasne, dlaczego ta druga konfiguracja jest potrzebna ani jaka jest jej rola w tworzeniu siatki. Pytanie wyższego poziomu brzmi prawdopodobnie, jaką rolę dataProviderodgrywa tworzenie siatki interfejsu użytkownika . Większe, większe pytanie dotyczy prawdopodobnie tego, jakie obiekty PHP są tworzone w celu utworzenia siatki listingu interfejsu użytkownika i jak kontroluje je konfiguracja

Oto szybka odpowiedź na pierwsze pytanie:

Konfiguracja typu wirtualnego nie jest wymagana. Jeśli spojrzysz na to, Magento\Framework\View\Element\UiComponent\DataProvider\DataProviderzobaczysz, że żaden z tych dwóch argumentów nie jest używany („kolekcja”, jak również „filterPool”).

Nieużywaną konfigurację usuniemy jak najszybciej. Tak więc deklaracja wyników typów wirtualnych dostawców danych powinna być tak prosta:

dla stron CMS:

<virtualType name="PageGridDataProvider" type="Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider"/>

i dla bloków CMS

<virtualType name="PageGridDataProvider" type="Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider"/>

Jak widać, w plikach konfiguracyjnych Komponentów interfejsu użytkownika nie jest wymagane używanie typu wirtualnego dostawcy danych i można odwoływać się do dostawcy danych ogólnych Magento\Framework\View\Element\UiComponent\DataProvider\DataProvider. Zdecydowaliśmy się na użycie typu wirtualnego, aby zapewnić programistom kolejny punkt rozszerzenia.