Stand: 2026-07-14

dbXapp trennt Fachlogik, Content und Darstellung. Ein Design ist eine vollstaendige Anwendungsschale mit eigenem HTML, CSS, JavaScript und Bildern. Ein Skin ist eine Farb- und Kontrastvariante innerhalb eines Designs. Diese Trennung erlaubt technisch identische Seiten mit sehr unterschiedlichen Auftritten.

Aktuell sind zwei eigenstaendige Frontend-Designs vorhanden:

Design	Charakter	Navigation	angebotene Skins
dbxapp	technisch, kompakt, anwendungsorientiert	horizontal	Blau, Gruen, Gelb, Rot, Hell, Dunkel
fleurop	verspielt, organisch, Holz, Pflanzen und Kupfer	links vertikal	Light (hell), Dark (dunkel)

Das konfigurierte Admin-Design ist dbxapp. Ein Frontend-Benutzer darf das Frontend-Design wechseln. Wird im Frontend fuer Administratoren das horizontale Admin-Menue eingeblendet, bleibt dieses bewusst horizontal und uebernimmt nicht die vertikale Fleurop-Navigation.

Begriffe und Verantwortung

Design

Ein Design verantwortet:

die aeussere HTML-Struktur der Seite,
Haupt- und Admin-Navigation,
Header, Contentflaeche, Footer und Fenster-Dock,
responsive Verhalten,
Typografie, Abstaende, Oberflaechen und Bildsprache,
designbezogene JavaScript-Ergaenzungen,
die Einbindung der angebotenen Skins.

Ein Design verantwortet nicht:

Shop-, CMS- oder Benutzerlogik,
Datenzugriff und Rechtepruefung,
das Speichern von Formularen,
Report-Pagination oder Ajax-Transport,
die fachliche Bedeutung eines Moduls.

Skin

Ein Skin veraendert innerhalb eines Designs vor allem Farben, Kontraste, Schatten, Rahmen und Hell-/Dunkelverhalten. Der Skin darf die Grundstruktur eines Designs nicht neu bauen. Wenn Navigation, Spalten oder Seitenschale anders werden sollen, ist ein eigenes Design die richtige Ebene.

Modul-Design

Module duerfen eigenes Komponenten-CSS und eigene Templates mitbringen, zum Beispiel:

dbx/modules/dbxShop/design/css/shop.css
dbx/modules/dbxShop/design/js/shop.js
dbx/modules/dbxShop/tpl/htm/product-card-default.htm

Dieses Modul-Design gestaltet nur die fachliche Ausgabe. Die umgebende Seite kommt weiterhin aus dem aktiven globalen Design unter dbx/design/.

Verzeichnis eines eigenstaendigen Designs

Ein Design liegt unter:

dbx/design/{design}/
  htm/
    default.htm
  css/
    colors.css
    skin-*.css
    base.css
    theme.css
    c-*.css
    m-menu.css
  js/
  img/

htm/default.htm ist die Voraussetzung dafuer, dass ein Verzeichnis als oeffentlich waehlbares Frontend-Design erkannt wird. Verzeichnisse mit einem Namen, der mit _ oder - beginnt, werden in der Designauswahl nicht angeboten.

Jedes Design soll alle designbezogenen Dateien selbst besitzen. fleurop soll daher nicht stillschweigend CSS, Bilder oder JavaScript aus dbxapp erben. Gemeinsam genutzt werden nur zentrale System- und Vendor-Ressourcen, etwa Bootstrap, Bootstrap Icons, jQuery und dbx/js/lib/core.js.

Design-Templates und Seitenvarianten

Die Seitenschale wird mit dbxTPL::get_design_tpl() geladen. Ausgangspunkt ist die aktive Kombination aus:

dbx_design: Designpaket,
dbx_page: Seitenvariante,
dbx_lng: Sprache,
dbx_color: Skin.

Typische Dateien im Design sind:

htm/default.htm     normale Seite
htm/intro.htm       optionale Einfuehrungsseite
htm/_window.htm     reduzierte Fensterschale, wenn vorhanden
htm/_editor.htm     Editor-Spezialseite, wenn vorhanden
htm/_install.htm    Installationsseite, wenn vorhanden

