dbxapp Zielarchitektur

dbxapp als Borland-inspirierte Web-RAD-Runtime

dbxapp soll das beste Konzept alter Borland-Systeme aufnehmen: Application Runtime, Komponenten, klare Lebenszyklen, Metadaten, Designer-Gefühl und schnelle Business-Entwicklung. dbxapp bleibt dabei eine moderne PHP-Webanwendung mit DD, FD, Templates, Modulen und Client-Libs.

Application Runtime Komponenten DD / FD Templates State Mobile Web RAD

Leitsatz

Borland-Prinzipien uebernehmen, aber nicht die alte Oberflaeche kopieren. dbxapp soll sich wie eine professionelle RAD-Umgebung denken lassen und trotzdem dbxapp bleiben.

Was dbxapp sein soll

dbxapp ist eine serverseitige, komponentenbasierte Web-Application-Runtime fuer modulare, datengetriebene Business-Anwendungen.

dbxApp
  Runtime / Kernel
  Context / State
  Module
  Components
  DD / FD
  Templates
  Client Runtime

Was dbxapp nicht sein soll

dbxapp soll kein Laravel-Klon, kein WordPress-Klon und keine reine React-SPA werden. Es soll auch keine nostalgische Desktop-Kopie im Browser werden.

Nicht:
  alles als Fenster
  alles als Client-State
  alles als ORM
  alles als Controller
  UI-Spielerei vor Nutzen

Gold-/Diamant-Massstab

Jede neue Struktur muss Module einfacher, sicherer oder konsistenter machen. Schoene Architektur ohne konkreten Gewinn wird nicht eingebaut.

Gold:
  klar
  schnell
  sicher
  wiederverwendbar
  wenig Modulcode

Borland-Prinzipien fuer dbxapp

1. Application Runtime statt losem PHP-Skript

dbxapp startet, baut Kontext auf, laedt Module, erzeugt Komponenten, sammelt Output, rendert Templates und aktiviert Client-Verhalten.

2. Komponenten statt Funktionssammlung

Forms, Reports, Grids, Dialoge, Fenster und Editoren sollen als Komponenten verstanden werden. Eine Komponente besitzt Kontext, Definition, Zustand, Verhalten und Ausgabe.

3. DD und FD als deklarative Designer-Schicht

DD beschreibt Daten und Beziehungen. FD beschreibt Formular-/UI-Felder. Templates beschreiben Darstellung. Klassen beschreiben Verhalten und Businesslogik.

4. Einheitlicher Lebenszyklus

Jede groessere Komponente soll langfristig denselben Ablauf besitzen. Dadurch werden Form, Report, Grid und Window vorhersagbar.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

5. Zentrale Runtime-API ueber dbx()

Module sollen nicht viele globale Funktionen kennen muessen. Sie sollen wenige klare Services nutzen.

dbx()->db()
dbx()->tpl()
dbx()->form()
dbx()->report()
dbx()->grid()
dbx()->dialog()
dbx()->window()
dbx()->get_modul_val()
dbx()->set_modul_val()
dbx()->get_remember()
dbx()->set_remember()

Modul-Zielbild

Module sollen schnell und sicher geschrieben werden koennen. Das Modul beschreibt was es will, nicht wie dbxapp intern Request, State, DD, FD, Template, AJAX und Validierung verbindet.

Report

$oReport = dbx()->report('sessions');
$oReport->set_dd('dbxSession');
$oReport->set_fd('dbxAdmin|rpt-sessions-selection');
return $oReport->run();

Form

$oForm = dbx()->form('customer');
$oForm->set_dd('customer');
$oForm->set_fd('myModule|customer-edit');
return $oForm->run();

Regel: Modulcode soll fachlich bleiben. Technische Wiederholungen wandern in Komponenten, Basisklassen oder dbx()-Services.

Mobile, Tablet und App-Huelle

dbxapp bleibt eine Webanwendung. Mobile und Tablet werden ueber responsive Komponenten, Layouts und Client-Libs unterstuetzt.

Eine spaetere Android-App waere primaer eine WebView-Huelle mit nativen Bruecken fuer Handy-Funktionen:

Kamera Dateisystem Termine Adressen GPS Push Scanner

Wichtig: Diese nativen Funktionen sind optionale Adapter. Der Kern bleibt Web, PHP, DD, FD, Templates, Komponenten und dbx()-Runtime.

Entscheidungsregeln fuer Umbauten

Inkompatible konzeptionelle Aenderungen werden vor Umsetzung besprochen.
Altlasten duerfen entfernt werden, wenn der neue Weg klarer und besser ist.
Bestehende Kernlogik wird nicht blind ersetzt, sondern Schritt fuer Schritt angehoben.
Neue APIs muessen sprechend benannt sein.
Modulcode soll weniger technische Details enthalten, nicht mehr.
Jede Komponente muss ihren Zustand nach Reload sinnvoll wiederherstellen koennen.
Client-Libs sind Komponenten-Libs: form.js, report.js, window.js, grid.js.
DD/FD/Templates/Klassen muessen im Editor- und Trace-Konzept sichtbar bleiben.

Vorgeschlagene Roadmap

Phase 1: Sprache und Struktur klaeren

Runtime-Begriffe, dbx()-API-Namen, Komponenten-Lifecycle und Modul-Konventionen definieren. Keine harten Brueche ohne gemeinsame Entscheidung.

Phase 2: dbxForm und dbxReport angleichen

Beide Komponenten bekommen einheitlichere State-, Request-, Definition- und Render-Ablage. Bestehendes Verhalten bleibt erhalten, wo es sinnvoll ist.

Phase 3: dbxComponent als Basiskonzept

Eine Basisklasse oder ein Basistrait wird erst eingefuehrt, wenn klar ist, welche gemeinsamen Funktionen wirklich stabil sind.

Phase 4: Workspace und Window-Konzept

openWin, Dialoge, Editorfenster, Reports und Statusbereiche werden zu einem leichten Workspace-Konzept zusammengefuehrt. Keine schwere Desktop-Kopie.

Phase 5: Mobile/Tablet polish

Komponenten bekommen responsive Regeln und mobile Bedienlogik. Native App-Anbindung bleibt optional ueber Adapter.

Stand: 2026-04-29. Dieses Dokument ist ein Architektur-Leitbild und keine Rueckwaertskompatibilitaetsgarantie. Es dient als gemeinsame Entscheidungsgrundlage fuer die neue dbxapp-Version.

RAD-Konzept