In diesem Beitrag tauchen wir ein, wie man die Kraft von Edge Delivery Services und Document Authoring nutzen kann, um eine dynamische Liste von Elementen aus einer Tabelle in DA zu erstellen.

Es gibt einen großen Unterschied zwischen dem Dumpen einer Liste von Links auf einer Seite und der Kuratierung von etwas wirklich Brauchbarem. Dieses Projekt begann mit "wir brauchen nur eine Liste von URLs und Beschreibungen", entwickelte sich aber schnell zur Lösung einiger echter Probleme: Inhalte wartbar halten, DOM-Überblähung vermeiden und das Filtern schnell machen, ohne es zu überdimensionieren.

Das Ergebnis ist der Block Reference List ; ein datengesteuertes, filterbares Kartenraster für Adobe Edge Delivery Services (EDS), das Inhalte aus einem tabellengestützten JSON-Feed zieht, Kategorien- und Tag-Filterung unterstützt und Ergebnisse schrittweise mit ausgefeilten Animationen lädt. Wir haben sie speziell entwickelt, um diese Edge Delivery Services-Referenzseite zu vertreiben, die ihr alle schon als Lesezeichen gespeichert habt!

Die Tabelle alles steuern lassen

Der Block ist vollständig datengesteuert. Es ruft eine JSON-Datei ab, die von einem EDS-Blatt bei /en/reference-links.jsongeneriert wird. Wir entschieden uns für ein Multi-Sheet-Format; Ein Blatt für Referenzpunkte, eines für Kategorien:

{
  "data": {
    "data": [
      {
        "url": "https://developer.adobe.com/",
        "image-url": "https://example.com/thumb.png",
        "title": "Adobe Developer Documentation",
        "description": "Official docs for building on Adobe platforms.",
        "tag": "Documentation|Official",
        "category": "Development"
      }
    ]
  },
  "categories": {
    "data": [{ "Category": "Development", "Description": "Dev tools and references" }]
  }
}

Die Tags verwenden Pipes innerhalb der Zelle (Tag1 | Tag2), was das Schreiben einfach und vorhersehbar hält.

Wenn du diesen Block erstellst, solltest du sicher einige Tests machen, bevor du ihn live pushst. Wenn du nur die ausgefüllte Liste innerhalb von DA hast, wirst du beim lokalen Testen wahrscheinlich auf Cross-Origin Resource Sharing (CORS)-Probleme stoßen. Um das zu beheben, erstellen Sie einfach Ihre eigene JSON-Datei mit einigen Testeinträgen, die die gleichen Anforderungen wie das DA-Sheet erfüllen, und aktivieren Sie die lokale JSON-Nutzung.

const USE_LOCAL_JSON = false;
const LOCAL_JSON_PATH = '/tools/json/reference-list.json';
const LIVE_JSON_URL = '/en/reference-links.json';

Karten bauen, die nicht kaputtgehen

Jedes Referenzelement wird zu einer Karte mit dieser DOM-Struktur:

.reference-card
  └── a.reference-link
        ├── div.reference-image-wrapper   (optional)
        │     └── img.reference-image
        └── div.reference-content
              ├── h3.reference-title
              ├── p.reference-description  (optional)
              └── div.reference-tags
                    └── span.reference-tag (one per tag)

Beim Bau eines Blocks ist eines der wichtigsten Dinge, die man bedenken sollte, wie einfach ein Autor ihn nutzen kann. Zu diesem Zweck mussten wir sicherstellen, dass die Liste unterschiedliche Informationsmengen verarbeiten und dennoch gleich funktionieren kann. Manche haben Beschreibungen, Tags oder beides nicht. Die Regel war, nur das Vorhandene zu rendern, aber das Layout sollte nicht davon abhängen, dass ein einzelnes Stück vorhanden ist. Einige konkrete Entscheidungen:

Die Liste filtern, ohne die Welt neu aufzubauen

