extbase_realurl

TYPO3-Erweiterung Extbase Realurl

Automatische Realurl-Konfiguration für Extbase Plugins

Was bewirkt es?

Extbase Realurl (ab hier: ER) arbeitet auf eine täuschend einfache Weise:

1. Wenn Realurl die automatische Konfigurationsdatei schreibt, greift ER auf die folgenden Elemente zurück die Generierung des Regelsatzes.
2. ER analysiert dann jedes Extbase Plugin, das auf der Website verwendet wird, indem es Folgendes erkennt der CType und list_type von Plugins, die eine Extbase Basis haben.
3. ER bestimmt das oberste Extbase Plugin auf jeder Seite und ordnet zu, dass seite zu dem verwendeten Extbase Plugin.
4. ER wählt die Regel aus, die für den Standard-Controller erstellt wurde und aktion, wie im Plugin definiert.
5. Realurl ruft eine spezielle ER UserFunction auf, um Argumente zu übersetzen. Dies spezielle UserFunction verarbeitet dann jedes Argument gemäß (by default) die ClassReflection des Controllers und seine Aktion mit der Option option zum Überschreiben bestimmter Verhaltensweisen durch Dokumentkommentaranmerkungen.

Das Ergebnis ist, dass jedes Mal, wenn Realurl die automatische Konfigurationsdatei schreibt was standardmäßig realurl_autoconf.php ist, dann Regeln für alle Instanzen von Extbase Plugins sind im Lieferumfang enthalten.

Die Alternative zu dem oben genannten Ansatz wäre, entweder eine fest programmierte Realurl-Konfiguration für Ihr aktuelles Setup - was nicht möglich wäre um sich an alle Plugin- und Seitenänderungen anzupassen, die von Ihren Editoren vorgenommen wurden - oder um eine benutzerdefinierte Benutzerfunktionen, die aufgerufen werden sollen, wenn Realurl Regeln erstellt - was so aussehen würde sehr ähnlich dem oben genannten Ansatz, würde aber viel Handarbeit erfordern und würde nicht sofort auf ein Extbase-Plugin zutreffen (es sei denn, Sie verwenden die Option die genau gleiche Strategie der Analyse von konfigurierten Plugins, aktuellen Instanzen und Instanzen und ClassReflections der Controller).

ER erledigt das alles automatisch für Sie. Und Sie können es im Detail steuern bei der Programmierung eigener Extbase-Plugins - auf eine Weise, die keine Auswirkungen hat wenn ER nicht installiert ist; aufgrund der Verwendung von Kommentaren zu Dokumenten.

Was bewirkt es auch?

Als ob automatische Regeln für jedes Plugin nicht genug wären, fügt ER auch einen Weg hinzu um eine beliebige Steuerungsaktion von einem Plugin aus einer beliebigen Erweiterung der Website aufzurufen. Die einzige Voraussetzung: Es funktioniert nur für Pakete, die Namensräume verwenden und haben Lieferantennamen. Dies ist notwendig für die Konsistenz. Die Aktionen kehren zurück genau den Inhalt, der von der Steuerung zurückgegeben wird, sonst nichts. Und es unterstützt formate, was es ideal für die AJAX-Nutzung oder für Dienste macht.

Die URL-Syntax für den Aufruf einer bestimmten Aktion lautet:

$base/$vendor/$extensionName/$pluginName/$optionalController/$optionalAction(.$optionalFormat)

Jeder optional markierte Parameter ist genau das: optional. Einfach auslassen ruft die Standard-Controller- und Aktionskombination für dieses Plugin auf; und wenn keine gesetzt sind, werden der Fallback StandardController und indexAction verwendet.

Und um Argumente zu spezifizieren:

.../$action/$argumentOneName/$argumentOneValue/$argumentTwoName/$argumentTwoValue(.$optionalFormat)
// oder die altmodische (Art und Weise, die auch Arrays in der üblichen `argument[subProperty]`Syntax unterstützt
.../$action.$format?$argumentOneName=$argumentOneValue&$argumentTwoName=$argumentTwoValue

