Theme Export-Import

Deferred Feature aus Theme-Strategie-Brainstorm 2026-04-28. Nicht jetzt implementieren, aber Datenmodell muss es ermoeglichen.

Bedarf

Externe Designer sollen Themes ausserhalb von Alexium entwickeln und als Paket einreichen koennen. Alexium importiert das Bundle, ohne Datenverlust. Auch umgekehrt: Alexium-Sysdesigner exportiert ein Theme zur Weiterbearbeitung oder als Backup.

Bundle-Format (Vorschlag)

theme-{theme_key}-{version}.atheme (zip-archiv):

manifest.json:
  - theme: { theme_key, theme_name, designer, license_unit, brand_defaults, ... }
  - schema_version: '1.0'
  - alexium_min_version: '5.x'

variants/:
  - {variant_key}.json: { component_key, slot_layout, css_source, ... }
  - ...

demo_pages/:
  - {page_key}.json: { page_meta, sections[], blockcontent[], bindings[], ... }

assets/:
  - {hash}.{ext}: Bilder, Fonts (Theme-Assets, nicht Tenant-Assets)
  - asset_manifest.json: Hash → Original-Pfad

README.md
LICENSE

Datenmodell-Anforderungen (heute schon beruecksichtigen)

  • templatevariant.css_source als TEXT-Spalte (nicht nur Asset-Pfad) — damit Export Self-Contained ist
  • theme.designer_id als FK auf designer-Tabelle — Designer-Metadaten mitexportierbar
  • Theme-Assets unter theme/{theme_key}/... (nicht unter tenant/...)
  • templatevariant.slot_layout_json falls Layout in Variant variiert (falls Component-only: weglassen)
  • Versionierung pro Variant (version SemVer-String)

Import-Validation

  • Schema-Version-Check (semver-kompatibel)
  • Component-Existenz: Theme liefert Variants fuer Components, die im Alexium-Standard existieren — wenn nicht, Warning + Skip oder Reject
  • Asset-Hash-Konsistenz
  • License-Unit-Anlage als pending/awaiting-approval

Zusammenhaenge

Aufwand-Schaetzung (grob)

  • Export: M (1-2 Tage), Service ThemeExportService::exportToBundle()
  • Import: L (3-4 Tage), Service ThemeImportService::importFromBundle() mit Validation + Dry-Run
  • Designer-Portal-UI: separate Sprint-Stage