dbxapp Wissen RAD-Roadmap

RAD-Roadmap

Auf dieser Seite
  1. dbxapp als LEGO-RAD-Runtime
    1. 1. Grundidee
    2. 2. LEGO statt Puzzle
    3. 3. Ziel für Modulautoren
    4. 4. Anpassbarkeit ohne Kernel-Änderung
    5. 5. Komponenten-Lifecycle
    6. 6. Standardverhalten im Kern
    7. 7. Workflow und Process
    8. 8. Persistenter Prozess-State
    9. 9. Wiederherstellung von UI-State
    10. 10. Roadmap
    11. 11. Pilot-Erkenntnisse aus aktuellen Modulen
    12. 12. Goldene Regeln
dbxapp Zielbild und Roadmap

dbxapp als LEGO-RAD-Runtime

dbxapp soll eine klare, schnelle und sichere PHP-Web-RAD-Runtime werden: Borland-inspiriert, DD/FD-getrieben, komponentenbasiert, workflowfähig und ohne versteckte Kern-Magie. Die Produktivität entsteht aus einfachen Bausteinen, die gut zusammenpassen.

LEGO-Prinzip DD / FD Form Report Grid Workflow Process Persistenter State myX
Leitsatz
Module sollen dbxapp benutzen, nicht dbxapp nachbauen. Technische Komplexität gehört in Kern und Komponenten. Fachliche Anpassung gehört in DD, FD, Templates, Hooks, Modulklassen und myX.

1. Grundidee

dbxapp soll das Beste aus Borland, Concept16 und Visual DataFlex/4GL in eine moderne PHP-, JavaScript- und CSS-Webruntime übersetzen. Nicht als nostalgische Kopie, sondern als klares RAD-System für datengetriebene Business-Anwendungen.

Borland
Komponenten, Properties, Events, Lifecycle, Designer-Gefuehl.
Concept16 / 4GL
Datengetriebene Fachanwendungen, schnelle Masken, Listen, Prozesse.
DataFlex
DD als Herz, Business-Regeln nahe an Daten, wenig Modulcode.

dbxapp bleibt dabei dbxapp: serverseitige PHP-Runtime, DD, FD, Templates, Module, Session-/Remember-State, Client-Libs und myX-Vererbung.

2. LEGO statt Puzzle

Die Architektur soll nicht aus Spezialteilen bestehen, die nur an genau einer Stelle passen. Jede größere Komponente soll dieselben Grundanschluesse besitzen. Dadurch können Bausteine kombiniert, ersetzt und erweitert werden.

dbx()->form('kunde')
dbx()->report('kunden')
dbx()->grid('kunden')
dbx()->dialog('delete')
dbx()->window('kunde')
dbx()->workflow('kunden-import')
dbx()->process('kunden-index')

Alle diese Bausteine sollen dieselbe Anschluss-Sprache verstehen:

id
context
dd
fd
tpl
data
state
request
actions
events / hooks
render
client
trace
Keine versteckte Magie: Konventionen sind erlaubt, aber jede automatische Entscheidung muss im Trace sichtbar sein: verwendete DD, FD, Templates, Klassen, Hooks, State-Keys und Actions.

3. Ziel für Modulautoren

Modulcode soll fachlich bleiben. Auch Anwender mit wenig Programmiererfahrung sollen kleine Anwendungen bauen können, wenn DD, FD und Templates vorbereitet sind.

class kunden {
    public function list() {
        return dbx()->report('kunden')
            ->dd('kunde')
            ->fd('kunden|rpt-kunden')
            ->rowEdit()
            ->rowDelete()
            ->run();
    }

    public function edit() {
        return dbx()->form('kunde')
            ->dd('kunde')
            ->fd('kunden|frm-kunde')
            ->run();
    }
}

Minimal soll auch möglich sein:

return dbx()->report('kunden')->run();
return dbx()->form('kunde')->run();

In diesem Fall sucht dbxapp nach klaren, dokumentierten Konventionen. Der Trace zeigt danach, welche DD, FD, Templates und Klassen tatsächlich verwendet wurden.

4. Anpassbarkeit ohne Kernel-Änderung

Alles muss anpassbar bleiben, aber die Anpassung soll über klare Ebenen laufen:

  1. DD: Daten, Felder, Defaults, Regeln, Rechte, Labels, UI-Metadaten.
  2. FD: konkrete Formular-/Report-/Grid-Feldsicht.
  3. Templates: Darstellung und Layout.
  4. Properties: einfache Komponentenoptionen wie Rows, Sort, Buttons, Modus.
  5. Hooks: gezielte Erweiterungspunkte ohne Kopieren der Komponente.
  6. Modulklassen: fachliche Speziallogik.
  7. myX: systemweite Vererbung für Experten.