Was die Argumente macht:

array(
    $argumentOneName => $argumentOneValue,
    $argumentTwoName => $argumentTwoValue,
    ...
)

Einige Beispiele, die hoffentlich alles nur durch Lesen erklären sollte:

# EXT:fromage receipt im HTML-Format (Template-Dateiname: receipt.html):
GET http://mydomain/FluidTYPO3/Fromage/Form/receipt.html

# EXT:fromage receipt im TXT-Format (Vorlagendateiname: receipt.txt):
GET http://mydomain/FluidTYPO3/Fromage/Form/receipt.txt

# EXT:mycoolext datumsbeschränkte Eintragsliste im JSON-Format (Vorlagendateiname: list.json):
GET http://mydomain/MyVendorName/Mycoolext/Entries/Entry/list/from/2011/to/2013.json

# EXT:myauth Benutzerstatus im JSON-Format (direkt von der Steuerung zurückgegeben):
GET http://mydomain/MyVendorName/Myauth/User/status.json

# EXT:sendstuff upload action, handle input then respond in XML format (template: upload.xml)
POST http://mydomain/MyVendorName/Sendstuff/Upload/upload.xml

# EXT:ajaxsavestuff save action, handle input then respond in JSON format, einige Argumente als GET:
POST http://mydomain/MyVendorName/Ajaxsavestuff/Stuff/save/name/MrAndersson/location/TheMatrix.json

# EXT:showoff svg action, rendert die Kontohistorie als SVG mit Grafik:
GET http://mydomain/MyVendorName/Showoff/Account/history.svg

Kurz gesagt: Sie können alles anrufen, solange es einen Lieferantennamen hat und definiert ist als Plugin (Hinweis: Es muss nicht registriert werden, es muss nur registriert werden konfiguriert - und Plugins, die konfiguriert, aber nicht registriert sind, sind live, kann aber nicht als Inhalt auf Seiten eingefügt werden. Tolle Möglichkeit, Plugins zu erstellen die nur AJAX-Inhalte liefern und die niemals in Seiten verwendet werden sollten).

Installation

Herunterladen und Installieren als TYPO3-Extension, dann aktivieren Sie "Automatisch" konfiguration" in der Extension-Konfiguration von Realurl im Extension Manager. Wenn eine automatische Konfiguration vorhanden ist, entfernen Sie die Konfigurationsdatei und lassen Sie sie zu Realurl, um es mit den enthaltenen ER-Regelsätzen neu zu erstellen.

Verwendung

Die grundlegende Verwendung von ER ist einfach - einmal installiert, funktioniert es automatisch die Argumente, die angegeben werden, zu übersetzen, aber auf eine etwas andere Art und Weise als das wird in der Regel von Realurl durchgeführt. Das leicht modifizierte Verhalten entspricht dem von Extbase erwartete Variablentypen besser als das Standardverhalten.

Die Grundversorgung besteht aus der einfachen Installation von ER und dem Erinnern an das Löschen Die automatische Konfigurationsdatei von Realurl, wenn die Plugin-Konfiguration geändert wird.

Die meisten der benutzerdefinierten "Clear Realurl Caches" Erweiterungen auf TER können dies tun für dich. Ein Haken wurde nicht in ER aufgenommen (zum Zeitpunkt der Erstellung dieses Dokuments), da nicht alle Standortbetreiber würden dieses Verhalten genießen und ein Umschalten wäre die richtige Wahl nur eine Funktion, die jede Art von Erweiterungskonfiguration erfordert - also ist dies die folgende absichtlich nicht enthalten.

Beachten Sie, dass ER nicht mit POST'ed-Argumenten arbeitet, sondern die Datei Erhalten Sie einen Teil der Anforderung, wenn Sie auf POST antworten. Zum Beispiel POSTEN Sie an die URL /path/to/page/Controller/action.html und rufen Sie die richtige Methode auf, weil sie wird mit GET gelesen - muss aber die Datenargumente im Originalformat POSTEN.

