dbxapp Knowledge Form & Report Lifecycle
Search Reference

Form & Report Lifecycle

On this page
  1. dbxForm / dbxReport Lifecycle Analysis
    1. 1. Short assessment
    2. 2. Target lifecycle
    3. 3. dbxForm: Current mapping
    4. 4. dbxReport: Current mapping
    5. 5. Starches
    6. 6. Risks and inconsistencies
    7. 7. Recommendation
    8. 8. Next decision questions
dbxapp LEGO RAD

dbxForm / dbxReport Lifecycle Analysis

Analysis of the current form and report classes against the planned component plug-in standard. The goal is classification, not conversion.

dbxForm dbxReport Lifecycle State Request Render
Labour rules
This analysis justifies later steps. It does not change atomic logic.

1. Short assessment

dbxForm and dbxReport They are already real conditionable components. The core is sustainable. The next quality level is not in a rewrite, but in a clear assignment: Context, definition, state, request, validation, process and render must be maintained as recognizable phases.

Main finding: The functionality is already available, but not yet consistently visible as a common plug-in standard.

2. Target lifecycle

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

This lifecycle is a structure of thought and order. It does not have to be implemented immediately 1:1 as a new base class.

3. dbxForm: Current mapping

Lifecycle phase Current methods / fields Assessment
construct construct(), clear() Basic initialization exists. The constructor and reset logic are functional, but not named as a lifecycle phase.
init context forward init(), init(), fid, dbx module, dbx action, dbx page, dbx design, dbx lng Strong. Context becomes central in forward init() set. This is already a good point of contact.
load definition add fld(), add flds(), read dd fields direct(), get dd fields source(), get dd(), get dd fld() Present, but widely distributed. DD/FD-Auflösung works, should become more conceptually visible in the long term as a definition phase.
load state load sysdata(), load workflow state(), get state value(), get fld val() Strong. Form state is loaded from Session/Remember. get fld val() Connects state and request meaningfully.
read request evaluate request(), resolve fld val(), get post data(), get post(), get post data(), get post(), submit() Present. evaluation request() is the right core. In new code, raw requests should increasingly be replaced by component methods.
validate check fld data(), check flds data(), errors(), warnings(), oValidator Strong. Validation is central and runs only once per request cycle.
Process set post(), save post(), view sync(), set state value(), workflow-state methods Standard process paths are available. Logic remains explicitly possible in the module. This is DBX compliant.
rendered forward run(), run(), get tpl(), merge tpl data(), merge fld data(), merge obj(), get form msg(), add editor markers() Strong, but extensive. Render is functional, but contains many subtasks. Later smoothing possible.
save state store sysdata(), store workflow state(), set form saved(), bump form version() Present. Important for F5 / reload stability. Must be consistently used in reports.

4. dbxReport: Current mapping

Lifecycle phase Current methods / fields Assessment
construct extends dbxForm, clear() Uses form base. This is true because Report is a specialized form/list component.
init context init(), forward init(), dbx module, fid, next i Present. init() sets report-specific page data and calls form-init.
load definition create selection fields(), add flds(), fd, dd, rflds, set form selects() Report selection about FD is correct. The method is clearly part of the definition phase.
load state load sysdata(), get fld val(), report state flds, get multi selects() Conceptually correct. Report values should be over get fld val() come from form-State/Request, not via direct module variable mirroring.
read request get fld val(), apply tabulator request(), check is multiselect(), parse multi select ids() Present. Report-specific request actions are clear, but not yet uniformly named as actions.
validate dbxForm::check_flds_data(), validator rules in FD/DD Uses form validation. All right. Report-internal parameters such as sorting/Where must be consistently validated.
Process set multi select(), del multi select(), del selected(), add rwhere search(), add rwhere select() Many reporting processes are available. They should later become visible as standardized actions.
rendered run(), split tpl(), get report header(), get report body(), get report footer(), pagination(), run body() Strong. Report rendering is feature-rich but has grown. No rewrite candidacy, but smoothing over clear phases.
save state store sysdata(), Multi-Select Remember, Report-State about dbxForm Present. Report-State must remain consistent in the component in order for F5 to be stable.

5. Starches

Form and report are already components

They have context, state, request evaluation, validation, rendering and persistence points.

dbxReport extends dbxForm is strategically correct

Reports need form state for filtering, pagination, sorting and selection. Heredity is not a mistake, but a meaningful core.

get fld val() is the correct report-state access

This method combines request, default, stored state and validation. This is better than mirroring values manually according to module variables.

6. Risks and inconsistencies

Phases are functional, but not named

New developers see many methods, but not immediately the lifecycle structure. This increases wrong decisions.

Old short APIs exist in parallel

mod(), rem() Direct requests remain technically usable. New module code should use more speaking methods.

Too early base class would be risky

A hard dbxComponentBase class before completion of analysis could break existing code and create new coupling.

7. Recommendation

  1. No rough restructuring of dbxForm or dbxReport.
  2. Consolidate lifecycle terms first in Doku and PHPDoc.
  3. New methods only introduce additive.
  4. Factory methods in dbx() first for Form(s) and Report(s) planning.
  5. dbxComponent define only after pilot decision as base class, trait or convention.
  6. Report modules gradually $oReport->get fld val(...) alignment.

8. Next decision questions

  1. Let new component setters be short ()dd(), fd(), tpl()) or explicitly (set dd(), set fd(), set tpl())?
  2. Target dbx()->form('id') directly deliver an initialized form or just an empty object?
  3. Target dbx()->report('id') Automatic init() Calling?
  4. Which old APIs are officially legacy but remain allowed internally?
  5. Will be dbxComponent First documentary convention, trait or real class?

Document status: 2026-04-29. Analysis without core code change.