Nach einigen Rückfragen haben wir nun endlich die Zeit auf den T3DD14 genutzt den Autoloader zu veröffentlichen. Die Extension soll einem die Arbeit beim entwickeln von Extbase Extensions ein wenig abnehmen und unterstützt den Entwickler mit ein wenig Magie im Hintergrund. Ich möchte euch nun kurz Vorstellen was der Autoloader machen kann und wie dieser strukturiert ist:
Struktur
Der Autoloader besteht aus einer einfachen API, welche in einer eigenen Extension benutzt werden kann, um innerhalb des ext_localconf bzw. ext_tables Kontext einige Konfigurationen automatisiert zu laden. Um den Autoloader zu benutzen müssen in den ext_*-Dateien folgende Zeilen untergebraucht werden:
// in ext_localconf.php \HDNET\Autoloader\Loader::extLocalconf('VENDORNAME', 'extension_key'); // in ext_tables.php \HDNET\Autoloader\Loader::extTables('VENDORNAME', 'extension_key'); |
Die Grundlage des Autoloader läuft dann eine Reihe von Loadern, welcher verschiedene Ordner/Strukturen prüfen und entsprechend die passende Konfigurationen laden. Zusätzlich sind die Loader unterteilt in einen cachebaren aufwändigen Teil, sowie in die Registrierung selbst. Dadurch können wir beim ermitteln der Dateien umfangreichere Verfahren benutzen (Reflection, Ordner auslesen) ohne das beim zweiten Klick die Performance darunter stark leiden muss.
Loader
Im Folgenden werde ich euch einmal kurz die zentralen Loader vorstellen und in ein Paar Stichpunkten erläutern was diese tun. Bei ALLEN Beispielen sind KEINE Änderungen an den ext_* Datei der Extension nötig:
- CommandController
CommandController werden automatisch registriert, sobald diese im Ordner „Classes/Command/“ liegen. - ContentObjects
ContentObjects sind SmartObjects (s.u.) und liegen im Ordner „Classes/Domain/Model/Content/“. Content Objekte erweitern tt_content können aber auch auf bestehende Felder zurückgreifen. Pro ContentObject wird ein normales Content Element an TYPO3 registriert. Dies wird von einem zentralen Controller gerendert und lädt das Template in „Resources/Private/Templates/Content/“ welches genauso heißt wie das Model. Übergeben wird das Model und auch die komplette Row des Inhaltselements. Kurz zusammengefasst: Somit wird nur ein Model und ein Template benötigt um ein Inhaltselement auf Basis von tt_content zu bauen. - FlexForms
Flexforms werden aus dem Verzeichnis „Configuration/FlexForms/“ geladen und mit Plugins verknüpft. Dies geschieht auf Basis des Namen. Wenn es ein PluginA.xml FlexForm gibt, wird dies an das Plugin mit dem Namen „PluginA“ gebunden. - Hooks
Hooks werden aus dem Ordner „Classes/Hooks“ geladen. Es werden alle Klassen geprüft und nach einer „@hook“ Annotation gesucht, welche entweder an einer Klasse oder an einer Methode stehen kann (je nachdem wie der Ziel-Hook integriert ist). Die Annotation „@hook TYPO3_CONF_VARS|SC_OPTIONS|recordlist/mod1/index.php|drawFooterHook“ sorgt somit dafür, dass die Funktion an der die Annotation gefunden wird mit dem entsprechend verknüpft wird. - Slots
Slots werden in „Classes/Slots“ gesucht. Es werden ebenfalls die Klassen analysiert und nach „@signalClass“ und „@signalName“ gesucht. Werden die Annotationen gefunden, wird die betroffene Methode mit dem Signal verknüpft und dient als Slot. - SmartObjects
SmartObjects stellen die Basis für die ContentObjects und helfen dabei, Modelle schneller zu entwickeln welche in der Persistenz-Schicht abgelegt werden sollen. Die Zentrale Annotation dafür ist „@db“. Steht ein „@db“ an einem Model, ist dies ein SmartObject und die Datenbank wird entsprechend der Properties angelegt. Steht ein „@db“ an einer Property, wird anhand des Variablen-Typ der Datenbank-Typ ermittelt, sodass die SQL CREATE-TABLE Abfrage vollständig ist. Sowohl mit dem „@db“ am Model als auch an der Property, kann entweder die Ziel-Datenbank geändert werden (ContentObjects: „@db tt_content“) oder an den Properties der Datenbank-Typ für komplexe Datentypen bestimmt werden („@db int(11) NOT NULL“). Die Datenbanken werden mittels eines Slots innerhalb des „SqlExpectedSchemaService“ integriert, weshalb es somit keine ext_tables.sql Datei mehr geben muss (ist zusätzlich natürlich weiterhin möglich). - StaticTyposcript
Alle setup- und/oder constants-Text-Dateien, welche innerhalb „Configuration/TypoScript“ gefunden werden, werden als Static Extension TypoScript geladen. Die Suche geschieht rekursiv weshalb auch Unterordner möglich sind. Gibt es Unterordner, werden diese in den Bezeichner der Registrierung mit aufgenommen. - TcaFiles
Dieser Loader durchläuft alle SmartObjects und erzeugt eine TCA Datei, für die welche eine brauchen aber noch keine haben. Dabei wird das TCA auf Basis des Model „vorgebaut“ und kann durch den Entwickler überschrieben werden. - Xclass
Nach Xclasses (Achtung, es handelt sich um den neuen TYPO3_CONF_VARS/SYS/Objects Mechanismus und nicht der alte Xclass-Mechanismus) wird in dem Ordner „Classes/Xclass“ gesucht. Gefundene Klassen werden reflektiert und passend registriert. Somit braucht man nur noch eine Klasse dort ablegen und von der zu erweiternden Klasse erben. Das war’s 😉
Wie geht es weiter?
Die Extension wurde eben frisch im TER veröffentlicht und kann nun frei benutzt werden. Wie ihr sieht ist es wiederum eine weitere Möglichkeit Content Objekte schnell zu bauen – jedoch auf einer sehr technischen Ebene. Innerhalb der Extension (in den Resources/Private/Examples) liegen Beispiel-Extensions für die einzelnen Loader Implementierungen. Wir freuen uns natürlich über Feedback zur Extension, sodass wir weitere Loader implementieren oder Fehler korrigieren können. Unter folgenden Links erreicht ihr alles: