1. Grundidee

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

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 groessere Komponente soll dieselben Grundanschluesse besitzen. Dadurch koennen 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

3. Ziel fuer Modulautoren

Modulcode soll fachlich bleiben. Auch Anwender mit wenig Programmiererfahrung sollen kleine Anwendungen bauen koennen, 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 moeglich 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 tatsaechlich verwendet wurden.

4. Anpassbarkeit ohne Kernel-Aenderung

Alles muss anpassbar bleiben, aber die Anpassung soll ueber 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 fuer Experten.

dbxForm   -> myForm
dbxReport -> myReport
dbxDB     -> myDB
dbxTPL    -> myTPL
dbxWebApp -> myWebApp

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() koennen als Kompatibilitaetsbruecke bestehen bleiben. Neue Struktur soll aber klar ueber Basis-Lifecycle, parent:: und geschuetzte Hook-Methoden laufen.

6. Standardverhalten im Kern

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

Module duerfen weiter Speziallogik enthalten, aber Standardverhalten soll nicht immer wieder neu geschrieben werden muessen.

7. Workflow und Process

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

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

Workflows duerfen 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 fuer grosse Datenmengen laufen in Chunks:

State laden
Pause/Cancel pruefen
Chunk laden
Chunk verarbeiten
Fortschritt speichern
Status zurueckgeben
naechster Tick

8. Persistenter Prozess-State

Ein Prozess wie das Bearbeiten von 100000 Datensaetzen muss nach Browser-Schliessen 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 Datensaetzen verarbeitet wurden, muss dbxapp beim Wiederoeffnen den Prozess finden, den Fortschritt anzeigen und ab dem naechsten sicheren Datensatz fortsetzen koennen.

9. Wiederherstellung von UI-State

Nicht nur Prozesse, auch normale Arbeitszustaende 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 Wiederherstellungsmoeglichkeit anbieten.

10. Roadmap

11. Pilot-Erkenntnisse aus aktuellen Modulen

• myLKW zeigt Bedarf fuer Action-Dispatcher, Prozess-State, JSON-Endpunkte, Grid-Sync und fachliche Aktionen.
• myLKW_list zeigt Bedarf fuer offizielle Grid-Komponente mit read/sort/save/delete/sync.
• myLKW_report zeigt Bedarf fuer 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.