Routing: Module, Views und Parameter #

Diese Seite richtet sich an Entwickler, die eine Routentabelle gewohnt sind (routes.yaml, routes/web.php, urls.py, config/routes.rb). Exponential hat keine Routentabelle. Eine Adresse wird als /<module>/<view>/<parameters> gelesen, und die module.php des Moduls legt fest, welche Views es gibt und welche Parameter sie annehmen. Sprechende Adressen sind eine eigene Schicht, die URL-Aliase, die vor diesem Schritt in eine Moduladresse übersetzt werden (Sprechende URLs).

Inhalt #

1. Die Konvention
2. Ein Modul registrieren
3. Parameter
4. HTTP-Methoden und Aktionen
5. URLs erzeugen
6. Was Nutzer eines Routers vermissen werden

Die Konvention #

Bei URI-basierter Siteaccess-Erkennung steht der Name des Siteaccess an erster Stelle (/admin/content/view/full/2) und wird entfernt, bevor das Modul gesucht wird (Siteaccesses).

Ein Modul registrieren #

Ein Modul ist ein Verzeichnis mit einer module.php in einem Modul-Repository. Die Repositories des Kernels sind settings/module.ini [ModuleSettings] ModuleRepositories[] (kernel, kernel/private/modules); eine Erweiterung ergänzt ihr eigenes und führt das Modul auf, wodurch es erreichbar wird:

# extension/expdemo/settings/module.ini.append.php
<?php /* #?ini charset="utf-8"?
[ModuleSettings]
ExtensionRepositories[]=expdemo
ModuleList[]=expdemo
*/ ?>

<?php
// extension/expdemo/modules/expdemo/module.php
$Module = array( 'name' => 'Demo' );

$ViewList = array();
$ViewList['item'] = array(
    'script' => 'item.php',
    'functions' => array( 'read' ),
    'params' => array( 'ItemID' ),
    'unordered_params' => array( 'offset' => 'Offset' ) );

$FunctionList = array();
$FunctionList['read'] = array();

Alle Schlüssel der $ViewList-Einträge sind in der module.php-Referenz aufgeführt. Leeren Sie nach dem Hinzufügen eines Moduls den INI-Cache (php bin/php/ezcache.php --clear-tag=ini) und deployen Sie unter Velocity (Server und Deployment).

Parameter #

Parameter kommen als Strings an. Die Deklaration kennt keine Typbeschränkungen oder Anforderungen: Casten und validieren Sie in der View ((int), Allow-Lists) (Validierung).

HTTP-Methoden und Aktionen #

Eine View beantwortet jede Methode; es gibt kein methods: [POST] in der Deklaration. Formulare werden als Aktionen behandelt: Die View legt fest, welcher POST-Button welche Aktion bedeutet, und der Code fragt $Module->isCurrentAction( 'Store' ) ab:

$ViewList['edit'] = array(
    'script' => 'edit.php',
    'functions' => array( 'manage' ),
    'params' => array( 'ItemID' ),
    'single_post_actions' => array( 'StoreButton' => 'Store', 'CancelButton' => 'Cancel' ),
    'post_action_parameters' => array( 'Store' => array( 'Title' => 'ItemTitle' ) ) );

Prüfen Sie die Methode selbst, wo es darauf ankommt (ein JSON-Endpunkt, der nur POST annehmen darf), und lassen Sie ezformtoken jeden POST schützen (Formulare und CSRF).

URLs erzeugen #

Es gibt keine Routennamen: Der Modul/View-Pfad ist der Name. Bündeln Sie die Pfade Ihres Moduls in einer Hilfsklasse, wenn viele Stellen sie erzeugen.

Was Nutzer eines Routers vermissen werden #

• Routennamen und Reverse Routing über den Namen: Erzeugen Sie stattdessen den Modulpfad.
• Anforderungen, Standardwerte und Konverter pro Parameter: Erledigen Sie dies in der View.
• Methodenspezifische Routen: Verwenden Sie Aktionen oder prüfen Sie die Methode in der View.
• Annotations- oder Attribut-Routen: module.php ist die einzige Deklaration.
• Beliebige sprechende Pfade für Ihre Modul-Views: URL-Aliase verweisen auf Inhaltsknoten; für Ihre eigenen Views verwenden Sie globale URL-Aliase oder Platzhalter, um einer Moduladresse eine freundlichere zu geben (Sprechende URLs).

Verwandte Seiten #

• Controller: Modul-Views
• Eigene Module und Views
• Das Modul-und-View-Muster
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.