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_sourceals TEXT-Spalte (nicht nur Asset-Pfad) — damit Export Self-Contained isttheme.designer_idals FK aufdesigner-Tabelle — Designer-Metadaten mitexportierbar- Theme-Assets unter
theme/{theme_key}/...(nicht untertenant/...) templatevariant.slot_layout_jsonfalls Layout in Variant variiert (falls Component-only: weglassen)- Versionierung pro Variant (
versionSemVer-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
- Theme-Marketplace — der ganze Sinn dieses Features
- Section-Type-Taxonomy — Components folgen der Taxonomy
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