Так Magento 2 представив компоненти інтерфейсу користувача.

Однією з них є сітка компонентів користувальницького інтерфейсу (додаткову інформацію про неї можна знайти тут: Пояснення сітки компонентів інтерфейсу в Magento 2 )

Створюючи спеціальний модуль, я дотримувався старого методу Magento 1, я створив Grid.phpфайл, який обробляє мою сітку adminhtml.

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

Я перелічу тих, кого я знайшов поки що.

• розширюваність. Ви можете додати новий xml, щоб додати нові стовпці.
• конфігурація коду. Менше коду для логіки, більше декларативних xmls.
• менше трафіку по мережі. Xml перетворюється в json і надсилається до браузера. Також кожен тип поля надсилається лише один раз до браузера, і генерування форми відбувається у клієнта.
• нова система дозволяє упорядкувати стовпці та зберегти стан.

Off topic: Я зрозумів "всередині інформації", що план полягає в тому, щоб перемістити всі сітки та форми на компоненти інтерфейсу користувача. Тож варто почати їх використовувати.

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

Що не так з компонентом інтерфейсу інтерфейсу користувача XML XML?

• Повільний цикл зворотного зв'язку під час розробки
• Важко зрозуміти
• Важко налагодити, якщо щось піде не так (в основному лише шляхом порівняння з XML в ядрі)
• Більш детально розкрито реалізацію
• Заохочує копіювати та вставляти
• XML не призначався людям для читання та письма
• Важко перевірити
• Не ясно, які інші варіанти є
• Багато котла та магії (найгірше з обох світів)
• У поєднанні з ідеєю відображення даних таблиці БД
• У файлі багато дублюваних рядків імен

"Придумайте краще рішення", говорите ви?

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

• Створіть реалізацію GridDataSourceInterface
• Компонент сітки використовує GridDataSourceInterface::getGridItemType()метод для отримання імені класу або імені інтерфейсу
• Інтерфейс відображається і всі гетери використовуються для визначення можливих стовпців
• Типи стовпців виводяться з типів повернення
• Типи, які не можна автоматично зробити як правильні типи стовпців, ігноруються.
• GridDataSourceInterfaceПримірник реалізації може бути використаний для настройки не за замовчуванням видимості стовпців і типів , використовуючи хороші описові методи , де це необхідно.

Переваги:

• Визначення сіток (та форм) за допомогою IDE за допомогою методу автодоповнення
• Розумні значення за замовчуванням
• Реалізація агностик
• Для простих утворень потрібно було б написати дуже мало коду
• Порівняно з XML-підходом, функцій немає втрати
• Розширюваність за допомогою перехоплювачів
• Якщо інтерфейси класів зроблені, то визначення сіток і форм також може бути таким же декларативним, як і XML (але набагато простіше)
• Відповідає Magento 2s "спосіб мислення" для класів контрактів на обслуговування
• Не потрібно змінювати поточну взаємодію з кодом прямої лінії (той же трафік по дроту)
• Сортування та конфігурація стовпців Frontend можуть продовжувати працювати так само, як зараз
• NO MOAR XML

Що стосується оригінального питання, я не думаю, що використання старого стилю Magento 1 блокує побудову інтерфейсів адміністрування, як правильно.
Я лише прихильник того, що нове декларація на базі XML має бути замінено якомога кращим.