Quindi Magento 2 ha introdotto i componenti dell'interfaccia utente.

Una di queste è la griglia dei componenti dell'interfaccia utente (puoi trovare maggiori informazioni qui: Spiegazione della griglia dei componenti dell'interfaccia utente in Magento 2 )

Durante la creazione di un modulo personalizzato, mi sono attenuto al vecchio metodo Magento 1, ho creato un Grid.phpfile che gestisce la mia griglia adminhtml.

Mi chiedo quali sono i vantaggi dell'utilizzo della griglia dei componenti dell'interfaccia utente anziché del Grid.phpmetodo?

Elencherò quelli che ho trovato finora.

• estensibilità. È possibile aggiungere un nuovo XML per aggiungere nuove colonne.
• configurazione tramite codice. Meno codice per la logica, xmls più dichiarativi.
• meno traffico sulla rete. Il file XML viene trasformato in json e inviato al browser. Inoltre, ogni tipo di campo viene inviato una sola volta al browser e la generazione del modulo avviene sul client.
• il nuovo sistema consente il riordino delle colonne e il salvataggio dello stato.

Fuori tema: ho ottenuto "informazioni interne" che il piano prevede di spostare tutte le griglie e i moduli nei componenti dell'interfaccia utente. Quindi dovresti iniziare a usarli.

@ raphael-at-digital-pianism mi ha chiesto di pubblicare questo elenco di cose che ritengo errate con il componente XML dell'interfaccia utente della griglia adminhtml, quindi ecco:

Cosa c'è di sbagliato nell'XML del componente dell'interfaccia utente della griglia adminhtml?

• Ciclo di feedback lento durante lo sviluppo
• Difficile da capire
• Difficile eseguire il debug se qualcosa va storto (principalmente confrontandolo con XML nel core)
• Sono stati esposti molti dettagli di implementazione
• Incoraggia copia e incolla
• XML non era pensato per essere letto e scritto dagli umani
• Difficile da testare
• Non deselezionare quali altre opzioni sono disponibili
• Un sacco di boilerplate E magia (il peggio di entrambi i mondi)
• Associato all'idea di visualizzare i dati della tabella DB
• Molte stringhe di nomi duplicate nel file

"Trova una soluzione migliore" dici?

Beh, non l'ho fatto. Ma ecco un'idea approssimativa di come io, come sviluppatore, vorrei essere in grado di creare griglie e moduli di amministrazione.

• Creare un'implementazione di GridDataSourceInterface
• Il componente griglia utilizza un GridDataSourceInterface::getGridItemType()metodo per recuperare un nome di classe o un nome di interfaccia
• L'interfaccia viene riflessa e tutti i getter vengono utilizzati per determinare le possibili colonne
• I tipi di colonna sono dedotti dai tipi restituiti
• I tipi che non possono essere dedotti automaticamente come tipi di colonna validi vengono ignorati.
• L' GridDataSourceInterfaceistanza di implementazione può essere utilizzata per configurare la visibilità e i tipi di colonna non predefiniti utilizzando metodi descrittivi utili ove necessario.

I benefici:

• Definizione assistita da IDE di griglie (e moduli) mediante il completamento automatico del metodo
• Impostazioni predefinite sensibili
• Implementazione agnostica
• Per entità semplici sarebbe necessario scrivere solo pochissimo codice
• Rispetto all'approccio XML, nessuna perdita di funzionalità
• Estendibilità tramite intercettori
• Se le interfacce di classe vengono eseguite, la definizione di griglie e moduli può anche essere dichiarativa come XML (ma molto più semplice)
• Corrisponde al "modo di pensare" di Magento 2 per le classi di contratto di assistenza
• Non è richiesta alcuna modifica all'interazione corrente con il codice frontend (stesso traffico sul filo)
• L'ordinamento e la configurazione delle colonne frontend possono continuare a funzionare esattamente come adesso
• NO MOAR XML

Per quanto riguarda la domanda originale, non penso che l'uso del vecchio stile Magento 1 blocchi per costruire interfacce adminhtml sia la cosa giusta da fare.
Sto solo sostenendo che la nuova dichiarazione di griglia basata su XML dovrebbe essere sostituita da qualcosa di meglio il più rapidamente possibile.