dbxForm   -> myForm
dbxReport -> myReport
dbxDB     -> myDB
dbxTPL    -> myTPL
dbxWebApp -> myWebApp
Regel: Wenn eine fachliche Anforderung nur durch Kernel-Änderung erreichbar ist, fehlt vermutlich ein offizieller Steckpunkt.

5. Komponenten-Lifecycle

Form, Report, Grid, Dialog, Window, Workflow und Process sollen langfristig nach einem vorhersagbaren Ablauf arbeiten. Die heutigen Methoden bleiben kompatibel, werden aber intern auf klarere Schritte ausgerichtet.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state
trace

forward_init() und forward_run() können als Kompatibilitätsbrücke bestehen bleiben. Neue Struktur soll aber klar über Basis-Lifecycle, parent:: und geschützte Hook-Methoden laufen.

6. Standardverhalten im Kern

Viele Dinge, die heute in Modulen manuell passieren, sollen offizielle Standardbausteine werden.

Form

RID lesen, Daten laden, Felder aufbauen, Submit prüfen, changed prüfen, speichern, Meldungen setzen, State sichern.

Report

Suche, Sortierung, Pagination, Row-Buttons, Multi-Actions, Selektion, Daten laden, Row-Hooks.

Grid

Read, Sort, Save, Delete, Sync, JSON-Ausgabe, Client-Kopplung, DD-Spalten.

Module dürfen weiter Speziallogik enthalten, aber Standardverhalten soll nicht immer wieder neu geschrieben werden müssen.

7. Workflow und Process

Workflows und Prozesse werden getrennt gedacht. Ein Workflow beschreibt den fachlichen Ablauf. Ein Process beschreibt die technische, wiederaufnehmbare Ausführung.

Workflow = fachlicher Ablauf
Process  = technische Ausfuehrung
Step     = einzelner Schritt
State    = gespeicherter Zustand

Workflows dürfen nicht statisch sein. Sie sollen smart auf Zustand, Fehler, Benutzerentscheidungen und Rechte reagieren.

upload -> preview -> validate
if valid: import
if invalid: mapping
if cancelled: cleanup
if error: retry_or_abort
summary

Prozesse für grosse Datenmengen laufen in Chunks:

State laden
Pause/Cancel pruefen
Chunk laden
Chunk verarbeiten
Fortschritt speichern
Status zurueckgeben
naechster Tick
Wichtig: Der Browser ist nur Anzeige und Steuerpult. Die Wahrheit liegt serverseitig im persistenten dbxapp-State.

8. Persistenter Prozess-State

Ein Prozess wie das Bearbeiten von 100000 Datensätzen muss nach Browser-Schließen oder Unterbrechung fortsetzbar sein. Der letzte sichere Stand wird dauerhaft gespeichert.

dbxProcess
  id
  process_key
  workflow_key
  user_id
  modul
  component_id
  status
  current_step
  cursor
  processed_count
  total_count
  payload_json
  result_json
  error_json
  pause_requested
  cancel_requested
  started_at
  updated_at
  finished_at

Statuswerte:

new
running
paused
cancel_requested
cancelled
done
error
interrupted

Wenn 53589 von 100000 Datensätzen verarbeitet wurden, muss dbxapp beim Wiederöffnen den Prozess finden, den Fortschritt anzeigen und ab dem nächsten sicheren Datensatz fortsetzen können.

9. Wiederherstellung von UI-State

Nicht nur Prozesse, auch normale Arbeitszustände sollen wiederherstellbar werden:

  • aktives Modul
  • aktiver Workflow
  • offene Fenster und Dialoge
  • aktive Tabs
  • Report-Seite, Suche, Sortierung, Selektion
  • Form-RID und noch nicht gespeicherte Formularwerte
  • Grid-Filter, Auswahl, Scroll-/Cursorstand soweit sinnvoll
  • laufende, pausierte oder fehlerhafte Prozesse

Beim App-Start soll dbxapp offene Arbeit erkennen und eine klare Wiederherstellungsmöglichkeit anbieten.

10. Roadmap

