Seminar DatoCMS: Plugin-Entwicklung mit dem Plugin SDK

Das Plugin-Seminar führt von der Erweiterungsidee über SDK-Kontext und UI-Komponenten bis zu Berechtigungen, Konfiguration, Tests, Paketierung und Versionierung. Mehrere Erweiterungspunkte werden in einem zusammenhängenden Schulungsplugin umgesetzt.

Inhaltsübersicht

Kapitelinhaltsverzeichnis

• Lernziele und Einsatzbereiche
• Vorbereitung und Arbeitsweise
• Seminarinhalte
• Praktische Übungen und Anwendung

Lernziele und Einsatzbereiche

Kapitelinhaltsverzeichnis

• Kompetenzziele
• Typische Einsatzszenarien
• Abgrenzung und Schwerpunkt

Kompetenzziele

Die Inhalte sind auf unmittelbar anwendbare, prüfbare Kompetenzen ausgerichtet.

• Geeignete Plugin-Anwendungsfälle und Erweiterungspunkte auswählen.
• Plugin-Projekt, SDK-Kontext und Konfiguration sauber strukturieren.
• Feldeditoren, Sidebars und Aktionen mit kontrolliertem Datenzugriff implementieren.
• Sicherheit, Tests, Versionierung und Rollout für den produktiven Betrieb vorbereiten.

Typische Einsatzszenarien

Das Seminar eignet sich insbesondere für die folgenden Projekt- und Betriebssituationen.

• Domänenspezifischer Feldeditor.
• Qualitätsprüfung oder Assistenz in der Record-Sidebar.
• Integration eines internen Katalog- oder Freigabedienstes.

Abgrenzung und Schwerpunkt

Die fachliche Tiefe wird durch folgende Grenzen bewusst fokussiert.

• Keine allgemeine React- oder TypeScript-Grundlagenschulung.
• Externe Dienste werden nur über sichere Demo-Schnittstellen integriert.
• Marktplatz- und Abrechnungsprozesse sind nicht Schwerpunkt.

Vorbereitung und Arbeitsweise

Kapitelinhaltsverzeichnis

• Zielgruppen
• Vorkenntnisse und Schulungsumgebung
• Didaktisches Vorgehen
• Qualitäts- und Abnahmekriterien

Zielgruppen

Frontend- und Full-Stack-Entwicklung, interne Plattformteams und technische Produktverantwortliche, die die DatoCMS-Oberfläche erweitern.

Vorkenntnisse und Schulungsumgebung

Sichere JavaScript- oder TypeScript-Kenntnisse, Komponentenentwicklung und grundlegendes Verständnis der DatoCMS-Oberfläche sowie Content Management API.

1. Schritt 1: Zugänge, Rollen und Schulungsprojekt vor Seminarbeginn kontrollieren.
2. Schritt 2: Beispieldaten, Assets, Quellmaterial oder Codebasis entsprechend dem Seminarthema bereitstellen.
3. Schritt 3: Ausgangszustand dokumentieren, damit Übungen wiederholt und Abweichungen eindeutig bewertet werden können.

Didaktisches Vorgehen

Kurze Fachblöcke werden unmittelbar mit Demonstrationen, geführten Arbeitsschritten, eigenständigen Laborphasen und kontrollierten Fehlerfällen verbunden.

1. Schritt 1: Ausgangsproblem und gewünschtes Sollverhalten präzisieren.
2. Schritt 2: Konfiguration oder Implementierung in kleinen, überprüfbaren Schritten ausführen.
3. Schritt 3: Normalfall, Grenzfall und mindestens einen Fehlerfall testen.
4. Schritt 4: Nachweis, Betriebsregel oder Checkliste aus dem Übungsergebnis ableiten.

Qualitäts- und Abnahmekriterien

• Konfigurationen und Arbeitsschritte sind reproduzierbar dokumentiert.
• Berechtigungen, Datenstände und Environments sind eindeutig voneinander getrennt.
• Positive und negative Testfälle besitzen ein erwartetes und nachvollziehbares Ergebnis.
• Fehlerzustände führen zu einer kontrollierten Diagnose und einem definierten Wiederanlauf.

