dbxapp Knowledge dbxTPL
Search Reference

dbxTPL

On this page
  1. Classification in the Golden Path
  2. Storage locations
  3. Loading templates
  4. Replacing markers
  5. Using objects
  6. Template distribution with dbx split
  7. Module inclusion
  8. DesignPage, Page and Content Templates
  9. Position
  10. dbx edit=1 and dbx edit=2
  11. Rules
  12. Related Chapters

dbxTPL is the template layer of dbxapp. It separates output from technical logic. PHP prepares data, templates determine structure, positioning and integration.

Classification in the Golden Path

The continuous module example is under Mandatory module manual. This chapter only deepens the template abilities.

Service/View-Model -> kontrollierte Werte -> dbxTPL -> HTML
dbxForm/dbxReport -> Komponentenobjekte -> dbxTPL -> HTML

dbxTPL does not load any technical data and does not mutate any records. Values from the dbx pipelines are used without local escape help functions. Additional escaping is only necessary if an actual raw external input outside the existing field, report or component pipeline is to be output as literal HTML text.

Storage locations

Module templates are here:

dbx/modules/{modul}/tpl/htm/{template}.htm
dbx/modules/{modul}/tpl/css/{modul}.css
dbx/modules/{modul}/tpl/js/{modul}.js

Templates can be language-dependent. If the active language e.g. De dbxTPL first attempts the language file and then falls back to the neutral file:

dbx/modules/{modul}/tpl/htm/{template}_de.htm
dbx/modules/{modul}/tpl/htm/{template}.htm

Labels, fixed headings and small help texts in the template can thus be maintained language-specifically without branching out the module code.

System templates are usually in the module dbx:

dbx/modules/dbx/tpl/htm/

Loading templates

$tpl = dbx()->get_system_obj('dbxTPL');
$html = $tpl->get_tpl('dbxContact|ticket-row', array(
'id' => 17,
'subject' => 'Rückfrage',
));

dbxContact|ticket-row means:

dbx/modules/dbxContact/tpl/htm/ticket-row.htm

Replacing markers

Template:

<article class="ticket-row">
<strong>{subject}</strong>
<span>#{id}</span>
</article>

PHP:

return $tpl->get_tpl('dbxContact|ticket-row', array(
'subject' => $row['subject'],
'id' => (int) $row['id'],
));

Result:

<article class="ticket-row">
<strong>Rückfrage</strong>
<span>#17</span>
</article>

Using objects

dbxForm and dbxReport can use objects in templates:

<div class="dbx-panel">
{obj:bar}
<div class="dbx-panel-body">
{obj:report}
</div>
</div>

PHP:

$form = new \dbxForm();
$form->init('ticket-panel', 'ticket-panel');
$form->add_obj('bar', 'dbx|component-bar', $barData);
$form->add_obj('report', 'obj-value', $this->ticket_report());
return $form->run();

Template distribution with dbx split

Some dbxapp components not only read a template as a whole, but divide it into areas. dbxReport For this purpose, use the marker:

<hr class="dbx_split">

A typical report template dbxAdmin|report-sysmsg:

[tpl=dbx|report-shell-head]
[dbx:pagination]
<div class="table-responsive">
<table class="table table-striped table-bordered table-light table-hover align-middle">
<thead>
<tr class="{tr-class}">[rpt:row]</tr>
</thead>
<tbody>
<hr class="dbx_split">
<tr class="{tr-class}">[rpt:row]</tr>
<hr class="dbx_split">
</tbody>
</table>
</div>
[tpl=dbx|report-shell-foot]

The ranges are:

  • Before the first dbx split: headers, e.g. Table headers.
  • Between the first and second dbx split: Body/Row-Template, is repeated per record.
  • After the second dbx split: Footer or downstream report structure.

For templates with more split markers, dbxReport can also distinguish header/Footer for subsequent pages. Importantly, The division belongs in the template. The report evaluates them.

Module inclusion

Templates can integrate modules:

[modul=dbxAdmin]dbx_run1=sysmsg&dbx_run2=list_sysmsg[/modul]

The dbxInterpreter executes this module call at the page output.

DesignPage, Page and Content Templates

A typical structure:

DesignPage
-> Page-Template
-> Content-Template
-> Modul-Inclusions
-> Modul-Templates

DesignPage defines the external frame: Navigation, Main Area, Footer, CSS/JS-Positionen.

Page templates define page types: Standard page, landing page, admin page, dashboard.

Content templates define specific content blocks: Hero, Body, Gallery, Footer.

Module templates define subject areas: Report, Form, Toolbar, Panel.

CMS templates can divide content into areas and columns via simple markers:

<section class="cms-header header">{cms:header}</section>
<section class="cols cols-{cms:cols}">
<div class="col col-1">{cms:col1}</div>
<div class="col col-2">{cms:col2}</div>
<div class="col col-3">{cms:col3}</div>
</section>
<footer class="footer">{cms:footer}</footer>

The CMS renderer distributes the editorial content on these slots. As a result, a CMS page without its own PHP code can be output in one column, two column, three column, with header, hero, gallery and footer.

Position

Positioning belongs in templates and CSS, not in controller logic.

Good:

<div class="dbx-admin-dashboard-slot dbx-admin-dashboard-slot-sessions">
[modul=dbxAdmin]dbx_run1=session&dbx_run2=list_session[/modul]
</div>

Not good:

return '<div style="float:left;width:50%">' . $this->session_report() . '</div>';

dbx edit=1 and dbx edit=2

dbx edit=1 and dbx edit=2 Mark editable areas in the rendered page. The website is still normally displayed. The interpreter remains active.

Important:

  • The page template must contain: [modulus=... executed.
  • In the template editor itself, raw text is displayed.
  • Markers such as {Title: remain visible in the template editor.
  • The editor may not store the rendered output.

Rules

  • No long HTML strings in PHP.
  • Templates describe structure.
  • PHP provides data, status and actions.
  • No blanket escape wrappers around normal DD, form or report values.
  • Everything that is reusable gets its own template.
  • Dashboard templates should only contain division and domain areas per [modulus=... incorporate.

Related Chapters