Seminar Magnolia CMS – Light Development mit YAML und FreeMarker

Das Seminar vermittelt schnelle, versionierbare Magnolia-Entwicklung mit Light Modules, YAML-Definitionen, FreeMarker, Dialogen, Content Types, Ressourcen, 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. Light-Module-Struktur und Definitionsmodell
2. Templates, Bereiche und Komponenten
3. FreeMarker und Webressourcen
4. Dialoge, Content Types und Lokalisierung
5. Tests, Paketierung und Deployment
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Light-Module-Struktur und Definitionsmodell

Inhaltsverzeichnis

• Modulordner und Descriptor
• YAML-Definitionen und Namensräume
• Ressourcen, Beobachtung und Versionsverwaltung
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Modulordner und Descriptor, YAML-Definitionen und Namensräume und Ressourcen, Beobachtung und Versionsverwaltung 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: Modulordner und Descriptor 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 YAML-Definitionen und Namensräume 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: Ressourcen, Beobachtung und Versionsverwaltung werden schrittweise konfiguriert oder implementiert. Ein neues Light Module wird angelegt, geladen und in Git nachvollziehbar strukturiert. 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: Modulgerüst mit Namens- und Ablagestandard.

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

Templates, Bereiche und Komponenten

Inhaltsverzeichnis

• Page-, Area- und Component-Definitionen
• Verfügbarkeit, Prototypen und Vererbung
• Dialogverknüpfung und Renderer
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Page-, Area- und Component-Definitionen, Verfügbarkeit, Prototypen und Vererbung und Dialogverknüpfung und Renderer 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: Page-, Area- und Component-Definitionen 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 Verfügbarkeit, Prototypen und Vererbung 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: Dialogverknüpfung und Renderer werden schrittweise konfiguriert oder implementiert. Eine Seitenvorlage mit mehreren kontrollierten Komponentenbereichen wird definiert. 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: Template-Paket mit Komponentenrestriktionen.

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

FreeMarker und Webressourcen

Inhaltsverzeichnis

• Datenzugriff, Makros und Includes
• sichere Ausgabe, Fallbacks und Fehlerfälle
• CSS, JavaScript, Assets und URLs
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Datenzugriff, Makros und Includes, sichere Ausgabe, Fallbacks und Fehlerfälle und CSS, JavaScript, Assets und URLs 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: Datenzugriff, Makros und Includes 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 sichere Ausgabe, Fallbacks und Fehlerfälle 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: CSS, JavaScript, Assets und URLs werden schrittweise konfiguriert oder implementiert. Komponenten werden mit wiederverwendbaren Makros und stabilen Leerzuständen gerendert. 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: Renderingbibliothek mit Ressourcenstruktur.

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

Dialoge, Content Types und Lokalisierung

Inhaltsverzeichnis

• Felder, Validierung und Hilfetexte
• strukturierte Inhalte und Content Apps
• i18n-Schlüssel, Labels und lokalisierte Werte
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Felder, Validierung und Hilfetexte, strukturierte Inhalte und Content Apps und i18n-Schlüssel, Labels und lokalisierte Werte 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: Felder, Validierung und Hilfetexte 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 strukturierte Inhalte und Content Apps 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: i18n-Schlüssel, Labels und lokalisierte Werte werden schrittweise konfiguriert oder implementiert. Ein redaktioneller Datentyp wird mit Dialog und lokalisierter Ausgabe ergänzt. 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: Redaktionsvertrag mit Feld- und Sprachdefinition.

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

Tests, Paketierung und Deployment

Inhaltsverzeichnis

• Definitionen prüfen und Fehler lokalisieren
• Rendering- und Dialogtests
• Versionspaket, Umgebungskonfiguration und Rollback
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Definitionen prüfen und Fehler lokalisieren, Rendering- und Dialogtests und Versionspaket, Umgebungskonfiguration 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: Definitionen prüfen und Fehler lokalisieren 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 Rendering- und Dialogtests 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: Versionspaket, Umgebungskonfiguration und Rollback werden schrittweise konfiguriert oder implementiert. Das Light Module wird automatisiert geprüft und in eine zweite Umgebung übertragen. 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: Lieferpaket mit Test- und Rückfallcheckliste.

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: Web- und Frontend-Entwicklung, technische Konzeption, Magnolia-Entwicklung, Prototyping-Teams und technische Redaktion.

Voraussetzungen: Grundkenntnisse in HTML, CSS, JavaScript, YAML, Git und Template-Systemen; Java-Kenntnisse sind nicht erforderlich.

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.