Modul in 30 Minuten

1. Ziel und Dateibaum

dbx/modules/myInvoices/
├── myInvoices.class.php
├── include/             Fachservice und Fixtures
├── dd/                  vollständige TABLE/FIELDS/INDEXES-DDs
├── fd/                  Formular- und Reportfelder
├── tpl/htm/ und help/   fachliche Templates und Hilfe
├── js/ und tpl/css/     ausschließlich modulspezifische Assets
├── tests/               Vertrags- und Integrationstests
└── dbx.package.json

Klassen verwenden PascalCase; Methoden, Properties und lokale Variablen snake_case. Neue eigenständige Klassen beginnen mit declare(strict_types=1);.

2. Router klein halten

$run = (string)dbx()->get_modul_var('dbx_run1', 'report', 'parameter|max=32');
$service = dbx()->get_include_obj('myInvoicesService', 'myInvoices');

switch ($run) {
    case 'form':
    case 'edit':
        return $service->form();
    case 'delete':
        return $service->delete();
    default:
        return $service->report();
}

Dies ist der gekürzte reale Einstieg aus myInvoices.class.php. Der Router wählt nur eine Fachmethode. Er enthält weder Datenzugriff noch HTML. Gruppenrechte werden ausschließlich mit dbx()->has_group() geprüft.

3. Daten ausschließlich über dbxDB und DD

$db = dbx()->get_system_obj('dbxDB');
$record = $db->select1('myInvoices|invoice', array('id' => $id), '*', 0);
$db->update('myInvoices|invoice', $data, array('id' => $id));

DDs bleiben vollständig und direkt lesbar. Eine neue oder geänderte DD wird nach dem Schreiben mit dbxDD DD→DB synchronisiert. Erst der erfolgreiche Sync schließt die Strukturänderung ab. Auditfelder werden von dbxDB verwaltet.

4. Formular und Report über öffentliche APIs

• Formular: dbxForm mit FD verwenden. Die Form-ID ist UI-State-Identität, nicht Templatename. Das Modul-Haupttemplate bindet {form:bar}, {form:message} und {form:footer} ein.
• Report: normale Tabellenlisten verwenden das dbxReport-Standardtemplate. Datenquelle, Action, Record, RID, Modus und Aktionen werden über benannte Methoden gesetzt.
• Aktionen: Standardaktionen mit set_table_actions() konfigurieren.
• Zählwerte: bei Filtern selektierte Trefferzahl und ungefilterte Gesamtzahl getrennt übergeben. Gesamt darf sich durch einen Suchfilter nicht ändern.
• Mobil: Tabellen bleiben scrollbar; eine fachlich sinnvolle Kartenansicht nutzt Feldlabels und dbx-report-mobile-cards.

5. Templates, Assets und Zustand

• Vor einer Neuanlage vorhandene Templates im Zielmodul und in dbx prüfen.
• Kein eingebettetes <style> oder <script>. CSS liegt unter tpl/css/, JavaScript unter js/ und wird einmal über den Asset-/Featuremechanismus registriert.
• Kein direkter Zugriff auf $_SESSION. UI-Zustand verwendet den zuständigen State-Service oder die Session-/Remember-API.
• Ajax, Confirm und Fenster verwenden die vorhandenen dbxapp-Komponenten; der normale Request bleibt Fallback.

6. dbxKi-Antwort für eine Moduländerung

Ein dbxKi-Modulauftrag liefert reference/25_Verbindliches_Modulhandbuch.md, reference/KI-TEMPLATES.md und reference/myInvoices/. Die KI kopiert auftrag.contract.json unverändert und füllt nur die deklarierten Outputs:

{
  "outputs": {
    "module.changes": [
      {"action":"module.file.write","params":{"path":"include/myExampleService.class.php","content":"<?php ..."}},
      {"action":"module.dd.sync","params":{"dd":"example"}}
    ],
    "change_log": {
      "summary":"Beispielmodul um eine filterbare Liste ergänzt",
      "details":"Der neue Report verwendet DD, dbxDB und den dbxReport-Standard.",
      "resources":["dbx/modules/myExample/include/myExampleService.class.php","dbx/modules/myExample/dd/example.dd.php"]
    }
  }
}

dbxKi erzeugt den Plan selbst, zeigt eine Vorschau und schreibt das Change Log erst nach erfolgreicher atomarer Ausführung.

7. Abnahme

1. PHP- und JavaScript-Syntax prüfen.
2. DD→DB-Sync und idempotente Fixtures über die dbxapp-APIs testen.
3. Normalen und Ajax-Ablauf, Rechte, Action-Token, Fehlerfälle und Mehrfachinstanzen testen.
4. Desktop und Mobil, Filter, Pagination, Gesamt-/Trefferzahl und Tastaturfokus prüfen.
5. Fokussierte Modul-Vertrags-/Integrationstests und vollständigen SelfTest ausführen.
6. Nach Erfolg genau einen verständlichen Change-Log-Eintrag für den logischen Block schreiben.