dbxapp Wissen Form- und Report-Lifecycle
Anwender Entwickler

Form- und Report-Lifecycle

dbxapp LEGO-RAD

dbxForm / dbxReport Lifecycle-Analyse

Analyse der aktuellen Form- und Reportklassen gegen die geplante Komponenten-Stecknorm. Ziel ist Einordnung, nicht Umbau.

dbxForm dbxReport Lifecycle State Request Render
Arbeitsregel
Diese Analyse begruendet spaetere Schritte. Sie aendert keine Kernlogik.

1. Kurzbewertung

dbxForm und dbxReport sind bereits echte zustandsfaehige Komponenten. Der Kern ist tragfaehig. Die naechste Qualitaetsstufe liegt nicht in einem Rewrite, sondern in klarer Zuordnung: Kontext, Definition, State, Request, Validierung, Prozess und Render muessen als erkennbare Phasen gepflegt werden.

Hauptbefund: Die Funktionalitaet ist schon vorhanden, aber noch nicht konsequent als gemeinsame Stecknorm sichtbar.

2. Ziel-Lifecycle

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

Dieser Lifecycle ist eine Denk- und Ordnungsstruktur. Er muss nicht sofort 1:1 als neue Basisklasse implementiert werden.

3. dbxForm: aktuelle Zuordnung

Lifecycle-Phase Aktuelle Methoden / Felder Bewertung
construct __construct(), clear() Grundinitialisierung vorhanden. Konstruktor und Reset-Logik sind funktional, aber nicht als Lifecycle-Phase benannt.
init_context forward_init(), init(), _fid, _dbx_modul, _dbx_action, _dbx_page, _dbx_design, _dbx_lng Stark. Kontext wird zentral in forward_init() gesetzt. Das ist bereits ein guter Steckpunkt.
load_definition add_fld(), add_flds(), read_dd_fields_direct(), get_dd_fields_source(), get_dd(), get_dd_fld() Vorhanden, aber breit verteilt. DD/FD-Aufloesung funktioniert, sollte langfristig begrifflich klarer als Definitionsphase sichtbar werden.
load_state load_sysdata(), load_workflow_state(), get_state_value(), get_fld_val() Stark. Formularzustand wird aus Session/Remember geladen. get_fld_val() verbindet State und Request sinnvoll.
read_request evaluate_request(), resolve_fld_val(), get_post_data(), get_post(), _get_post_data(), _get_post(), submit() Vorhanden. evaluate_request() ist der richtige Kern. Request-Rohzugriffe sollten in neuem Code zunehmend durch Komponentenmethoden ersetzt werden.
validate check_fld_data(), check_flds_data(), errors(), warnings(), oValidator Stark. Validierung ist zentral und wird nur einmal pro Request-Zyklus ausgefuehrt.
process set_post(), save_post(), view_sync(), set_state_value(), Workflow-State-Methoden Standard-Prozesspfade sind vorhanden. Fachlogik bleibt bewusst im Modul moeglich. Das ist DBX-konform.
render forward_run(), run(), get_tpl(), merge_tpl_data(), merge_fld_data(), merge_obj(), get_form_msg(), add_editor_markers() Stark, aber umfangreich. Render ist funktional, enthaelt aber viele Teilaufgaben. Spaetere Glattung moeglich.
save_state store_sysdata(), store_workflow_state(), set_form_saved(), bump_form_version() Vorhanden. Wichtig fuer F5-/Reload-Stabilitaet. Muss bei Reports konsequent mitgenutzt werden.

4. dbxReport: aktuelle Zuordnung

