Komponenten-Stecknorm

Auf dieser Seite

1. Ziel
2. Gemeinsame Anschluesse
3. Standard-Lifecycle
4. Minimaler Modulcode als Zielbild
5. Kompatibilitätsregeln
6. Erste technische Umsetzungsschritte

dbxapp LEGO-RAD

Diese Spezifikation beschreibt die gemeinsame Anschluss-Sprache für DBX-Komponenten. Sie ist Entscheidungsgrundlage für 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 Rücksprache.

1. Ziel

DBX-Komponenten sollen sich gleichartig konfigurieren, starten, rendern, speichern und erweitern lassen. Module sollen fachliche Absicht ausdrücken 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 für 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 über 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 müssen 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 prüfen. DD/FD sollen die Prüfung ermöglichen.

process

Aktionen ausführen: 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. Kompatibilitätsregeln

Bestehendes Verhalten von dbxForm und dbxReport bleibt erhalten, bis ein neuer Weg abgestimmt ist.
Neue APIs werden zunächst additiv eingeführt.
Kurze Alt-Methoden dürfen intern bleiben, aber neue Modulentwicklung nutzt sprechende Namen.
State-Keys müssen modul- und instanzsicher sein.
FD/DD/Templates/Klassen müssen weiterhin für 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 für 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.

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