Magento 2: quels sont les avantages de l'utilisation de composants de grille d'interface utilisateur par rapport au Grid.php standard?

23

Magento 2 a donc introduit les composants de l'interface utilisateur.

L'un d'eux est la grille de composants UI (vous pouvez trouver plus d'informations à ce sujet ici: Explication de la grille de composants UI dans Magento 2 )

Lors de la création d'un module personnalisé, je m'en suis tenu à l'ancienne méthode Magento 1, j'ai créé un Grid.phpfichier qui gère ma grille adminhtml.

Je me demande quels sont les avantages d'utiliser la grille des composants de l'interface utilisateur au lieu de la Grid.phpméthode?

magento2 module grid magento-2.0 uicomponent Raphael chez Digital Pianism
la source

Réponses:

23

Je vais énumérer celles que j'ai trouvées jusqu'à présent.

  • extensibilité. Vous pouvez ajouter un nouveau xml afin d'ajouter de nouvelles colonnes.
  • configuration sur code. Moins de code pour la logique, plus de xml déclaratifs.
  • moins de trafic sur le réseau. Le xml est transformé en json et envoyé au navigateur. De plus, chaque type de champ n'est envoyé qu'une seule fois au navigateur et la génération du formulaire se produit sur le client.
  • le nouveau système permet la réorganisation des colonnes et la sauvegarde de l'état.

Hors sujet: j'ai obtenu des "informations internes" indiquant que le plan consiste à déplacer toutes les grilles et formulaires vers les composants de l'interface utilisateur. Vous devez donc commencer à les utiliser.

Marius
la source
Pas un sujet hors sujet qui est une excellente info, exactement le genre de commentaires dont j'ai besoin
Raphael au Digital Pianism
@Raphael vous pouvez enregistrer des signets par ui_component. Configuration via xml Plus de détails que vous pouvez voir dans la table
ui_bookmark
22

@ raphael-at-digital-pianism m'a demandé de publier cette liste de choses que je pense être incorrectes avec le composant XML de l'interface utilisateur de la grille adminhtml, alors voici:

Quel est le problème avec le composant XML de l'interface utilisateur de la grille adminhtml?

  • Cycle de rétroaction lent pendant le développement
  • Difficile à comprendre
  • Difficile à déboguer si quelque chose ne va pas (principalement en se comparant au XML dans le noyau)
  • De nombreux détails de mise en œuvre exposés
  • Encourage le copier-coller
  • XML n'était pas destiné aux humains pour lire et écrire
  • Difficile à tester
  • Pas clair quelles autres options sont disponibles
  • Beaucoup de passe-partout ET de magie (le pire des deux mondes)
  • Couplé à l'idée d'afficher des données de table DB
  • Beaucoup de chaînes de noms dupliquées dans le fichier

"Trouvez une meilleure solution" dites-vous?

Et bien non. Mais voici une idée approximative de la façon dont, en tant que développeur, j'aimerais pouvoir créer des grilles et des formulaires adminhtml.

  • Créer une implémentation de GridDataSourceInterface
  • Le composant de grille utilise un GridDataSourceInterface::getGridItemType() méthode pour récupérer un nom de classe ou un nom d'interface
  • L'interface est réfléchie et tous les getters sont utilisés pour déterminer les colonnes possibles
  • Les types de colonnes sont déduits des types de retour
  • Les types qui ne peuvent pas être automatiquement déduits comme types de colonnes valides sont ignorés.
  • L' GridDataSourceInterfaceinstance d'implémentation peut être utilisée pour configurer des types de visibilité et de colonne non par défaut en utilisant de belles méthodes descriptives si nécessaire.

Les avantages:

  • Définition assistée par IDE des grilles (et formulaires) par autocomplétion de méthode
  • Valeurs par défaut sensibles
  • Indépendant de la mise en œuvre
  • Pour les entités simples, très peu de code devrait être écrit
  • Par rapport à l'approche XML, aucune perte de fonctionnalités
  • Extensibilité via des intercepteurs
  • Si les interfaces de classe sont terminées, la définition des grilles et des formulaires peut également être tout aussi déclarative que XML (mais beaucoup plus simple)
  • Correspond à la "façon de penser" de Magento 2 pour les classes de contrat de service
  • Aucun changement à l'interaction actuelle avec le code frontal requis (même trafic sur le câble)
  • Le tri et la configuration des colonnes frontales peuvent continuer de fonctionner comme ils le font actuellement
  • NO MOAR XML

En ce qui concerne la question d'origine, je ne pense pas que l'utilisation de l'ancien style Magento 1, des blocs pour construire des interfaces adminhtml, soit la bonne chose à faire.
Je préconise seulement que la nouvelle déclaration de grille basée sur XML soit remplacée par quelque chose de mieux aussi rapidement que possible.

Vinai
la source
? c'est vrai que difficile à comprendre component.Are UI que vous pensiez magento viendra avec une autre solution sur l' avenir i composant grille interface utilisateur .Il devient tête Cache pour moi ....... Donot trouver un blog approprié (:
Amit Bera