Lifecycle-Phase Aktuelle Methoden / Felder Bewertung
construct extends dbxForm, clear() Nutzt Form-Basis. Das ist richtig, weil Report eine spezialisierte Form-/Listenkomponente ist.
init_context init(), forward_init(), _dbx_modul, _fid, _next_i Vorhanden. init() setzt Report-spezifische Seitendaten und ruft Form-Init.
load_definition create_selection_fields(), add_flds(), _fd, _dd, _rflds, set_form_selects() Report-Selektion ueber FD ist korrekt. Die Methode gehoert klar zur Definitionsphase.
load_state load_sysdata(), get_fld_val(), _report_state_flds, get_multi_selects() Konzeptionell richtig. Reportwerte sollen ueber get_fld_val() aus Form-State/Request kommen, nicht ueber direkte Modulvariablen-Spiegelung.
read_request get_fld_val(), apply_tabulurator_request(), check_is_multiselect(), parse_multi_select_ids() Vorhanden. Report-spezifische Request-Aktionen sind klar, aber noch nicht einheitlich als Actions benannt.
validate dbxForm::check_flds_data(), Validator-Regeln in FD/DD Nutzt Form-Validierung. Gut. Report-interne Parameter wie Sortierung/Where muessen weiter konsequent validiert werden.
process set_multi_select(), del_multi_select(), del_selected(), add_rwhere_search(), add_rwhere_select() Viele Reportprozesse sind vorhanden. Sie sollten spaeter als standardisierte Actions sichtbar werden.
render run(), split_tpl(), get_report_haeder(), get_report_body(), get_report_footer(), pagination(), run_body() Stark. Report-Rendering ist funktionsreich, aber gewachsen. Keine Rewrite-Kandidatur, sondern Glattung ueber klare Phasen.
save_state store_sysdata(), Multi-Select Remember, Report-State ueber dbxForm Vorhanden. Report-State muss weiter konsequent in der Komponente bleiben, damit F5 stabil ist.

5. Staerken

Form und Report sind bereits Komponenten

Sie besitzen Kontext, State, Request-Auswertung, Validierung, Rendering und Persistenzpunkte.

dbxReport extends dbxForm ist strategisch richtig

Reports brauchen Formularzustand fuer Filter, Pagination, Sortierung und Auswahl. Die Vererbung ist kein Fehler, sondern ein sinnvoller Kern.

get_fld_val() ist der richtige Report-State-Zugriff

Diese Methode verbindet Request, Default, gespeicherten State und Validierung. Das ist besser als Werte manuell nach Modulvariablen zu spiegeln.

6. Risiken und Inkonsistenzen

Phasen sind funktional vorhanden, aber nicht benannt

Neue Entwickler sehen viele Methoden, aber nicht sofort die Lifecycle-Struktur. Das erhoeht Fehlentscheidungen.

Alte Kurz-APIs existieren parallel

mod(), rem() und direkte Request-Zugriffe bleiben technisch nutzbar. Neuer Modulcode sollte sprechendere Methoden verwenden.

Zu fruehe Basisklasse waere riskant

Eine harte dbxComponent-Basisklasse vor Abschluss der Analyse koennte bestehenden Code brechen und neue Kopplung erzeugen.

7. Empfehlung

  1. Keine grobe Umstrukturierung von dbxForm oder dbxReport.
  2. Lifecycle-Begriffe zuerst in Doku und PHPDoc festigen.
  3. Neue Methoden nur additiv einfuehren.
  4. Factory-Methoden in dbx() zuerst fuer form() und report() planen.
  5. dbxComponent erst nach Pilotentscheidung als Basisklasse, Trait oder Konvention definieren.
  6. Report-Module schrittweise auf $oReport->get_fld_val(...) ausrichten.

8. Naechste Entscheidungsfragen

  1. Sollen neue Komponenten-Setter kurz heissen (dd(), fd(), tpl()) oder explizit (set_dd(), set_fd(), set_tpl())?
  2. Soll dbx()->form('id') direkt eine initialisierte Form liefern oder nur ein leeres Objekt?
  3. Soll dbx()->report('id') automatisch init() aufrufen?
  4. Welche alten APIs werden offiziell Legacy, aber bleiben intern erlaubt?
  5. Wird dbxComponent zuerst Doku-Konvention, Trait oder echte Klasse?

Stand: 2026-04-29. Analyse ohne Kerncode-Aenderung.