Ist eine angeforderte Seitenvariante im aktiven Design nicht vorhanden, faellt die Template-Aufloesung auf default.htm zurueck. Der derzeitige Fenstermechanismus setzt bei dbx_window=1 die Seite auf _window. Eine separate _adminWin-Variante ist im aktuellen Stand nicht implementiert und darf deshalb nicht vorausgesetzt werden.

Ein minimales default.htm enthaelt mindestens:

<!doctype html>
<html lang="{dbx:lng}">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{dbx:title}</title>{dbx:head_meta}
  <link rel="stylesheet" href="dbx/vendor/twbs/bootstrap/dist/css/bootstrap.min.css">
  <link rel="stylesheet" href="dbx/vendor/twbs/bootstrap-icons/font/bootstrap-icons.css">
  <link rel="stylesheet" href="dbx/design/{dbx:design}/css/colors.css">
  <link rel="stylesheet" href="{dbx:skin_css}">
  <link rel="stylesheet" href="dbx/design/{dbx:design}/css/base.css">
  <link rel="stylesheet" href="dbx/design/{dbx:design}/css/theme.css">
</head>
<body class="{dbx:skin_class}"
      data-dbx-design="{dbx:design}"
      data-dbx-skin="{dbx:color}">
  <main id="dbxMain">[dbx:content]</main>
  <script src="dbx/vendor/components/jquery/jquery.min.js"></script>
  <script src="dbx/js/lib/core.js?design={dbx:design}"></script>
</body>
</html>

Der reale Contentmarker lautet [dbx:content]. Die Marker {dbx:skin_css}, {dbx:skin_class}, {dbx:design}, {dbx:color} und {dbx:lng} werden durch dbxTPL ersetzt.

Laufzeit: Wie ein Design bestimmt wird

Der Ablauf liegt zentral in dbxWebApp:

check_remember() liest dbx_design, dbx_color, dbx_lng und dbx_edit aus Remember-State und Request.
Requestwerte duerfen die gemerkten Werte ueberschreiben.
check_design() validiert das Design und loest die Aliaswerte user und admin gegen die Konfiguration auf.
Ein Admin-Modul mit _admin im Modulnamen schaltet fuer Administratoren auf default_design_admin.
design_load() waehlt Design und Page, setzt den Modulinhalt in [dbx:content] ein und liefert die fertige Seite aus.
Bei dbx_ajax=1 wird keine neue Seitenschale geladen; nur der Modulinhalt wird zurueckgegeben.

Die Standardwerte stehen in dbx/modules/dbx/cfg/config.php:

$config['default_color'] = 'blau';
$config['default_design_user'] = 'dbxapp';
$config['default_design_admin'] = 'dbxapp';

Ein Modul oder Admin-Werkzeug kann fuer seinen Aufruf dbx_page, dbx_design, dbx_lng und dbx_color setzen. Solche Umschaltungen muessen vor dem Laden der Designschale erfolgen und duerfen die zentrale Validierung nicht umgehen.

Frontend und Administration

Die aktuelle Trennung lautet:

Normale Frontend-Seiten verwenden das vom Benutzer gewaehlte Design.
dbxShop ist ein Frontend-Modul und laeuft deshalb in der aktiven Frontend-Schale.
Module mit dem Suffix _admin, beispielsweise dbxShop_admin, wechseln fuer Administratoren zum konfigurierten Admin-Design.
Das Admin-Menue kann fuer angemeldete Administratoren auch im Frontend erscheinen. Im Fleurop-Design wird es als eigener horizontaler Streifen ueber dem eigentlichen Frontend-Header ausgegeben.
Ein per Ajax oder openWin geladener Inhalt erhaelt nicht automatisch ein zweites komplettes Design. Die Fensterschale kommt vom aufrufenden Kontext; Komponenten des Admin-Inhalts werden durch ihre Modul-Styles gestaltet.

Damit bleiben Frontend und Backend visuell trennbar, ohne dass Modulcode dupliziert oder ein iframe vorausgesetzt werden muss. Falls spaeter echte Design-Isolation in Fenstern benoetigt wird, muss sie als eigener, dokumentierter Fenstermodus umgesetzt werden.

Design- und Skin-Auswahl im Menue