Beachten Sie auch, dass ER URLs, die Sie umleiten(), von Ihrem Controller in URLs umwandelt wird aber keine URLs transformieren, die durch das Absenden eines Formulars erstellt werden, das Folgendes verwendet GET-Request-Modus (da diese URL vom Browser erstellt wird).

Integration

Eine erweiterte Integration ist durch die Verwendung von Anmerkungen zu Controller-Klassen möglich und seine Aktionsmethoden. Durch die Verwendung von Annotationen können Sie steuern, wie ER erstellt wird die Regelsätze für Ihre Seiten. Zum Beispiel, indem man konfiguriert, ob ER hinzufügen von Pfadsegmenten für den Controller und Aktionsparameter (Pseudocode, nur Pseudocode) die Anmerkungen zählen hier):

/**
 * @route NoMatch('bypass')
 */
klasse MyController {

    /**
     * @route NoMatch('bypass')
     * @route NoMatch(NULL) $Objekt
     */
    öffentliche Funktion myAction(Tx_MyExt_Domain_Model_MyObject $Object) {
        zurückkehren;
    }

}

Das obige Beispiel fordert Realurl auf, "zu umgehen" (d.h. vollständig zu ignorieren):

• Der Parameter tx_myext_myplugin[controller] weil @route NoMatch('bypass') ist auf die Controller-Klasse gesetzt.
• Der Parameter tx_myext_myplugin[action], da @route NoMatch('bypass') ist die auf die Aktion Steuerung eingestellt ist.

Und würde den Parameter tx_myext_myplugin[object] erfordern.

Eine solche Konfiguration wäre besonders sinnvoll für eine Show-Aktion, die eine menschenlesbarer URL-Parameter, der $object identifiziert (genau wie EXT:news suggeriert in das Wiki zur Realurl-Konfiguration)

Siehe http://forge.typo3.org/projects/extension-news/wiki/RealURL für die allgemeinen Informationen idee hinter der Transformation.

Standardmäßig sind sowohl der Controller- als auch der Aktionsparameter enthalten, wodurch URLs erstellt werden sehen ähnlich aus wie /path/to/page/Controller/action/human-readable-title.html.

Zukünftige Überarbeitungen werden es ermöglichen, dieses Verhalten ohne Verwendung von doc-Kommentaren zu ändern annotationen, was es einfacher macht, zu beeinflussen, wie ER Plugins verarbeitet, die keine Plugins verarbeiten eigene Anmerkungen hinzufügen, um - wie z.B. sehr häufig - die Controller für einige Plugins und Controller plus Aktion für "Detailansicht" Aktionen die als Plugins erstellt werden, die nur eine Aktion auf einem Controller aufrufen - nur eine Aktion wie EXT:news (und zufällig macht ER perfekte Regeln für EXT:news, aber sie beinhalten den Controller und die Aktion auch für die Detailansicht).

Zukünftige Überarbeitungen können diese Fälle möglicherweise sogar automatisch bearbeiten, indem sie scannen die Plugin-Konfiguration, um festzustellen, ob es sinnvoll ist, die beiden zu integrieren "hartkodierte" Argumente, Controller und Aktion. Aber bis zu diesem Zeitpunkt haben diese beiden argumente werden einbezogen, es sei denn, sie werden manuell mit Anmerkungen versehen.

Über Domain-Objekte

ER wird erkennen, ob Ihre Steuerungsaktion ein Domänenobjekt als Argument akzeptiert und wenn dies der Fall ist, wird ER erkennen, welches Feld als menschenlesbar verwendet werden soll URL-Parameter (z.B. /detail/this-is-my-object-title.html). Anstatt zu verlangen dass Sie das Labelfeld manuell konfigurieren, ER erkennt dies anhand des "Labels". eigenschaft, die im TCA des Domain-Objekts definiert ist - zusammen mit der DB-Tabelle.

Zukünftige Überarbeitungen werden eine größere Kontrolle über bestimmte Domänenobjekte ermöglichen argumente und ihr Verhalten.