dbxInterpreter

dbxInterpreter is the bridge between content, templates and modules. His principle is deliberately small: Text contains simple markers, and the output pipeline replaces these markers with the matching result.

The Three Markers

The dbxapp output pipeline essentially interprets only three types of markers:

This is deliberately little. There is no large template language, no loops in the template and no eval(). The logic remains in the PHP module, the structure in the template, and the connection is created via these markers.

Why this is fast

The interpreter is fast because he does not evaluate a complex language.

• Only known markers are sought.
• [inc ] decides only if an existing block remains.
• [tpl loads a template recursively over dbxTPL.
• [Module sets module parameters and calls the module dbxApi on.
• template contents are cached; Dynamic values are then replaced.
• There are no PHP expressions in the template.

This leaves the output deterministic. A template is text, not a program. Modules can still be arbitrarily complex because they run as normal dbxapp modules.

[inc ]: Simple conditions

[inc ] is intended for small display decisions.

With allowed functions:

Rule: [inc ] It is not a programming language. Complex logic belongs in module or include classes.

[tpl: Template building blocks

[tpl incorporates reusable template parts.

This makes templates small and combinable. A report template can thereby e.g. use the standard report header, filter bar and footer without copying this structure in each module.

[Module: Modular islands

[Module starts a module and replaces the marker with its output.

Execution:

1. dbxInterpreter finds the marker.
2. The module name is read.
3. The parameters in the marker are set as module variables.
4. These module variables are protected so that request values do not accidentally overwrite them.
5. dbxApi loads the module object.
6. The module shall: run() executed.
7. The module output replaces the marker.

Example of content:

Example of an admin dashboard template:

The parent template thus only defines the position. The integrated area remains its own module with its own report, search, sorting, pagination, actions and its own AJAX target.

Why so much is possible

These three markers create nestable building blocks:

• A CMS page can contain several modules.
• A dashboard can only consist of layout slots and module calls.
• A report can use standard templates for head, filter, body and footer.
• A form can be within a module and in turn use standard form templates.
• A module can run multiple times on the same page if targets and module variables are neatly separated.
• Content remains editorially editable, although domain functions are embedded.

Example:

This is not a big framework in the template. There are only three simple mechanisms that work neatly with the kernel classes.

Template editor and dbx edit

With the normal website output, the interpreter must run, even if dbx edit is active. Otherwise, the page would only display raw markers.

In the template editor, the opposite applies: There, the interpreter may not execute the markers. The user should the file from /tpl See and edit exactly as it is stored.

Important:

• Website with dbx edit > 0: The interpreter is running.
• Template editor: Markers remain raw text.
• [modulus=... in the editor must not generate a module output.
• Editor markers such as DBX-TPL START do not belong in the edited raw text.

Performance and safety concept

The interpreter remains small because it only connects:

• It does not produce any technical logic.
• It does not store any data.
• He does not render reports himself.
• He does not build windows, Ajax logic or Confirm dialogues.

These tasks belong to the respective standard classes and JavaScript-Libs. The interpreter only ensures that content and templates can solve the right building blocks.

Rules for modules

• Module calls in content always as [modulus=...]...[/Module writing.
• Write parameters in the marker such as querystring: dbx run1=list&id=4.
• Do not build your own parsers for modular markers.
• Repeatable areas with unique targets such as dbx target {i} building.
• Keep domain logic in the module, do not hide in the template.
• Keep templates small and use standard building blocks [tpl=... use.
• Conditions only for simple display decisions with [inc ] use.

Relationship with dbxTPL

dbxTPL and dbxInterpreter are separate but work together:

1. dbxTPL loads templates and replaces {Marker.
2. dbxTPL Processed [inc ].
3. dbxTPL Processed [tpl.
4. The web output then allows for module markers dbxInterpreter dissolve.

This separation is a core advantage of dbxapp: Template structure and module execution remain separate, but can be combined in content.