Modulhandbuch · Kapitel 6 von 8

Inclusion, Installation und Aufruf

Zweistufige Inclusion, DD-Sync, Fixtures, Installation und direkte Modulaufrufe.

Kapitel 6 des verbindlichen Modulhandbuchs für das Referenzmodul myInvoices.

12. Was die zweistufige Inclusion technisch bewirkt

Für jede sichtbare Rechnung erzeugt invoice_report_next_record() genau einen Marker:

[modul=myInvoices]dbx_run1=positions&invoice_id=17[/modul]

Der Interpreter:

prüft den Modulzugriff;
setzt dbx_run1 und invoice_id als geschützte Modulvariablen;
ruft erneut den kleinen Router auf;
lässt positions() Kopf und Positionen über dbxDB und DD prüfen;
ersetzt den Marker durch den fertigen Positionsreport.

Das Muster eignet sich für eine begrenzte äußere Seitengröße. Bei 20 Rechnungen entstehen 20 gezielte Positionsabfragen mit verschiedenen invoice_id-Werten; das sind keine identischen Resultsets, die ein einfacher Ergebniscache zusammenlegen könnte. dbxDB kann weiterhin DD-Metadaten, Verbindungen und dafür vorgesehene DD-Caches zentral nutzen.

Bei sehr großen Seiten SOLL die Unterliste erst beim Öffnen eingebettet oder in einem fachlichen Batch über dbxDB vorgeladen werden. Direkte PDO-Abfragen oder ein zweiter Browser-API-Weg sind keine Optimierung.

13. DD-Sync, Fixtures und Installation

Beide DDs werden über den vorhandenen Admin-DD-Sync oder einen explizit geschützten Installationspfad synchronisiert:

$dd = dbx()->get_system_obj('dbxDD');
 
foreach (array('invoice', 'invoiceItem') as $name) {
    $dd->sync_dd_to_db('myInvoices', $name, 'reset');
 
    do {
        $state = $dd->sync_dd_to_db(
            'myInvoices',
            $name,
            'apply'
        );
    } while (($state['status'] ?? '') === 'running');
 
    if (($state['status'] ?? '') !== 'finished') {
        throw new \RuntimeException(
            (string)($state['message'] ?? 'DD-Sync fehlgeschlagen')
        );
    }
}

Schemaänderungen laufen nicht bei jedem normalen Request. Der ausführbare Service zeigt unter dbx_run1=install zunächst nur ein dbxForm. DD-Sync und Fixtures starten erst nach dessen gültigem POST. Deshalb braucht die Installationsroute keinen zusätzlichen dbx_token: dbxForm schützt bereits den Submit, und die Route verlangt zusätzlich Adminrecht.

include/myInvoicesFixtures.class.php berechnet die Demo-Snapshots aus den zugehörigen Positionen und schreibt sämtliche Fachdaten über dbxDB. Sie übergibt keine Auditfelder. Alle Demo-Rechnungen besitzen eine eindeutige DBX-DEMO-*-Nummer; ein wiederholter Lauf überspringt vorhandene Fixtures und überschreibt keine Benutzerdaten.

Für Automation steht derselbe Installer ohne zweiten Datenpfad per CLI bereit:

php dbx/modules/myInvoices/tools/install_demo.php

php dbx/modules/myInvoices/tools/install_demo.php --schema-only

14. Direkter Aufruf und Inclusion

Direkt:

?dbx_modul=myInvoices&dbx_run1=report
?dbx_modul=myInvoices&dbx_run1=form&rid=new
?dbx_modul=myInvoices&dbx_run1=form&rid=17
?dbx_modul=myInvoices&dbx_run1=positions&invoice_id=17
?dbx_modul=myInvoices&dbx_run1=install

Eingebettet:

[modul=myInvoices]dbx_run1=report[/modul]

Der Positionsaufruf wird normalerweise vom Rechnungs-Record-Callback erzeugt, kann für eine reine Detailansicht aber auch bewusst eingesetzt werden:

[modul=myInvoices]dbx_run1=positions&invoice_id=17[/modul]

Templates verwenden {i} für eindeutige Instanzen. Modulparameter werden mit get_modul_var() und passenden Regeln gelesen.

dbxapp Modulhandbuch – Inclusion, Installation und Aufruf

12. Was die zweistufige Inclusion technisch bewirkt

13. DD-Sync, Fixtures und Installation

14. Direkter Aufruf und Inclusion