Codex-Arbeitsanweisung

dbxapp Arbeitsanweisung für Codex

Diese Datei beschreibt, wie Codex an dbxapp arbeiten soll. Sie ist als Arbeitsanweisung für neue Sitzungen gedacht.

Grundrichtung

dbxapp wird als Borland-inspirierte PHP-Web-RAD-Runtime weiterentwickelt. dbxapp soll nicht Laravel, WordPress oder React-SPA nachbauen, sondern eine eigene komponentenorientierte Anwendungsumgebung bleiben.

Module sollen Anwendungen aus klaren DBX-Komponenten zusammensetzen. Die Komplexität gehört in Systemklassen und Runtime, nicht in jedes Modul.

Application Runtime
 -> Module
 -> Komponenten
    -> Forms
    -> Reports
    -> Grids
    -> Dialoge / OpenWin
    -> Editor
 -> DD/FD Metadaten
 -> Templates
 -> Client-Libs
 -> State / Remember
 -> Services ueber dbx()

Qualitätsziel

Gold ist Ziel, Diamant wird angestrebt. Funktioniert-irgendwie reicht nicht. Verantwortlichkeiten müssen stimmen, Namen müssen klar sein, und die Verwendung in Modulen muss einfach bleiben.

Wichtige Architekturregeln

• HTML gehört in Templates, nicht in PHP-Code.
• Module bleiben duenn und gut lesbar.
• Komplexität gehört in Systemklassen.
• DD/FD sind Metadaten und Designer-Schicht.
• Templates erzeugen die visuelle Struktur.
• dbxReport rendert Reports, ist aber nicht fest an DB gebunden.
• dbxDB ist für DB-Daten und DB-Aktionen verantwortlich.
• dbxForm ist für Formulare, Feldwerte und Zustand verantwortlich.
• dbxApi / dbx() ist die zentrale, klare System-API.
• Callbacks dienen der einfachen Individualisierung ohne globales Event-System.
• Eigene Klassen wie myReport extends dbxReport bleiben möglich.
• Keine inkompatiblen Konzeptänderungen ohne Rücksprache.

Namen und API

Namen müssen sprechend, kurz genug und eindeutig sein. Kryptische Namen sind zu vermeiden.

Bevorzugt:

dbx()->get_modul_var('record_count')
dbx()->set_modul_var('record_count', $count)
dbx()->get_remember_var(...)
dbx()->set_remember_var(...)
dbx()->get_system_obj('dbxReport')

Nicht bevorzugt:

dbx()->mod(...)
dbx()->rem(...)
dbx()->sys(...)

Module

Module sollen nach dem Prinzip write less, get more gebaut werden. Der einfache Standardfall soll mit wenig Code funktionieren. Bei Bedarf muss trotzdem eine saubere Erweiterung möglich sein.

$oReport = dbx()->get_system_obj('dbxReport');
$oReport->init('report-sessions');
$oReport->_dd = 'dbxSession';

Danach sollen möglichst viele Dinge automatisch aus DD/FD, Templates, Report-State und Systemkonventionen laufen.

Reports und Forms

• Reports und Forms sind zustandsfähige Komponenten.
• Sie kennen nach Möglichkeit ihre DD/FD.
• Sie speichern und restaurieren ihren Zustand.
• Reload/F5 soll den Zustand erhalten.
• Feldwerte kommen aus Formular, Request oder Remember-State.
• Pagination, Auswahl, Filter und Buttons sollen einheitlich funktionieren.
• Datumswerte bleiben intern DB-konform und werden in der Anzeige usergerecht formatiert.

Datumsformatierung in Reports soll zentral passieren:

• _rpt_format[$field] hat Vorrang.
• Danach gilt $field['convert'] aus DD/FD.
• Danach gilt $field['type'] aus DD/FD.

$field['type']='date';
$field['type']='datetime';
$field['convert']='date';
$field['convert']='date_time';

Deutsche Anzeige:

2026-05-01              -> 01.05.2026
2026-05-01 16:12:26     -> 01.05.2026 16:12:26
2026-05-01 16:12:26.439 -> 01.05.2026 16:12:26.439

Callbacks

Callbacks sollen optional und einfach sein. Kein globales Event-System, keine Listener-Registrierung, keine Prioritäten, keine Fremdmodule.

Ein DBX-Objekt ruft optionale Methoden auf dem aktuellen Modul-Objekt auf, wenn sie existieren. Fehlen sie, passiert nichts.

private function report_sessions_body($oObj, $content) {
    return $content;
}

private function report_sessions_next_record($oObj, $record) {
    return $record;
}

Der erste Parameter ist immer das aufrufende DBX-Objekt. Der zweite Parameter ist der zu filternde Wert. Die Rückgabe ersetzt den zweiten Parameter.

Datenquelle und Verantwortung

Deshalb dürfen DB-Aktionen nicht in dbxReport liegen. Beispiel: Tabelle leeren gehört zu dbxDB, nicht zu dbxReport.

$ok = $db->delete_tab($dd);

dbxReport darf dafür einen Button oder Platzhalter rendern, aber nicht selbst die DB-Tabelle leeren.

Templates

• HTML wird über Templates erzeugt.
• PHP-Code soll keine langen HTML-Fragmente zusammenbauen.
• Ausnahmen nur bei sehr kleinen, klar begründeten Sonderfaellen.
• Bootstrap-Klassen sollen genutzt werden, wenn es für Standard-UI passt.
• Komponentenbezogenes Styling liegt in passenden CSS-Dateien.

Arbeitsweise für Codex

1. Vor Änderungen die betroffenen Dateien lesen.
2. Bestehende DBX-Konventionen beachten.
3. Kleine, gezielte Patches machen.
4. Keine grossen Refactorings ohne Rücksprache.
5. Keine inkompatiblen Konzeptänderungen ohne Rücksprache.
6. Nach Änderungen PHP-Lint ausführen.
7. Wenn sinnvoll, HTTP-Smoke-Test für betroffene Route ausführen.
8. Alte Altlasten dürfen entfernt werden, wenn das neue Konzept sauberer ist.

Aktueller Fokus

Die modernisierten Admin-Reports sind:

• Sessions
• Missing
• SysMsg
• Trace

Diese Reports dienen als Referenz für neue einheitliche DBX-Report-Struktur.