Architektur
Systemcode, Projektdaten und Ausgaben bleiben technisch getrennt
ProfilSite arbeitet dateibasiert und erzeugt statische Websites.
Systemcode, Projektdaten und Ausgabedateien besitzen getrennte Verantwortlichkeiten und Speicherbereiche.
Dateibasis
Dateibasierte Speicherung bleibt strukturiert und vertraglich geregelt
ProfilSite benötigt für den regulären Systembetrieb keine separate SQL-Datenbank.
Dauerhafte System- und Projektzustände werden in strukturierten Dateien und klar abgegrenzten Verzeichnissen geführt. Medien liegen ebenfalls in projektbezogenen Dateibeständen.
Dateibasiert bedeutet dabei nicht unstrukturiert. Datenverträge, Pfadregeln, Repository-Grenzen, Validierung und transaktionale Schreibmechanismen übernehmen Aufgaben, die für Konsistenz und kontrollierten Zugriff erforderlich sind.
Die Architektur basiert auf definierten Zuständigkeiten statt auf frei verteilten Dateien. Für Betrieb und Sicherung entsteht dadurch eine klare Abgrenzung.
Systembestand, Projektbestand und erzeugte Ausgaben können als unterschiedliche technische Einheiten betrachtet werden.
Datenräume
System, Projekte und Ausgaben besitzen getrennte Speicherbereiche
Die technische Architektur trennt drei grundlegende Datenräume.
Der Systembestand enthält Anwendungscode, Darstellungsressourcen, Regelwerke, Stilwelten und Dokumentation. Der Projektbestand enthält die konkreten ProfilSites mit Inhalten, Bereichen, Bühnen, Medien, Rechtsdaten, Redaktion und Freigaben.
Der Ausgabebestand enthält erzeugte statische Websites und Website-Pakete. Diese Trennung ist eine Schutzgrenze.
Eine Systemaktualisierung soll nicht automatisch produktive Projektdaten ersetzen. Umgekehrt dürfen Ausgabedateien nicht als Quelle für die weitere Projektbearbeitung verwendet werden.
Die Richtung der Produktion bleibt eindeutig: Systemregeln und Projektdaten werden gelesen, ein freigegebener Projektzustand wird verarbeitet und daraus entsteht eine Ausgabe.
Verzeichnisstruktur
Die physische Ablage bildet fachliche Verantwortlichkeiten ab
Der Systemstamm gliedert unterschiedliche technische Aufgaben in eigene Verzeichnisse.
Der Anwendungscode liegt getrennt von Darstellungsressourcen, Systemdaten, Stilwelten, Projekten, Dokumentation und erzeugten Ausgaben. Diese Struktur macht sichtbar, welche Dateien zu welchem Verantwortungsbereich gehören.
Die Projektbestände enthalten die tatsächlich bearbeiteten ProfilSites. Dort liegen unter anderem Arbeitskopien, aktuelle Freigabestände, Archive, Medien und projektbezogene Einstellungen.
Ausgaben werden dagegen in einem eigenen technischen Bereich erzeugt. Für Wartung ist diese Trennung wesentlich.
Eine Änderung an einer Stilwelt gehört nicht in denselben Datenraum wie eine Änderung an einem Projektinhalt. Ein Systemupdate muss wiederum den Projektbestand als geschützte Quelle behandeln.
Datenverträge
Fachbereiche besitzen eigene strukturierte Dateien und Verträge
Projektinformationen werden nicht als ein einziges großes Dokument gespeichert.
Unterschiedliche Fachbereiche besitzen eigene strukturierte Dateien und Verträge. Bühnen, Bereiche, Medien, Rechtsdaten, Redaktion, Stilweltkopien und Freigaben können dadurch getrennt verwaltet und geprüft werden.
JSON-basierte Datenverträge definieren, welche Felder und Identitäten erwartet werden. Fachmodule lesen und schreiben nur die dafür vorgesehenen Datenbereiche.
Renderer wiederum sollen vorhandene Projektzustände darstellen, nicht eigenständig neue Projektinhalte erzeugen. Diese Verantwortungsgrenzen erleichtern Wartung und Fehlerdiagnose.
Wenn ein Problem in der Medienzuordnung liegt, muss nicht die gesamte Projektdatei untersucht werden. Wenn eine Darstellung fehlerhaft ist, bleibt die Persistenz davon getrennt.
Statische Website
Der öffentliche Betrieb bleibt von Atelier und Projektbestand getrennt
Die öffentliche ProfilSite wird als statischer Dateibestand erzeugt.
Dazu gehören HTML-Dokumente, Stylesheets, JavaScript, Schriften, Materialien, Bilder und technische Begleitdateien. Für normale Seitenaufrufe wird weder Matliks Atelier noch eine Datenbankabfrage benötigt.
Statisch bedeutet nicht, dass die Website ausschließlich aus unbewegtem Text besteht. JavaScript kann weiterhin für Navigation, Darstellungswechsel, Galerieverhalten oder andere vorgesehene Interaktionen verwendet werden.
Entscheidend ist, dass die Inhalte nicht bei jedem Seitenaufruf aus einer Serverdatenbank zusammengesetzt werden müssen. Die statische Ausgabe trennt Produktion und Auslieferung.
Ausgabestufen
Prüfausgabe und Website-Kandidat bilden zwei getrennte Produktionsstufen
Vor dem endgültigen Website-Paket verwendet ProfilSite zwei Ausgabestufen.
Die interne statische Prüfausgabe kontrolliert, ob die freigegebenen Bereiche aus ihren aktuellen Daten technisch korrekt erzeugt werden können.
Sie ist bereits eine echte HTML-Ausgabe, aber noch nicht als endgültiger öffentlicher Stand gedacht.
Darauf folgt der öffentliche Website-Kandidat.
Er führt alle aktiven Bereiche zu einer zusammenhängenden Website zusammen und berücksichtigt öffentliche Pfade, Canonical-Adressen, Bereichsnavigation, Rechtstexte, Metadaten, Medien und gegebenenfalls die Redaktion.
Diese zweite Stufe darf nur auf einem aktuellen und vollständigen Prüfausgabestand aufbauen.
Website-ZIP
Das öffentliche Paket enthält nur die für den Betrieb benötigten Dateien
Aus dem geprüften öffentlichen Kandidaten kann ein Website-ZIP erzeugt werden.
Es enthält die für den Betrieb benötigten HTML-, CSS-, JavaScript-, Medien- und Begleitdateien. Projektinterne Arbeitsdaten und Atelierlogik gehören nicht in dieses Paket.
Das Website-ZIP ist ausdrücklich keine Projektsicherung. Es enthält den fertigen öffentlichen Webauftritt, nicht den bearbeitbaren Projektbestand.
Ebenso ist das Erzeugen des ZIP keine Veröffentlichung. ProfilSite überträgt den Inhalt nicht automatisch auf einen entfernten Webserver.
Die technische Grenze ist eindeutig: ProfilSite erzeugt und prüft die Website-Dateien. Ein externer Übertragungsprozess bringt diese Dateien gegebenenfalls auf das Zielhosting.
Sicherung
Archive, Transaktionsschutz und Projektbackups erfüllen unterschiedliche Aufgaben
ProfilSite unterscheidet mehrere Arten von Historie und Sicherung.
Fachliche Archive bewahren frühere freigegebene Bühnen- oder Artikelstände. Transaktions-Preimages dienen kurzfristig dem Rollback eines laufenden Schreibvorgangs.
Projektarchive sichern dagegen einen vollständigen Projektbestand für Übergabe oder Wiederherstellung. Ein Projektarchiv ist nicht lediglich ein beliebig gepacktes Verzeichnis.
Vor einer Wiederherstellung können Struktur, Projektidentität, Dateianzahl, Größen, Dateitypen und Archivpfade geprüft werden. Damit sollen beschädigte oder ungeeignete Archive erkannt werden, bevor sie in den aktiven Projektbestand gelangen.
Auch die Wiederherstellung ist ein kontrollierter Vorgang. Ein Projekt wird nicht durch das manuelle Zurückkopieren einzelner JSON-Dateien rekonstruiert.
Updates
Systemupdates dürfen geschützte Projektdaten nicht beiläufig verändern
Systemupdate und Projektdaten sind unterschiedliche technische Vermögenswerte.
Ein Update kann PHP, JavaScript, CSS, Systemregeln, Stilwelten oder Dokumentation verändern, während der konkrete Projektbestand erhalten bleiben muss. Der Projektbereich besitzt deshalb besondere Schutzpriorität.
Ein vollständiges Systempaket bedeutet nicht, dass reale Produktionsprojekte bei jeder Aktualisierung ersetzt werden. Vor einem Update müssen geschützte Datenräume eindeutig identifiziert und vom Austausch des Systembestands getrennt werden.
Änderungen am persistierten Datenmodell benötigen zudem einen bewussten Migrationsweg. Eine reine Darstellungsreparatur ist kein Grund, Projektdateien beiläufig umzuschreiben.
Laufzeit
Die statische Ausgabe reduziert die Komponenten des öffentlichen Betriebs
Die statische Ausgabe reduziert die Zahl der Komponenten, die für einen normalen öffentlichen Seitenaufruf erforderlich sind.
Besucher benötigen weder Zugriff auf das Atelier noch auf den Projektbestand oder eine separate Datenbank-Engine. Der Webserver liefert die erzeugten Dateien aus.
Dadurch wird die Produktionsumgebung vom öffentlichen Betrieb entkoppelt. Änderungen werden im System vorbereitet, geprüft und erneut ausgegeben.
Die öffentliche Website muss nicht selbst die vollständige Bearbeitungslogik mitführen. Diese Architektur ist kein allgemeines Qualitätsurteil über andere Website-Systeme.