dbxapp LEGO-RAD

Komponenten-Stecknorm

Diese Spezifikation beschreibt die gemeinsame Anschluss-Sprache fuer DBX-Komponenten. Sie ist Entscheidungsgrundlage fuer Form, Report, Grid, Dialog, Window, Workflow und Process.

kompatibel schrittweise DD / FD State Templates Hooks Client-Libs

Grundregel:
Diese Stecknorm ist zuerst ein Zielvertrag. Sie erzwingt noch keine inkompatible Basisklasse und ersetzt keine bestehende Kernlogik ohne Ruecksprache.

1. Ziel

DBX-Komponenten sollen sich gleichartig konfigurieren, starten, rendern, speichern und erweitern lassen. Module sollen fachliche Absicht ausdruecken und nicht technische Infrastruktur wiederholen.

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

2. Gemeinsame Anschluesse

Anschluss	Bedeutung	Beispiele
id	Eindeutige Komponenten-ID innerhalb des aktuellen Kontextes.	sessions, customer-edit, import-run
context	Modul-, Instanz-, Request- und Benutzerkontext.	modul, run1, run2, instance_id, uid
dd	Daten-/Tabellen-/Feldwissen.	dbxSession, dbx\|dbxTrace, modul\|kunde
fd	Formular-/UI-Felddefinition.	dbxAdmin\|rpt-sessions-selection
tpl	Darstellungsschablone fuer HTML-Ausgabe.	modul\|report-sessions, dbx\|pagination
data	Arbeitsdaten der Komponente.	record, rows, values, options
state	Persistenter Komponenten-Zustand.	filter, sort, page, selected, draft_id
request	Aktuelle Eingaben aus GET/POST/AJAX.	submit, action, field values
actions	Kommandos der Komponente.	save, delete, select, export, show
hooks	Erweiterungspunkte ohne Kernel-Hack.	before_validate, after_save, before_render
render	Ausgabe ueber Templates und Replaces.	run(), render(), get_html()
client	Client-Lib und CSS-Aktivierung.	data-dbx="lib=form\|...", report.js, c-report.css
trace	Nachvollziehbarkeit von Aktionen, Dateien und Zustand.	dbxTrace, editor files, debug context

3. Standard-Lifecycle

Der Lifecycle ist die gemeinsame Denkstruktur. Bestehende Klassen muessen ihn nicht sofort exakt als Methoden besitzen, sollen aber schrittweise daran ausgerichtet werden.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

construct

Objekt erzeugen, harte Defaults setzen, keine teuren Nebenwirkungen.

init_context

Modul, Instanz, Benutzer, Request-Ziel und State-Key bestimmen.

load_definition

DD, FD, Templates, Felder, Aktionen und Optionen laden.

load_state

Remember-/Session-/Process-State laden. F5 darf Zustand nicht zerstoeren.

read_request

GET/POST/AJAX lesen und vom gespeicherten Zustand unterscheiden.

validate

Werte, Typen, Rechte und Regeln pruefen. DD/FD sollen die Pruefung ermoeglichen.

process

Aktionen ausfuehren: save, delete, select, export, custom actions.

render

HTML erzeugen, Client-Libs/CSS anmelden, Editor-Dateien registrieren.

save_state

Neuen Zustand speichern. Nur definierter State wird persistiert.

4. Minimaler Modulcode als Zielbild

Report

$r = dbx()->report('sessions');
$r->dd('dbxSession');
$r->fd('dbxAdmin|rpt-sessions-selection');
$r->tpl('dbxAdmin|report-sessions');
return $r->run();

Form

$f = dbx()->form('customer-edit');
$f->dd('crm|customer');
$f->fd('crm|customer-edit');
$f->tpl('crm|form-customer');
return $f->run();

Methodennamen wie dd(), fd() und tpl() sind Vorschlag, nicht Beschluss. Vor Implementierung abstimmen.

5. Kompatibilitaetsregeln

Bestehendes Verhalten von dbxForm und dbxReport bleibt erhalten, bis ein neuer Weg abgestimmt ist.
Neue APIs werden zunaechst additiv eingefuehrt.
Kurze Alt-Methoden duerfen intern bleiben, aber neue Modulentwicklung nutzt sprechende Namen.
State-Keys muessen modul- und instanzsicher sein.
FD/DD/Templates/Klassen muessen weiterhin fuer Editor und Trace registrierbar sein.
Client-Libs laden ihre CSS komponentenzentriert.
Mobile/Tablet ist Web-first. Native App-Anbindung bleibt Adapter-Schicht.

6. Erste technische Umsetzungsschritte

Bestehende Methoden in dbxForm und dbxReport den Lifecycle-Phasen zuordnen.
Gemeinsame Begriffe fuer Kontext, Definition, State, Request und Render festlegen.
Sprechende dbx()-Factory-Methoden als additive Schicht planen.
Eine kleine, nicht-invasive dbxComponent-Spezifikation erstellen.
Erst danach entscheiden, ob dbxComponent Basisklasse, Trait oder nur Konvention wird.

Stand: 2026-04-29. Diese Datei ist eine technische Spezifikation und noch keine Implementierungsentscheidung. Inkompatible Aenderungen werden vor Umsetzung besprochen.