Component Integration Standard

On this page

1. Objective
2. Common connections
3. Standard lifecycle
4. Minimum module code as target image
5. Compatibility rules
6. First technical implementation steps

dbxapp LEGO RAD

This specification describes the common connection language for DBX components. It is the basis for decision-making for form, report, grid, dialogue, window, workflow and process.

Compatible gradual DD / FD State Templates Hooks Client Libs

Principle:
This standard is first of all a target contract. It does not yet enforce an incompatible base class and does not replace existing atomic logic without consultation.

1. Objective

DBX components can be configured, started, rendered, stored and extended in the same way. Modules are intended to express domain intent and not to repeat technical infrastructure.

dbx()->form('kunde')
dbx()->report('kunden')
dbx()->grid('kunden')
dbx()->dialog('delete')
dbx()->window('kunde')
dbx()->workflow('import')
dbx()->process('reindex')

2. Common connections

Connection	Meaning	Examples
id	Unique component ID within the current context.	Sessions, customer-edit, import-run
Context	Module, instance, request and user context.	modul, run1, run2, instance id, uid
dd	Data/table/field knowledge.	dbxSession, dbx\|dbxTrace, modul\|customer
fd	Form/UI field definition.	dbxAdmin\|rpt-sessions-selection
tpl	Display template for HTML output.	modul\|report-sessions, dbx\|pagination
Data	working data of the component.	record, rows, values, options
State	Persistent component state.	filter, sort, page, selected, draft id
Request	Current input from GET/POST/AJAX.	submit, action, field values
Actions	commands of the component.	save, delete, select, export, show
Hooks	Extension points without kernel hack.	before validate, after save, before render
rendered	Release on templates and replaces.	run(), render(), get html()
Client	Client lib and CSS activation.	data-dbx="lib=form\|...", report.js, c-report.css
traceability	Traceability of actions, files and status.	dbxTrace, editor files, debug context

3. Standard lifecycle

The lifecycle is the common thinking structure. Existing classes do not have to possess it immediately exactly as methods, but should be gradually aligned with it.

construct
init_context
load_definition
load_state
read_request
validate
process
render
save_state

construct

Create object, set hard defaults, no expensive side effects.

init context

Determine the module, instance, user, request destination and state key.

load definition

Load DD, FD, templates, fields, actions and options.

load state

Remember/Session/Process-State. F5 must not destroy condition.

read request

GET/POST/AJAX and distinguish it from the stored state.

validate

Check values, types, rights and rules. DD/FD should allow the test.

Process

Perform actions: Save, Delete, Select, Export, Custom Actions

rendered

Create HTML, log in client Libs/CSS, register editor files.

save state

Store new state. Only a defined state is persisted.

4. Minimum module code as target image

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();

Method names such as dd(), fd() and tpl() They are a proposal, not a decision. Vote before implementation.

5. Compatibility rules

Existing conduct of dbxForm and dbxReport will remain until a new path is agreed.
New APIs are first introduced additively.
Short old methods may remain internal, but new module development uses speaking names.
State keys must be module and instance secure.
FD/DD/Templates/Klassen must still be registered for Editor and Trace.
Client Libs load their CSS component centered.
Mobile/Tablet is web-first. Native app connection remains adapter layer.

6. First technical implementation steps

Existing methods in dbxForm and dbxReport Assign the lifecycle phases.
Define common terms for context, definition, state, request and render.
Speakers dbx()-Factory methods as an additive layer.
A small, non-invasive dbxComponentCreate specification.
Only then will it be decided whether: dbxComponent Base class, trait or just convention.

Document status: 2026-04-29. This file is a technical specification and not yet an implementation decision. Incompatible changes are discussed before implementation.