Seminarinhalte

Kapitelinhaltsverzeichnis

• Plugin-Idee und Erweiterungspunkt
• Projektaufbau und lokale Entwicklung
• SDK-Kontext und Projektinformationen
• Eigener Feldeditor
• Sidebar und Record-Prüfung
• Form- und Record-Aktionen
• Plugin-Konfiguration und Mehrprojektfähigkeit
• CMA- und externe Integrationen
• Sicherheit und Datenschutz
• Tests, Packaging und Versionierung

Plugin-Idee und Erweiterungspunkt

Die Erweiterung löst ein konkretes Redaktionsproblem und wird dem kleinsten geeigneten UI-Eingriff zugeordnet.

1. Schritt 1: Problem, Nutzergruppe und Erfolgskriterium beschreiben.
2. Schritt 2: Vorhandene Standardfunktion gegen Pluginbedarf abgrenzen.
3. Schritt 3: Erweiterungspunkt und minimale erste Version festlegen.

Projektaufbau und lokale Entwicklung

Scaffolding, Konfiguration, Build und lokale Vorschau werden reproduzierbar eingerichtet.

1. Schritt 1: Projektstruktur und Abhängigkeiten anlegen.
2. Schritt 2: Lokalen Entwicklungsmodus mit Testprojekt verbinden.
3. Schritt 3: Build-, Lint- und Typprüfung als Baseline ausführen.

SDK-Kontext und Projektinformationen

Plugin-Code liest nur die benötigten Informationen aus Kontext, Feld, Record und Projekt.

1. Schritt 1: Benötigte Kontextwerte inventarisieren.
2. Schritt 2: Typisierten Zugriff kapseln.
3. Schritt 3: Fehlende oder unerwartete Kontextwerte als Fehlerfall behandeln.

Eigener Feldeditor

Ein Feldeditor führt Nutzende durch eine domänenspezifische Eingabe und schreibt validierte Werte zurück.

1. Schritt 1: Wertformat und Validierungsregeln definieren.
2. Schritt 2: Editorzustand und SDK-Schreiboperation implementieren.
3. Schritt 3: Leere, ungültige und bestehende Werte testen.

Sidebar und Record-Prüfung

Eine Sidebar fasst Qualitätsinformationen zusammen, ohne die Standardpflege zu ersetzen.

1. Schritt 1: Prüfkriterien aus Modell und Record ableiten.
2. Schritt 2: Status, Hinweise und Sprungziele anzeigen.
3. Schritt 3: Aktualisierung bei Record-Änderung und fehlenden Rechten testen.

Form- und Record-Aktionen

Explizite Aktionen führen begrenzte, nachvollziehbare Aufgaben aus und verlangen bei Risiko eine Bestätigung.

1. Schritt 1: Vorbedingungen und Auswirkungen der Aktion definieren.
2. Schritt 2: Aktion mit Fortschritts- und Fehlermeldung implementieren.
3. Schritt 3: Doppelklick, Abbruch und Teilfehler behandeln.

Plugin-Konfiguration und Mehrprojektfähigkeit

Veränderliche IDs, Optionen und Endpunkte werden konfigurierbar statt fest kodiert.

1. Schritt 1: Projektabhängige Werte identifizieren.
2. Schritt 2: Konfigurationsoberfläche mit Validierung erstellen.
3. Schritt 3: Plugin in zwei unterschiedlich konfigurierten Testprojekten prüfen.

CMA- und externe Integrationen

Schreibzugriffe und externe Requests werden serverseitig oder mit klaren Berechtigungsgrenzen ausgeführt.

1. Schritt 1: Datenfluss und Geheimnisgrenzen zeichnen.
2. Schritt 2: Minimalen API-Zugriff mit Fehlerbehandlung implementieren.
3. Schritt 3: Berechtigungsfehler, Timeout und ungültige Antwort simulieren.

Sicherheit und Datenschutz

Eingaben, Ausgaben, Geheimnisse und externe Inhalte werden als potenziell unsicher behandelt.

