dbxapp ist ein PHP-Framework für Web- und Mobile-Anwendungen. Praktisch besteht es vor allem aus Reports, Formularen, Modulen, Templates und einem zentralen Runtime-/Session-System. Alles läuft grundsätzlich über index.php als einzigen Einstieg.

Das System ist darauf ausgelegt, Seiten serverseitig sehr schnell zu erzeugen. Nach den gemessenen Werten des Systemautors liegen typische komplette Requests meist bei etwa 0,01x s, das clientseitige core.js inklusive Libs oft bei etwa 0,02x s. Das passt zur Architektur: einfache Templates, viel Wiederverwendung, Session-Caches, keine schwere SPA-Laufzeit.

Der bevorzugte Zugriff auf den Systemkern erfolgt über dbx(). Die früher direkt genutzten globalen Helper wie dbx_get_SysVar(), dbx_get_PostGetVar() oder dbx_get_sys_object() wurden in die Klasse dbxApi überführt.

$db  = dbx()->get_SysObj('dbxDB');
$tpl = dbx()->get_SysObj('dbxTPL');
$id  = dbx()->req('id', 0, 'int');

dbx()->setSys('dbx_ajax', 1);
$ajax = dbx()->sys('dbx_ajax', 0, 'int');

Neue Kern- oder Modulprogrammierung soll den kurzen API-Stil verwenden. Das macht Suche, Refactoring und spätere Dokumentation einfacher: dbx()->cfg('dbx') beschreibt klarer, welche Ebene gemeint ist, als eine lange globale Funktionsliste.

?dbx_modul=dbxAdmin&dbx_run1=session&dbx_run2=list_session&dbx_edit=0

1. check_request() übernimmt diese Parameter in den Laufkontext.
2. check_perma() greift hier nicht um, weil Modul direkt angegeben ist.
3. check_design() wählt das aktive Design, typischerweise Admin-Design bei Adminkontext.
4. dbxWebApp->run() lädt Modul dbxAdmin.
5. dbxAdmin->run() liest dbx_run1=session und lädt Include-Klasse dbxSession aus dem Modul dbxAdmin.
6. Diese Modulklasse ruft bei dbx_run2=list_session den Reportaufbau auf.
7. dbxReport_Session erweitert Systemklasse dbxReport.
8. Der Report baut Formularfelder, Pagination, Tabellenkopf, Tabellenzeilen und Aktionslinks aus Templates zusammen.
9. Die Daten kommen aus DD dbxSession und DB dbxSession.db3.
10. Das komplette Ergebnis wird in das Design default.htm gesetzt.
11. Danach lädt der Interpreter noch Menüs wie Menu (b-undef) not found.

dbxapp ist stark zustandsgetrieben. Wer das System verstehen will, muss die verschiedenen Speicherorte unterscheiden.

Das ist einer der größten Unterschiede zu gängigen Frameworks: In dbxapp werden viele Dinge nicht als kurzlebiges Request-Objekt modelliert, sondern als strukturierter Session-/Kontextzustand.

Templates sind in dbxapp bewusst einfach. Keine Schleifen, keine Template-Sprache, kein Eval. Stattdessen:

• {var} für einfache Ersetzungen
• für einfache Bedingungen
• TPL (dbxContent/file.htm) not found
  für rekursive Template-Includes
• für spätere Interpreter-Komposition

Sehr wichtig ist die Trennung zwischen Modul-Templates und Design-Templates. Das Modul liefert den inhaltlichen Block, das Design liefert den Seitenskelett-Rahmen. Danach kommt der Interpreter und ergänzt weitere modulare Inhalte wie Menüs.

Ein Modul ist eine PHP-Klasse mit einer zentralen run()-Methode. Es kann:

• direkt Inhalte erzeugen,
• Unterklassen aus dem eigenen Include-Ordner laden,
• Templates rendern,
• weitere Module im HTML als einbetten.

Die Komposition ist deklarativ. Das ist einer der wichtigsten Architekturzüge von dbxapp. Ein Template oder Modul kann andere Modul-Ausgaben an beliebiger Stelle einbetten. Dadurch entsteht die Seite nicht in einem zentralen Controller, sondern schrittweise aus Bausteinen.

