Optimizely CMS – Activation de la prise en charge du glisser-déposer pour PropertyList

d’Optimizely Listes de propriétés génériques peut être un outil utile à la fois pour les développeurs et les éditeurs de CMS, mais il comporte des limites.

Notre client nous a récemment approchés pour demander une meilleure façon d’organiser leurs listes de propriétés. Certaines de leurs listes étaient devenues assez longues et devoir déplacer des éléments d’un emplacement à la fois n’était pas une expérience agréable.

Il y a un solution existante là-bas déjà pour ceux qui ont Commerce, mais notre client est CMS uniquement.

Une connaissance de base du dojo est recommandée, mais savoir module d’aspect du dojo et le système de glisser-déposer (DnD) est nécessaire pour bien comprendre le fonctionnement de la solution.

Problèmes

Si vous n’êtes intéressé que par la solution, n’hésitez pas à ignorer cette section et allez-y directement.

Étonnamment, j’ai trouvé que DnD est déjà configuré, mais ne fonctionne pas pleinement. Les éléments PropertyList peuvent être glissés, mais pas déposés.
En déboguant le code existant, j’ai découvert que le problème est que le type PropertyList n’est pas ajouté aux types DnD autorisés.
Dans le code de l’éditeur de collection, permisDndTypes est toujours indéfini pour les PropertyLists.
epi-cms/contentediting/editors/CollectionEditor.js
Dans le code DnD pour vérifier si un dépôt est autorisé, le types acceptés pour PropertytLists est toujours défini sur textequi est juste la valeur par défaut.
epi/shell/dnd/_DndDataMixin.js

dojo/dnd/Source.js

La solution

Afin de contourner ce problème, j’ai étendu le widget dojo de base CollectionEditor. Cette solution a été testée dans CMS 11 et CMS 12.

Grâce au module d’aspect de dojo, nous pouvons intercepter la chaîne d’appels DnD là où c’est nécessaire au lieu d’essayer de forcer toute la chaîne d’appels à fonctionner avec des PropertyLists.

Ici, j’ai intercepté l’appel problématique au DnD _checkAcceptanceForItems() afin de supprimer sa valeur de retour et de renvoyer ma propre implémentation personnalisée. La partie clé est la ligne 35, où nous vérifions les éléments source par rapport au type PropertyList (self.itemType).

define('custom-scripts/Editors/PropertyListCollectionEditor', [
  // dojo core
  'dojo/_base/declare', // Used to declare the actual widget
  'dojo/_base/array',
  'dojo/aspect',

  // Optimizely
  'epi-cms/contentediting/editors/CollectionEditor', // Opti base widget to extend,
], 
function (
declare, 
array, 
aspect, 

CollectionEditor) {
  return declare([CollectionEditor], {
    _setupDnD: function () {
      // summary:
      //      Set up the dnd on the grid.
      // tags:
      //      private
      this.inherited(arguments);
      var self = this;

      self.own(
        aspect.after(
          self.grid.dndSource, // Target
          '_checkAcceptanceForItems', // Target's method to watch
          function (items, acceptedTypes) {
            // Run after target's method &
            // replace original return value with logic for PropertyLists
            return array.every(items, (item) => {
              return self.itemType.toLowerCase() === item.data.typeIdentifier;
            });
          },
          true, // Receive target method's original arguments
        ),
      );
    },
  });
});

Après cela, j’ai créé un descripteur d’éditeur pour utiliser le nouveau widget comme classe d’édition.

public class PropertyListEditorDescriptor<T> : CollectionEditorDescriptor<T> where T : new()
{
       public PropertyListEditorDescriptor()
       {
               ClientEditingClass = "custom-scripts/Editors/PropertyListCollectionEditor";
       }
}

Maintenant, pour activer la prise en charge du glisser-déposer, il me suffit d’utiliser PropertyListEditorDescriptor à la place de CollectionEditorDescriptor lors de la configuration de PropertyLists.

[EditorDescriptor(EditorDescriptorType = typeof(CollectionEditorDescriptor<Location>))]
public virtual IList<Location> Locations { get; set; }