Die Auswahl befindet sich im Hauptmenue-Template:

dbx/modules/dbxMenu/tpl/htm/dbx-top-main.htm

dbxMenu::frontend_design_options() durchsucht zur Laufzeit dbx/design/*/htm/default.htm. Dadurch erscheint ein neues vollstaendiges Design ohne fest verdrahtete Liste im Menue.

Der Designwechsel ist ein normaler Seitenaufruf mit dbx_design. Der Skin wird clientseitig durch dbx/js/lib/utilities.js gewechselt und anschliessend ueber dbx_color mit dem Serverzustand synchronisiert.

Die angebotenen Skins sind aktuell absichtlich designspezifisch:

dbxapp: blau, gruen, gelb, rot, hell, dunkel

fleurop: hell (Light), dunkel (Dark)

Dass im Fleurop-Verzeichnis weitere skin-*.css-Dateien vorhanden sind, macht sie nicht automatisch zu waehlbaren Varianten. Verbindlich ist die designspezifische Liste in dbxMenu::skin_options() und die passende Normalisierung in utilities.js.

CSS-Schichten

Eine robuste Aufteilung ist:

Datei	Verantwortung
colors.css	gemeinsame Design-Tokens und semantische Farbvariablen
skin-*.css	Werte fuer eine konkrete Farb-/Kontrastvariante
base.css	App-Shell, Header, Main, Footer, Navigation, responsive Grundstruktur
theme.css	visuelle Sprache fuer Panels, Formulare, Reports und Fenster
c-*.css	Komponenten wie CMS, Form, Grid, Report, OpenWin und Process
m-menu.css	Menue- und responsive Sonderregeln

Skins sollten vorzugsweise CSS-Variablen ueberschreiben. Komponenten greifen auf diese Variablen zu. Dadurch muss eine Dark-Variante nicht die komplette Komponentenbibliothek kopieren.

Das Fleurop-Design

fleurop ist bewusst keine Farbkopie von dbxapp. Seine Merkmale sind:

feste bzw. einblendbare linke Hauptnavigation,
Holz-, Pflanzen- und Kupferanmutung,
organische Ornamente und florale Icons,
eine eigenstaendige Topbar und ein eigener Footer,
ein horizontaler Admin-Streifen fuer Administratoren,
eigenstaendiges Login-Styling,
Light- und Dark-Skin,
designbezogenes Verhalten in dbx/design/fleurop/js/fleurop.js.

Die linke Navigation muss bei langen oder aufgeklappten Untermenues scrollbar bleiben. Dropdowns des horizontalen Admin-Menues muessen ueber dem Seiteninhalt liegen; deshalb sind Stacking Context und z-index Teil der Designpruefung.

Neues Design anlegen

Einen eindeutigen, URL-tauglichen Namen waehlen.
Unter dbx/design/{name} mindestens htm, css, js und img anlegen.
Eine vollstaendige htm/default.htm mit [dbx:content], Menues, Footer, Vendor-Abhaengigkeiten und core.js erstellen.
Eigene colors.css, base.css, theme.css und Skin-Dateien anlegen.
Benoetigte c-*.css und Menue-Regeln im Design selbst pflegen.
Das Design mit Gast, Benutzer und Administrator testen.
Lange Haupt- und Untermenues, kleine Displays und Tastaturbedienung testen.
Formulare, Reports, CMS, Login, Shop und OpenWin/Ajax pruefen.
Erst danach das Design ueber dbx_design={name} produktiv anbieten.

Pruefliste

htm/default.htm existiert und enthaelt [dbx:content].
{dbx:skin_css} und {dbx:skin_class} sind eingebunden.
body traegt data-dbx-design und data-dbx-skin.
core.js?design={dbx:design} wird geladen.
Das Design importiert keine privaten Dateien eines anderen Designs.
Haupt- und Admin-Menue sind erreichbar und ueberdecken den Content korrekt.
Untermenues bleiben bei geringer Hoehe erreichbar.
Light/Dark bzw. alle angebotenen Skins funktionieren ohne unlesbare Kontraste.
Login, CMS, Shop, Formulare, Reports, Fenster und Ajax wurden geprueft.
Admin-Module laufen im Admin-Design; Frontend-Seiten bleiben umschaltbar.