Systemüberblick

Diese Seite zeigt, wie die wichtigsten Bausteine von dbxapp zusammenspielen. Sie ist eine Orientierungskarte – die verlinkten Leitfäden erklären anschließend die einzelnen Bereiche im Detail.

dbxapp in einem Satz

dbxapp ist eine modulare PHP-Plattform für öffentliche Websites, CMS-Inhalte, administrative Anwendungen und individuelle Fachprozesse. Eine gemeinsame Laufzeit verbindet Routing, Berechtigungen, Datenmodelle, Formulare, Reports, Templates, Browserfunktionen und Caching.

Dadurch müssen typische Aufgaben nicht für jedes Modul neu gelöst werden. Neue Funktionen greifen auf definierte Systemdienste zurück und bleiben so prüfbar, wartbar und updatefähig.

Die Architektur auf einen Blick

index.php, Request-Pipeline und dbx()

Starten die Laufzeit, erfassen den Request-Kontext und stellen die zentrale System-API bereit.

Module und Routen

Ordnen einen Request einer Fachfunktion zu. Module enthalten Controller, Services und die zugehörigen Systemressourcen.

dbxDB, DD und FD

dbxDB ist der verbindliche Datenzugriff. DD-Dateien beschreiben Tabellen, Felder, Indizes und Rechte; FD-Dateien definieren wiederverwendbare Formularsichten.

dbxForm und dbxReport

Übernehmen Validierung, Formularzustand, Speichern, Suche, Sortierung, Seitennavigation, Auswahl und Aktionen.

Content, Menü, Templates und Designs

Bestimmen Seitenstruktur und Darstellung. Das Frontend arbeitet überwiegend mit CMS-Seiten und Permalinks; die Administration mit Modulen und Request-Parametern.

JavaScript-Systembibliotheken

Ergänzen die serverseitige Ausgabe um AJAX, Dialoge, Fenster, Confirm-Abläufe, Reports, Grids, Editorfunktionen und persistenten UI-Zustand.

So entsteht eine Antwort

1. index.php startet die Request-Pipeline.
2. Die Laufzeit ermittelt Installation, Sprache, Benutzer, Design, Route und Berechtigungen.
3. Das zuständige Modul lädt Fachlogik und – falls erforderlich – Daten über dbxDB und eine vollständige DD.
4. dbxForm, dbxReport oder ein Fachservice erzeugen das fachliche Ergebnis.
5. Templates und Interpreter setzen die Ausgabe zusammen; dargestellte Codebeispiele bleiben dabei inert.
6. Ausgabefilter, Metadaten und Design vervollständigen die Antwort. Geeignete öffentliche Gastseiten können anschließend aus dem Full-Page-Cache bedient werden.

Welcher Baustein ist wofür gedacht?

Update-feste Erweiterungsgrenzen

• Allgemeingültig: Änderungen am Kernel oder an systemweiten Modulen gehören in die Produktquelle, werden getestet und über den Release- und Updateprozess verteilt.
• Installationsspezifisch: Kundenlogik, lokale Integrationen und abweichende Abläufe gehören nach myX oder in ein eigenes Fachmodul. Dadurch bleiben sie von Kernel-Updates getrennt.
• Datenzugriff: Fachcode verwendet ausschließlich dbxDB und vollständige DDs. Direkte PDO-, mysqli-, SQLite3- oder Treiberzugriffe umgehen Rechte, Trace, Synchronisierung und Systemdiagnose.
• Darstellung: HTML gehört in Templates. PHP koordiniert Fachlogik, statt große Markup-Blöcke zusammenzubauen.
• Browserlogik: Vorhandene Systembibliotheken werden erweitert oder wiederverwendet; parallele AJAX-, Fenster-, Dialog- oder UI-State-Lösungen sind zu vermeiden.

Diese Trennung macht Updates vorhersehbar: Der Produktkern kann ersetzt werden, während projektspezifische Erweiterungen klar abgegrenzt erhalten bleiben.

Typische Einstiegspunkte

Öffentliche Seite

/kontakt
/produkte/lkw-planung
/de/service

Administratives Modul

?dbx_modul=dbxAdmin
?dbx_modul=dbxContact_admin&dbx_run1=list
?dbx_modul=dbxAdmin&dbx_run1=sysmsg&dbx_run2=list_sysmsg

Modul innerhalb von Content oder Template

[modul=dbxContact]dbx_run1=tickets[/modul]

Wie geht es weiter?

• Architektur und Laufzeit erklärt den Request-Ablauf im Detail.
• myX zeigt update-feste projektspezifische Erweiterungen mit einem konkreten Beispiel.
• Modul-Schnellstart führt in einem Arbeitsgang durch ein vollständiges Modul.
• dbxDB, DD und FD vertieft Datenmodell, Rechte und Synchronisierung.

Merksatz: Neue Fachfunktionen nutzen die vorhandenen dbxapp-Pipelines. Allgemeine Funktionen werden Teil des Produkts; installationsspezifische Funktionen bleiben sauber in myX oder einem eigenen Fachmodul.