1. Schritt 1: Angriffsflächen und sensitive Daten markieren.
2. Schritt 2: Validierung, Encoding und Geheimnisablage umsetzen.
3. Schritt 3: Missbrauchs- und Rechtefälle als Tests ergänzen.

Tests, Packaging und Versionierung

Das Plugin erhält reproduzierbare Artefakte, Changelog und eine kontrollierte Einführung.

1. Schritt 1: Unit-, Komponenten- und Integrationsfälle definieren.
2. Schritt 2: Produktionsbuild und Paketprüfung ausführen.
3. Schritt 3: Version, Rolloutgruppe, Rückfall und Supportweg dokumentieren.

Praktische Übungen und Anwendung

Kapitelinhaltsverzeichnis

• Domänenspezifischer Feldeditor
• Qualitäts-Sidebar
• Freigabeaktion mit externem Prüfdienst
• Rollout in zwei Projekte
• Prüf- und Abnahmekriterien

Domänenspezifischer Feldeditor

Szenario: Ein Feld speichert eine strukturierte Produktkennung, die aus mehreren Teilwerten erzeugt wird.

1. Schritt 1: Format und Beispiele definieren.
2. Schritt 2: UI und lokale Validierung implementieren.
3. Schritt 3: Wert über das SDK speichern.
4. Schritt 4: Neu-, Bestands- und Fehlerfälle testen.

Prüfkriterium: Der Editor validiert Eingaben, zeigt verständliche Fehler und schreibt ausschließlich das vereinbarte Format.

Qualitäts-Sidebar

Szenario: Redaktion benötigt eine Übersicht über Pflichtfelder, Alt-Texte, Slug und Veröffentlichungsstatus.

1. Schritt 1: Prüfregeln und Prioritäten festlegen.
2. Schritt 2: Recorddaten aus dem Kontext lesen.
3. Schritt 3: Statusdarstellung und Sprungziele implementieren.
4. Schritt 4: Rechte- und Aktualisierungsfälle testen.

Prüfkriterium: Die Sidebar zeigt nachvollziehbare Prüfergebnisse und aktualisiert sich bei Änderungen ohne unzulässige Schreibzugriffe.

Freigabeaktion mit externem Prüfdienst

Szenario: Eine Record-Aktion ruft einen simulierten internen Prüfdienst auf und schreibt nur bei Erfolg einen Status.

1. Schritt 1: Schnittstellenvertrag und Sicherheitsgrenzen definieren.
2. Schritt 2: Aktion mit Bestätigung und Fortschritt implementieren.
3. Schritt 3: Erfolg, Timeout und Ablehnung simulieren.
4. Schritt 4: Protokollierung und Rollback des Status prüfen.

Prüfkriterium: Geheimnisse bleiben geschützt; Timeout, Ablehnung und Doppelaufruf sind kontrolliert behandelt.

Rollout in zwei Projekte

Szenario: Dasselbe Plugin soll mit unterschiedlichen Modell- und Feld-IDs verwendet werden.

1. Schritt 1: Konfigurierbare Werte identifizieren.
2. Schritt 2: Setup-Dialog und Validierung implementieren.
3. Schritt 3: Zwei Testkonfigurationen anlegen.
4. Schritt 4: Update und Rückfall auf Vorversion testen.

Prüfkriterium: Konfiguration, Validierung und Versionsstand funktionieren in beiden Projekten ohne Codeänderung.

Prüf- und Abnahmekriterien

Die Übungen werden nicht allein nach sichtbarer Funktion, sondern nach Reproduzierbarkeit, Sicherheit, Datenqualität und Betriebsfähigkeit bewertet.

• Der Ausgangszustand, die Änderung und der geprüfte Zielzustand sind dokumentiert.
• Mindestens ein Negativ- oder Störungstest wurde kontrolliert durchgeführt.
• Geheimnisse, produktive Daten und unbeteiligte Systeme wurden nicht in die Übungen einbezogen.
• Offene Punkte besitzen Priorität, verantwortliche Stelle und nächsten Prüftermin.