Seminar Magnolia CMS – Intensivseminar Entwicklung, Headless und Integration

Der fünftägige Entwicklungspfad bündelt Light Development, Templates, Komponenten, FreeMarker, Content-Modelle, Delivery API, externe Frontends, REST-Integration, Java-Erweiterungen, Tests und Deployment. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Tag 1: Light Development und Templating
2. Tag 2: Content-Modelle und Frontend-Komponenten
3. Tag 3: Headless und externe Frontends
4. Tag 4: REST-Integration und Java-Erweiterung
5. Tag 5: Test, Qualität und Deployment
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Tag 1: Light Development und Templating

Inhaltsverzeichnis

• Light-Module-Struktur und YAML
• Page-, Area- und Component-Definitionen
• FreeMarker, Dialoge und Ressourcen
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Light-Module-Struktur und YAML, Page-, Area- und Component-Definitionen und FreeMarker, Dialoge und Ressourcen zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Light-Module-Struktur und YAML werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Page-, Area- und Component-Definitionen wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: FreeMarker, Dialoge und Ressourcen werden schrittweise konfiguriert oder implementiert. Ein lauffähiges Light Module mit redaktionell nutzbarer Seite wird aufgebaut. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Versioniertes Light Module mit Definitions- und Renderingstandard.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Tag 2: Content-Modelle und Frontend-Komponenten

Inhaltsverzeichnis

• Content Types und Content Apps
• Komponentenverträge und Dialoge
• responsive, zugängliche und performante Ausgabe
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Content Types und Content Apps, Komponentenverträge und Dialoge und responsive, zugängliche und performante Ausgabe zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Content Types und Content Apps werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Komponentenverträge und Dialoge wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: responsive, zugängliche und performante Ausgabe werden schrittweise konfiguriert oder implementiert. Strukturierte Inhalte werden modelliert und in wiederverwendbaren Frontend-Komponenten ausgegeben. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Content- und Komponentenbibliothek mit Tests.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Tag 3: Headless und externe Frontends

Inhaltsverzeichnis

• Delivery-Endpunkte und Referenzen
• Assets, Lokalisierung und Payload-Design
• SPA- oder Server-Frontend, Preview und Fehlerzustände
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Delivery-Endpunkte und Referenzen, Assets, Lokalisierung und Payload-Design und SPA- oder Server-Frontend, Preview und Fehlerzustände zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Delivery-Endpunkte und Referenzen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Assets, Lokalisierung und Payload-Design wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: SPA- oder Server-Frontend, Preview und Fehlerzustände werden schrittweise konfiguriert oder implementiert. Ein externes Frontend wird angebunden und mit Authoring- sowie Preview-Fluss geprüft. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Headless-Referenzintegration mit API-Vertrag.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Tag 4: REST-Integration und Java-Erweiterung

Inhaltsverzeichnis

• REST Client, Authentisierung und Mapping
• Java-Modul, Dependency Injection und Commands
• Fehlerbehandlung, Wiederholung und Monitoring
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet REST Client, Authentisierung und Mapping, Java-Modul, Dependency Injection und Commands und Fehlerbehandlung, Wiederholung und Monitoring zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: REST Client, Authentisierung und Mapping werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Java-Modul, Dependency Injection und Commands wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Fehlerbehandlung, Wiederholung und Monitoring werden schrittweise konfiguriert oder implementiert. Ein Drittsystem wird angebunden und durch eine kleine Java-Erweiterung orchestriert. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Integrationsmodul mit Betriebs- und Fehlerkonzept.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Tag 5: Test, Qualität und Deployment

Inhaltsverzeichnis

• Unit-, Integrations-, API- und Frontendtests
• Build, CI/CD und Konfigurationsparameter
• Release, Smoke-Test und Rollback
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Unit-, Integrations-, API- und Frontendtests, Build, CI/CD und Konfigurationsparameter und Release, Smoke-Test und Rollback zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Unit-, Integrations-, API- und Frontendtests werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Build, CI/CD und Konfigurationsparameter wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Release, Smoke-Test und Rollback werden schrittweise konfiguriert oder implementiert. Das Gesamtprojekt wird automatisiert geprüft, ausgerollt und kontrolliert zurückgesetzt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Produktionsreifes Lieferpaket mit Abnahmegates.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: Magnolia-, Frontend- und Full-Stack-Entwicklung, Lösungsarchitektur, API Engineering, DevOps und technische Projektleitung.

Voraussetzungen: Sichere Kenntnisse in HTML, CSS, JavaScript, HTTP, JSON, Git und YAML; für Java-Anteile werden Java- und Maven-Grundkenntnisse vorausgesetzt.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.