Wichtig: Kontext-Isolation pro Modulinstanz ist zentral. Genau deshalb existieren dbx_activ_modul_id und die modulinstanzbezogenen ModulVar-Speicher.

Die DDs sind nicht nur Felddefinitionen. Sie sind ein zentrales Metamodell. In ihnen stehen:

Beispielhaft sieht man das an lkw.dd.php und dbxSession.dd.php. Dieselben DD-Daten beeinflussen Datenbankzugriff, Formularerzeugung, Reportspalten und Grid-Metadaten.

dbxForm und dbxReport sind keine kleinen Helfer, sondern zentrale Laufzeitklassen.

• dbxForm verwaltet Felder, Validierung, Formularstatus, Meldungen, Reloads, Sessionzustand und Rendering.
• dbxReport erweitert das um Tabellen-/Listenlogik, Pagination, Selektionslogik, Row-Actions, Formatierungen und Seitenaufbau.

Damit entstehen große Teile einer Anwendung aus Konfiguration plus Templates plus etwas Steuerlogik in Modulklassen.

Der Report zur Session-Liste ist ein typisches Beispiel: Filterfelder, Pagination, Row-Delete, Mehrfachselektion und Tabellenkopf werden nicht individuell von Hand geschrieben, sondern über die Report-Infrastruktur erzeugt.

Clientseitig ist dbxapp kein loser Haufen Skripte, sondern besitzt ein eigenes kleines Frontend-Framework:

• Namespace dbx
• Feature-Registry
• Asset-Loader für JS/CSS
• data-dbx-Parser
• Auto-Scan per MutationObserver
• UI-State in localStorage
• delegierte Events
• Geräte-/Loop-Abstraktion

Das bedeutet: Third-Party-Libs werden nicht roh benutzt, sondern hinter DBX-Features integriert. Das passt auch zu Grid/Tabulator und zum Ajax-System.

• Sehr schnell: extrem kurze Request-Zeiten passen zur einfachen serverseitigen Architektur.
• Deterministisch: Seiten entstehen aus klaren Templates und Modulen, nicht aus versteckter Magie eines großen Framework-Stacks.
• Hohe Wiederverwendbarkeit: Form- und Report-Infrastruktur spart sehr viel Standardarbeit.
• Starke Komposition: Module können überall eingebettet werden.
• DD als gemeinsames Metamodell: Datenbank, Rechte, UI und Validierung hängen zusammen.
• Serverseitig robust: kein Zwang zu API-first oder SPA-Architektur.
• Frontend kontrolliert: eigenes Core-System statt unkoordiniertem Wildwuchs.

• Hohe Einstiegshürde: ohne Verständnis von SysVar, ModulVar, Remember und SessionVal wirkt das System schnell verwirrend.
• Kern-API im Umbau: die wichtigsten früher globalen Zugriffe laufen jetzt über dbx(); verbleibende globale Hilfsfunktionen sollten bewusst klein gehalten werden.
• Session als zentrale Laufzeitbasis: praktisch, aber für neue Entwickler ungewohnt.
• Kontextwechsel im Interpreter: sehr mächtig, aber nur sauber beherrschbar, wenn Modulinstanz-Kontext exakt verstanden wird.
• Doppelte Namenswelten: gleiche Klassennamen als System- und Modulklasse können ohne Namespace-Verständnis irritieren.
• Dokumentationsbedarf: vieles ist logisch, aber nicht auf den ersten Blick selbsterklärend.

Wer dbxapp richtig benutzen will, sollte das System nicht mit Standard-MVC-Mustern verwechseln. Der richtige Zugang ist:

1. vom Ablauf aus denken – Request, Session, WebApp, Modul, Template, Interpreter, Ausgabe;
2. vom Zustand aus denken – SysVar, ModulVar, Remember, SessionVal;
3. vom DD aus denken – Daten, Rechte, UI, Validierung gehören zusammen;
4. von Komposition aus denken – Seiten setzen sich aus Modulen und Templates zusammen.

Dann wird klar: dbxapp ist kein zufälliges Alt-System, sondern ein bewusst serverseitig, schnell und produktionsnah aufgebautes Framework mit eigenem Architekturprofil.