Итак, Magento 2 представил компоненты пользовательского интерфейса.

Одним из них является Grid Component Grid (вы можете найти больше информации об этом здесь: Объяснение UI Component Grid в Magento 2 )

При создании пользовательского модуля я придерживался старого метода Magento 1, я создал Grid.phpфайл, который обрабатывает мою сетку adminhtml.

Мне интересно, каковы преимущества использования сетки компонентов пользовательского интерфейса вместо Grid.phpметода?

Я перечислю те, которые я нашел до сих пор.

• расширяемость. Вы можете добавить новый XML для добавления новых столбцов.
• Конфигурация поверх кода. Меньше кода для логики, больше декларативных xmls.
• меньше трафика по сети. XML преобразуется в JSON и отправляется в браузер. Также каждый тип поля отправляется только один раз в браузер, и генерация формы происходит на клиенте.
• новая система позволяет переупорядочивать столбцы и сохранять состояние.

Не по теме: я получил "внутреннюю информацию", что план состоит в том, чтобы переместить все сетки и формы в компоненты пользовательского интерфейса. Поэтому вы должны начать использовать их.

@ raphael-at-digital-pianism попросил меня опубликовать этот список вещей, которые я считаю неправильными в XML-компоненте интерфейса администратора adminhtml, так что здесь:

Что не так с компонентом adminhtml Grid UI XML?

• Медленный цикл обратной связи во время разработки
• Трудно понять
• Трудно отлаживать, если что-то идет не так (в основном, только по сравнению с XML в ядре)
• Многое раскрыто в деталях реализации
• Призывает копировать и вставлять
• XML не предназначен для людей, чтобы читать и писать
• Трудно проверить
• Не ясно, какие другие варианты доступны
• Много шаблонов И магии (худшее из обоих миров)
• В сочетании с идеей отображения данных таблицы БД
• Много дублированных строк имени в файле

«Придумай лучшее решение», говорите вы?

Ну, нет. Но вот приблизительное представление о том, как я, как разработчик, хотел бы иметь возможность создавать сетки и формы adminhtml.

• Создать реализацию GridDataSourceInterface
• Компонент grid использует GridDataSourceInterface::getGridItemType()метод для получения имени класса или имени интерфейса
• Интерфейс отражается и все геттеры используются для определения возможных столбцов
• Типы столбцов выводятся из возвращаемых типов
• Типы, которые не могут быть автоматически выведены в качестве допустимых типов столбцов, игнорируются.
• GridDataSourceInterfaceЭкземпляр реализации может быть использован для настройки не по умолчанию видимости столбцов и типов , используя хорошие описательные методы , где это необходимо.

Выгоды:

• IDE помогает определение сеток (и форм) через автозаполнение метода
• Разумные значения по умолчанию
• Реализация агностика
• Для простых объектов нужно написать очень мало кода
• По сравнению с подходом XML, без потери возможностей
• Расширяемость с помощью перехватчиков
• Если интерфейсы классов выполнены, определение сеток и форм также может быть таким же декларативным, как XML (но гораздо более простым)
• Соответствует «образу мышления» Magento 2s для классов контрактов на обслуживание
• Никаких изменений в текущем взаимодействии с кодом внешнего интерфейса не требуется (такой же трафик по сети)
• Сортировка и настройка внешнего интерфейса могут работать так же, как и сейчас.
• NO MOAR XML

Что касается первоначального вопроса, я не думаю, что использование старого стиля Magento 1, блоков для создания интерфейсов adminhtml, является правильным решением.
Я только защищаю, что новое объявление сетки на основе XML должно быть заменено чем-то лучшим как можно быстрее.