Schnellstart: Ihre erste CRUD-Seite
Ein funktionierendes Hinzufügen/Bearbeiten/Löschen-Grid in drei Zeilen PHP - kein HTML, kein Layout, keine Verdrahtung.
Die ganze Seite
Erstellen Sie pages/payments.php mit genau diesem Inhalt:
$xcrud = Xcrud::get_instance();
$xcrud->table('payments');
$xcrud->route('payments');
Rufen Sie /payments auf, und das ist bereits ein vollständiger CRUD-Bildschirm - Liste, Suche, Sortierung, Hinzufügen, Bearbeiten, Löschen. Die Datei ruft nie selbst render() auf und gibt auch sonst nichts aus: core/router.php bemerkt, dass die Seite keine eigene Ausgabe erzeugt hat, ruft daher render() für Sie auf und umschließt das Ergebnis mit der normalen Seitenhülle der Site (oder der Dashboard-Hülle, falls Login/Rollen aktiviert sind). Dieses automatische Umschließen passiert nur, wenn die Seite "still" bleibt - sobald eine Seite eigenes HTML ausgibt (etwa eine Seite ohne Widget oder eine mit mehreren Widgets), lässt der Router sie unangetastet. Siehe Mehrere Widgets auf einer Seite für diesen Fall.
get_instance()
Xcrud::get_instance() liefert eine neue, unabhängige Widget-Instanz - trotz des Namens ist es kein echtes Singleton. Jeder Aufruf liefert ein brandneues Objekt mit eigener Tabelle, eigenen Spalten, Feldern und Hooks. Mehrere Widgets können problemlos auf einer Seite koexistieren, jedes aus seinem eigenen get_instance()-Aufruf:
$customers = Xcrud::get_instance();
$customers->table('customers');
$customers->route('customers');
$orders = Xcrud::get_instance();
$orders->table('orders');
$orders->route('orders');
table()
$xcrud->table(string $name) bindet das Widget an eine echte Datenbanktabelle. Der Name wird gegen das Schema Ihrer Datenbank geprüft (die Tabelle muss existieren und einen einspaltigen Primärschlüssel haben) sowie gegen XcrudConfig::$blacklistedTables - eine Sicherheits-Blacklist in src/Config.php. Standardmäßig ist jede Tabelle erreichbar; eine Tabelle wird erst unbenutzbar, sobald sie explizit in diese Liste aufgenommen wird. Der Aufruf von table() auf einer gesperrten oder nicht existierenden Tabelle wirft sofort eine Exception. Das vollständige Modell, einschließlich spaltenbasierter Sperrung, finden Sie unter Sicherheit: Tabellen & Spalten sperren.
| Parameter | Typ | Standard | Beschreibung |
|---|---|---|---|
$name | string | - | Echter Tabellenname in der verbundenen Datenbank. Darf nicht in $blacklistedTables stehen, muss existieren und einen einspaltigen Primärschlüssel besitzen. |
route()
$xcrud->route(string $name) legt den URL-Slug fest, auf den das Widget reagiert - so ordnet core/router.php eine Anfrage wie /payments genau dieser Widget-Instanz zu, und es ist auch der Schlüssel, mit dem ajax_crud.php bei jeder AJAX-Anfrage die Konfiguration derselben Seite (Spalten, Hooks, Buttons) erneut auflöst. Allein der Aufruf von table() setzt bereits eine Standardroute, die dem Tabellennamen entspricht - route() ist also nur nötig, wenn die URL vom Tabellennamen abweichen soll.
render() vs. page()
Ist es konfiguriert, erzeugt ein Widget sein Markup auf eine von zwei Arten:
| Methode | Liefert | Wann verwenden |
|---|---|---|
render() | Nur das eigene HTML des Widgets (Mount-Punkt + Assets + Init-Skript) | Einbettung in eine Seite, die Sie bereits selbst schreiben - neben anderen Widgets, eigenem HTML oder einem entkoppelten Frontend |
page() | Ein vollständiges eigenständiges HTML-Dokument (Doctype, Head, Titel, Body), das render() umschließt | Eine Route, die aus nichts als diesem einen Grid besteht - worauf der Router bei einer stillen Seite wie der obigen zurückfällt |
$xcrud = Xcrud::get_instance();
$xcrud->table('payments');
$xcrud->route('payments');
echo $xcrud->page(); // vollständiges <html>...</html>-Dokument
Bei einer Seite mit nur einem Widget müssen Sie selten eine der beiden Methoden explizit aufrufen - lässt man die Seite still (wie im obigen Drei-Zeilen-Beispiel), ruft der Router render() für Sie auf und kümmert sich um die umgebende Hülle.