Tak więc Magento 2 wprowadziło komponenty interfejsu użytkownika.

Jednym z nich jest siatka składników interfejsu użytkownika (więcej informacji na ten temat można znaleźć tutaj: Objaśnienie siatki składników interfejsu użytkownika w Magento 2 )

Podczas tworzenia niestandardowego modułu trzymałem się starej metody Magento 1, utworzyłem Grid.phpplik, który obsługuje moją siatkę adminhtml.

Zastanawiam się, jakie są zalety korzystania z siatki komponentów interfejsu użytkownika zamiast Grid.phpmetody?

Wymienię te, które do tej pory znalazłem.

• rozciągliwość. Możesz dodać nowy plik XML, aby dodać nowe kolumny.
• konfiguracja za pomocą kodu. Mniej kodu dla logiki, więcej deklaratywnych plików XML.
• mniejszy ruch w sieci. Plik xml jest przekształcany w plik json i wysyłany do przeglądarki. Również każdy typ pola jest wysyłany tylko raz do przeglądarki, a generowanie formularzy odbywa się na kliencie.
• nowy system umożliwia zmianę kolejności kolumn i zapisywanie stanu.

Poza tematem: Mam „informacje wewnętrzne”, że plan polega na przeniesieniu wszystkich siatek i formularzy do komponentów interfejsu użytkownika. Więc powinieneś zacząć ich używać.

@ raphael-at-digital-pianism poprosił mnie o opublikowanie tej listy rzeczy, które moim zdaniem są niepoprawne z komponentem administracyjnym grid grid XML, więc oto:

Co jest nie tak z administracyjnym składnikiem interfejsu grid grid XML?

• Wolny cykl sprzężenia zwrotnego podczas tworzenia
• Ciężko zrozumieć
• Trudno debugować, jeśli coś pójdzie nie tak (głównie przez porównanie z XML w rdzeniu)
• Ujawniono wiele szczegółów implementacji
• Zachęca do kopiowania i wklejania
• XML nie był przeznaczony dla ludzi do czytania i pisania
• Trudne do przetestowania
• Nie jest jasne, jakie inne opcje są dostępne
• Dużo bojlera ORAZ magii (najgorsze z obu światów)
• W połączeniu z pomysłem wyświetlania danych tabeli DB
• Wiele zduplikowanych ciągów nazw w pliku

„Wymyśl lepsze rozwiązanie”, mówisz?

Cóż, nie mam. Ale tutaj jest przybliżony pomysł, jak ja, jako programista, chciałbym móc tworzyć siatki i formularze adminhtml.

• Utwórz implementację GridDataSourceInterface
• Komponent grid używa GridDataSourceInterface::getGridItemType()metody do pobrania nazwy klasy lub nazwy interfejsu
• Interfejs jest odzwierciedlony, a wszystkie moduły pobierające służą do określania możliwych kolumn
• Typy kolumn są wywnioskowane z typów zwracanych
• Typy, których nie można automatycznie wywnioskować, ponieważ prawidłowe typy kolumn są ignorowane.
• GridDataSourceInterfaceInstancja realizacja może być używana do konfiguracji innych niż domyślne widoczności i kolumnowych typów wykorzystaniem ciekawych metod opisowych, gdzie potrzebne.

Korzyści:

• Wspomagana przez IDE definicja siatek (i formularzy) poprzez autouzupełnianie metod
• Rozsądne wartości domyślne
• Wdrożenie agnostyczne
• W przypadku prostych jednostek trzeba byłoby napisać bardzo mało kodu
• W porównaniu z podejściem XML, bez utraty funkcji
• Rozszerzalność za pomocą przechwytywaczy
• Jeśli interfejsy klas są gotowe, definiowanie siatek i formularzy może być tak samo deklaratywne jak XML (ale znacznie prostsze)
• Pasuje do „sposobu myślenia” Magento 2s dla klas kontraktów serwisowych
• Nie wymaga zmiany bieżącej interakcji z kodem frontendu (taki sam ruch przez drut)
• Sortowanie i konfiguracja kolumn interfejsu użytkownika może nadal działać tak jak teraz
• NIE MOAR XML

Jeśli chodzi o pierwotne pytanie, nie sądzę, aby przy użyciu starego stylu Magento 1, bloki do budowania adminhtml były odpowiednie.
Jestem tylko zwolennikiem nowej deklaracji siatki opartej na XML, która powinna zostać jak najszybciej zastąpiona czymś lepszym.