Also führte Magento 2 die UI-Komponenten ein.

Eines davon ist das UI Component Grid (weitere Informationen dazu finden Sie hier: Erklärung des UI Component Grid in Magento 2 )

Beim Erstellen eines benutzerdefinierten Moduls habe ich mich an die alte Magento 1-Methode gehalten und eine Grid.phpDatei erstellt, die mein adminhtml-Raster behandelt.

Ich frage mich, welche Vorteile die Verwendung des UI-Komponentenrasters anstelle der Grid.phpMethode hat.

Ich werde die auflisten, die ich bisher gefunden habe.

• Erweiterbarkeit. Sie können eine neue XML hinzufügen, um neue Spalten hinzuzufügen.
• Konfiguration über Code. Weniger Code für Logik, mehr deklarative XMLs.
• weniger Verkehr über das Netzwerk. Die XML-Datei wird in einen JSON-Code umgewandelt und an den Browser gesendet. Außerdem wird jeder Feldtyp nur einmal an den Browser gesendet und die Formularerstellung erfolgt auf dem Client.
• Das neue System ermöglicht das Umordnen von Spalten und das Speichern des Status.

Off Topic: Ich habe "inside info" erhalten, dass der Plan ist, alle Grids und Formulare in UI-Komponenten zu verschieben. Sie sollten sie also verwenden.

@ raphael-at-digital-pianism hat mich gebeten, diese Liste mit Dingen zu veröffentlichen, die meiner Meinung nach mit der XML-Komponente der Benutzeroberfläche des Admin-HTML-Grids nicht in Einklang stehen.

Was ist los mit der XML-Komponente der AdminHTML-Raster-Benutzeroberfläche?

• Langsamer Rückkopplungszyklus während der Entwicklung
• Schwer zu verstehen
• Schwer zu debuggen, wenn etwas schief geht (meist nur durch Vergleich mit XML im Kern)
• Viele Implementierungsdetails werden offengelegt
• Ermutigt zum Kopieren und Einfügen
• XML war nicht für Menschen zum Lesen und Schreiben gedacht
• Schwer zu testen
• Nicht klar, welche anderen Optionen verfügbar sind
• Viel Boilerplate UND Magie (das Schlimmste von beiden Welten)
• Verbunden mit der Idee, DB-Tabellendaten anzuzeigen
• Viele doppelte Namensstrings in der Datei

"Komm mit einer besseren Lösung", sagst du?

Nun, ich habe nicht. Aber hier ist eine grobe Vorstellung, wie ich als Entwickler in der Lage sein möchte, Admin-HTML-Grids und -Formulare zu erstellen.

• Erstellen Sie eine Implementierung von GridDataSourceInterface
• Die Grid-Komponente verwendet eine GridDataSourceInterface::getGridItemType()Methode, um einen Klassen- oder Schnittstellennamen abzurufen
• Die Schnittstelle wird reflektiert und alle Getter werden verwendet, um die möglichen Spalten zu bestimmen
• Spaltentypen werden aus den Rückgabetypen abgeleitet
• Typen, die nicht automatisch als gültige Spaltentypen abgeleitet werden können, werden ignoriert.
• Die GridDataSourceInterfaceImplementierungsinstanz kann verwendet werden, um nicht standardmäßige Sichtbarkeits- und Spaltentypen zu konfigurieren, wobei bei Bedarf nützliche beschreibende Methoden verwendet werden.

Die Vorteile:

• IDE-unterstützte Definition von Gittern (und Formularen) durch automatische Vervollständigung von Methoden
• Sinnvolle Vorgaben
• Implementierungsunabhängig
• Für einfache Entitäten müsste nur sehr wenig Code geschrieben werden
• Im Vergleich zum XML-Ansatz kein Funktionsverlust
• Erweiterbarkeit über Abfangjäger
• Wenn die Klassenschnittstellen fertig sind, kann das Definieren von Gittern und Formularen genauso aussagekräftig sein wie XML (aber viel einfacher).
• Entspricht der "Denkweise" von Magento 2 für Servicevertragsklassen
• Keine Änderung der aktuellen Interaktion mit dem Frontend-Code erforderlich (gleicher Datenverkehr über die Leitung)
• Die Sortierung und Konfiguration der Frontend-Spalten funktioniert weiterhin wie bisher
• KEIN MOAR XML

In Bezug auf die ursprüngliche Frage denke ich nicht, dass die Verwendung des alten Magento 1-Stils zum Erstellen von Admin-HTML-Schnittstellen das Richtige ist.
Ich befürworte nur, dass die neue XML-basierte Grid-Deklaration so schnell wie möglich durch etwas Besseres ersetzt werden sollte.