Wenn man überlegt, wie man filtert, kann es manchmal chaotisch werden, besonders beim erneuten Rendern bei jeder Interaktion. Um das zu vermeiden, haben wir von Anfang an darauf geachtet, die Attribute jeder Karte einzustellen, damit sie eher zu einem Sichtbarkeitsschalter wird.

card.setAttribute('data-category', ref.category);
card.setAttribute('data-tags', JSON.stringify(cardTags));

Wir haben außerdem eine Funktion namens updateReferenceDisplay hinzugefügt, um die Sichtbarkeit bei jeder Interaktion neu zu bewerten:

const categoryMatch = selectedCategory === 'all' || cardCategory === selectedCategory;
const tagMatch = cardTags.length === 0 || cardTags.some((tag) => activeTags.has(tag));

Tag-Matching verwendet OR-Logik, jeder ausgewählte Tag qualifiziert eine Karte. Aktive Tags befinden sich in einem Set, daher sind Hinzufügen/Entfernen und Mitgliedschaftsprüfungen alle O(1). Ein subtiler Randfall: unmarkierte Gegenstände. Wenn sie immer den Tag-Filter passieren konnten, verschwinden sie nie unerwartet.

CSS macht mehr als erwartet

Auch wenn dies nicht unbedingt ein Blog über Styling ist, wäre es mir nachlässig, wenn ich einige der Entscheidungen, die wir in dieser Hinsicht getroffen haben, nicht erwähnen würde. Vor allem was den "Spotlight"-Effekt betrifft, wenn eine Karte schwebt.

.reference-grid:has(.reference-card:hover) .reference-card:not(:hover) {
  transform: scale(0.9);
  opacity: 0.6;
}

Die Fade-in-Animation folgt demselben Ansatz, sodass es keinen Koordinationsaufwand zwischen JS und Stilen gibt:

.reference-card { opacity: 0; }

.reference-card.fade-in {
  opacity: 1;
  animation: fade-in-up 0.5s ease-out forwards;
}

@keyframes fade-in-up {
  from { transform: translateY(20px); }
  to   { transform: translateY(0); }
}

Abschließende Gedanken

Dieses Projekt ist ein starkes Beispiel dafür, wie durchdachte Architektur ein gemeinsames Muster in etwas wirklich Skalierbares verwandelt. Indem die Verantwortung in strukturierte Daten verlagert und das Frontend auf effizientes Rendering und Zustandsmanagement fokussiert bleibt, vermeidet der Referenzlistenblock die üblichen Fallstricke aufgeblähter DOMs und teurer Neurenderungen.

Der eigentliche Wert liegt nicht nur in der Filterung oder Präsentation, sondern im System selbst. Autoren erhalten eine vorhersehbare, reibungslose Art der Inhaltsverwaltung, während die Implementierung leistungsfähig bleibt und leicht zu erweitern ist. Es ist ein Muster, das mit wachsendem Inhalt Bestand hat und nicht jedes Mal neu aufgegriffen werden muss.

Sehen Sie die Referenzseite in Aktion!

Über den Autor

Noah Mattison

Technischer Lieferleiter bei Arbory Digital

Noah ist Absolvent der Informatik an der UNC Wilmington und zweifach zertifizierter AEM-Entwickler. Ursprünglich auf einem vormedizinischen Weg mit Leidenschaft für Krebserkennung und KI, bringt er eine problemlösende Denkweise in seine Arbeit bei Arbory ein. Er hilft bei der Planung der Projektausführung, delegiert die Arbeit über Teams hinweg, pflegt eine starke Kommunikation und unterstützt interne Abläufe. Er glaubt an die Gemeinschaft und Vision von Arbory und ist außerhalb der Arbeit umweltbewusst und genießt es, draußen aktiv zu bleiben, unter anderem beim Campen, Surfen und Klettern.

Kontaktieren Sie Noah auf LinkedIn

Gefällt dir, was du gehört hast? Haben Sie Fragen dazu, was für Sie am besten ist? Wir würden uns sehr freuen! Kontaktieren Sie uns

Mehr Artikel, die Ihnen gefallen könnten

category
AEM Technical Help
tags
AEM
number of rows
1