Phase 1: Begriffe und Stecknorm

  1. Offizielle Begriffe definieren: Component, Form, Report, Grid, Dialog, Window, Workflow, Process, Step, State.
  2. Gemeinsame Komponenten-Anschluesse dokumentieren.
  3. State-Ebenen definieren: sys, mod, remember, session, process.
  4. Trace-Ausgabe für Komponenten konzipieren.

Phase 2: dbxApi als Werkbank

  1. dbx()->db() ergänzen.
  2. dbx()->tpl() ergänzen.
  3. dbx()->form($id) ergänzen.
  4. dbx()->report($id) ergänzen.
  5. Später grid(), dialog(), window(), workflow(), process().
  6. Alte API kompatibel halten.

Phase 3: Form und Report glätten

  1. Lifecycle in dbxForm sichtbar strukturieren.
  2. dbxReport sauberer auf dbxForm aufbauen.
  3. Direkte Property-Zugriffe durch Methoden ergänzen.
  4. Alte Properties weiter unterstuetzen.
  5. Row- und Render-Hooks definieren.

Phase 4: Standardverhalten zentralisieren

  1. Standard-Form-Flow in den Kern ziehen.
  2. Standard-Report-Flow in den Kern ziehen.
  3. Standard-Grid-Flow mit JSON-Endpunkten aufbauen.
  4. Action-Dispatcher für Module einführen.

Phase 5: Persistente Process-Schicht

  1. DD/Tabelle für dbxProcess entwerfen.
  2. Chunk-Runner bauen.
  3. Pause, Resume, Cancel, Retry, Status, Log implementieren.
  4. resumeLast() für Benutzer/Modul/Workflow einführen.
  5. App-Start prüft offene Prozesse.

Phase 6: Workflow-Schicht

  1. Einfache Smart-Transitions: next, back, choice, repeat, stop.
  2. Workflow-State speichern.
  3. Workflow-Panel und Wiederherstellung vorbereiten.
  4. Kein grosses BPM-System, sondern dbxapp-typische kleine Bausteine.

Phase 7: UI und Wiederherstellung

  1. Process-Panel: Fortschritt, Log, Pause, Weiter, Abbrechen.
  2. Restore-Leiste für offene Arbeit.
  3. UI-State für Tabs, Fenster, Reports, Forms, Grids speichern.
  4. Trace und Editor-Sicht ausbauen.

Phase 8: Pilotmodule

  1. dbxAdmin Session-Liste als Report-Pilot.
  2. dbxUser_admin User-Liste und Gruppen-Form als Form/Report-Pilot.
  3. myLKW_list als Grid-/Ajax-Pilot.
  4. myLKW_report als Spezialreport mit Row-Hooks.
  5. Ein Prozess-Pilot für Import, DD-Update oder LKW-Sync.

Phase 9: Doku und Migration

  1. Doku für Modul neuer Stil.
  2. Doku für Komponenten-Bausteine.
  3. Doku für Hooks und myX.
  4. Doku für Workflow und Process.
  5. Neue Module nur noch nach neuer Methodik.
  6. Alte Module lauffähig lassen und bei Bedarf neu bauen.

11. Pilot-Erkenntnisse aus aktuellen Modulen

  • myLKW zeigt Bedarf für Action-Dispatcher, Prozess-State, JSON-Endpunkte, Grid-Sync und fachliche Aktionen.
  • myLKW_list zeigt Bedarf für offizielle Grid-Komponente mit read/sort/save/delete/sync.
  • myLKW_report zeigt Bedarf für Spezialreport-Hooks statt direkter Interna.
  • dbxUser_admin zeigt typische Admin-Reports mit Row-/Multi-Actions, Modal, Suche und Pagination.
  • dbxContent_edit zeigt Standard-Form-Flow und Observer/Wait-Pattern.

12. Goldene Regeln

Ein Modulautor soll dbxapp benutzen, nicht dbxapp nachbauen.

Wenn ein Modul technischen Standardcode enthaelt,
fehlt wahrscheinlich ein Baustein im Kern.

Der Browser ist Anzeige und Steuerpult, nicht die Wahrheit.

Der letzte sichere Stand muss serverseitig gespeichert sein.

Kein Fachproblem darf eine Kernel-Aenderung erzwingen.

Konventionen sind erlaubt, aber immer tracebar.

Bestehende Module bleiben kompatibel, neue Module folgen der neuen Methodik.

Dokumentstand: 2026-04-29. Diese Roadmap ist eine Ziel- und Arbeitsgrundlage. Inkompatible Konzeptänderungen werden vor Umsetzung besprochen.