RAD-Konzept

Auf dieser Seite

dbxapp als Borland-inspirierte Web-RAD-Runtime

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 übernehmen, 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 für 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. Schöne Architektur ohne konkreten Gewinn wird nicht eingebaut.

Gold:
  klar
  schnell
  sicher
  wiederverwendbar
  wenig Modulcode

Borland-Prinzipien für 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 größere 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 über dbx()

Module sollen nicht viele globale Funktionen kennen müssen. 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 können. 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-Hülle

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

Eine spätere Android-App waere primär eine WebView-Hülle mit nativen Brücken für 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 für Umbauten

Inkompatible konzeptionelle Änderungen werden vor Umsetzung besprochen.
Altlasten dürfen entfernt werden, wenn der neue Weg klarer und besser ist.
Bestehende Kernlogik wird nicht blind ersetzt, sondern Schritt für Schritt angehoben.
Neue APIs müssen sprechend benannt sein.
Modulcode soll weniger technische Details enthalten, nicht mehr.
Jede Komponente muss ihren Zustand nach Reload sinnvoll wiederherstellen können.
Client-Libs sind Komponenten-Libs: form.js, report.js, window.js, grid.js.
DD/FD/Templates/Klassen müssen 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 eingeführt, 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 zusammengeführt. Keine schwere Desktop-Kopie.

Phase 5: Mobile/Tablet polish

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

Dokumentstand: 2026-04-29. Dieses Dokument ist ein Architektur-Leitbild und keine Rückwärtskompatibilitätsgarantie. Es dient als gemeinsame Entscheidungsgrundlage für die neue dbxapp-Version.