dbxapp Wissen Form & Report Lifecycle
Suche Referenz

Form & Report Lifecycle

Auf dieser Seite
  1. dbxForm / dbxReport Lifecycle-Analyse
    1. 1. Kurzbewertung
    2. 2. Ziel-Lifecycle
    3. 3. dbxForm: aktuelle Zuordnung
    4. 4. dbxReport: aktuelle Zuordnung
    5. 5. Staerken
    6. 6. Risiken und Inkonsistenzen
    7. 7. Empfehlung
    8. 8. Nächste Entscheidungsfragen
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 begründet spätere Schritte. Sie ändert keine Kernlogik.

1. Kurzbewertung

dbxForm und dbxReport sind bereits echte zustandsfähige Komponenten. Der Kern ist tragfähig. Die nächste Qualitätsstufe liegt nicht in einem Rewrite, sondern in klarer Zuordnung: Kontext, Definition, State, Request, Validierung, Prozess und Render müssen als erkennbare Phasen gepflegt werden.

Hauptbefund: Die Funktionalität 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-Auflösung 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 ausgeführt.
process set_post(), save_post(), view_sync(), set_state_value(), Workflow-State-Methoden Standard-Prozesspfade sind vorhanden. Fachlogik bleibt bewusst im Modul möglich. 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, enthält aber viele Teilaufgaben. Spätere Glattung möglich.
save_state store_sysdata(), store_workflow_state(), set_form_saved(), bump_form_version() Vorhanden. Wichtig für F5-/Reload-Stabilität. 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 über FD ist korrekt. Die Methode gehört klar zur Definitionsphase.
load_state load_sysdata(), get_fld_val(), _report_state_flds, get_multi_selects() Konzeptionell richtig. Reportwerte sollen über get_fld_val() aus Form-State/Request kommen, nicht über 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 müssen 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 später 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 über klare Phasen.
save_state store_sysdata(), Multi-Select Remember, Report-State über 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 für 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 erhöht Fehlentscheidungen.

Alte Kurz-APIs existieren parallel

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

Zu frühe Basisklasse waere riskant

Eine harte dbxComponent-Basisklasse vor Abschluss der Analyse könnte 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 einführen.
  4. Factory-Methoden in dbx() zuerst für 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. Nächste 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?

Dokumentstand: 2026-04-29. Analyse ohne Kerncode-Änderung.