Hallo zusammen
Letzte Woche haben wir die erste Version der Arcaivas Webshop Extension
veröffentlicht, die mit allen TYPO3 Versionen von 4.5 bis 6.1 funktionsfähig
war (für die, die es interessiert gibt es hier mehr Infos dazu:
http://forum.typo3.org/index.php/t/200655/). Dabei haben wir einige Erfahrungen
gesammelt, die wir während des Anpassens und Testens der Extensions gemacht
haben und die wir gerne hier teilen möchten.
Wenn ihr eure Extension direkt mit Extbase anstatt dem PI-basierenden Ansatz
entwickelt habt, dann habt ihr sicher auch die neuen Tx_ Klassen benutzt, die
die benötigte Funktionalität wesentlich sauberer kapseln. In TYPO3 6.x wurde
das zwar auf Namespaces umgestellt, aber es gibt eine Kompatibilitätsschicht,
so dass in den meisten Fällen auch die Tx_ Klassen in 6.x benutzt werden
können. Leider haben sich aber einige Implementierungen in 6.x stark geändert
und für genau die gibt es dann auch keine Kompatibilitätsschicht.
Einer dieser Problemfälle ist die Handhabung von flash messages im Tx_
ActionController bzw. in den neuen Namespace-Variante. Im
Tx_Extbase_MVC_Controller_ActionController gibt es eine Eigenschaft
flashMessageContainer, die ein Objekt enthält, zu dem man wichtige Nachrichten
für den Benutzer hinzufügen kann, z.B. falls ein Fehler aufgetreten ist, der
nicht weiter behandelt werden kann:
$this->flashMessageContainer->add( ... );
In TYPO3 6.x hat sich die Implementierung der flash message Objekte ziemlich stark geändert
und ist nicht mehr kompatibel mit dem $this->flashMessageContainer Objekt weil sich die
Methodennamen und die benutzten Objekte im Vergleich zu 4.x stark geändert haben. Eine
Kompatibilitätsschicht gibt es dafür nicht, aber für die ganz alte t3lib_ Variante. Anstatt
also die schönen neuen Objekte zu benutzen muss man hier auf die "altertümlichen"
t3lib Klassen zurück greifen, damit es mit 4.x und 6.x funktioniert:
t3lib_FlashMessageQueue::addMessage( new t3lib_FlashMessage( '<message>',
'Error', t3lib_Flashmessage::ERROR );
Die Scheduler Tasks ("Planer" in der deutschen Übersetzung) machen auch Probleme, weil
sich das PHP Interface für die "additional field provider" (Klassen um zusätzliche Felder
im Task anzeigen und auswerten zu können) geändert hat und auch nicht rückwärtskompatibel ist.
In TYPO3 4.x erben die "additional fields provider" nur von tx_scheduler_Task
und müssen folgende Methoden implementieren:
- public function getAdditionalFields( array &$taskInfo, $task,
tx_scheduler_Module $parentObject )
- public function saveAdditionalFields( array $submittedData, tx_scheduler_Task
$task )
- public function validateAdditionalFields( array &$submittedData, tx_scheduler_Module $parentObject )
Die Provider in 6.x müssen dagegen das
\TYPO3\CMS\Scheduler\AdditionalFieldProviderInterface implementieren, das
folgende Methodensignaturen beinhaltet:
- public function getAdditionalFields( array &$taskInfo, $task,
\TYPO3\CMS\Scheduler\Controller\SchedulerModuleController $parentObject )
- public function saveAdditionalFields( array $submittedData,
\TYPO3\CMS\Scheduler\Task\AbstractTask $task )
- public function validateAdditionalFields( array &$submittedData,
\TYPO3\CMS\Scheduler\Controller\SchedulerModuleController $parentObject )
Der Unterschied ist im Typ des letzten Parameters der Methoden. Die übergebenen Objekte
sind nicht kompatibel und haben unterschiedliche Methoden und es gibt auch nicht die
Möglichkeit, nur die alte Variante zu benutzen. Unsere Lösung dafür war, zwei
verschiedene Klassen zu implementieren mit dem jeweils richtigen Interface zu
implementieren und den gemeinsamen Code in eine Basisklasse auszulagern, der von den
jeweiligen getAdditionalFields(), saveAdditionalFields() und validateAdditionalFields()
Methoden benutzt wird. Um die richtige Implementierung für die jeweilige TYPO3 Version
bereit zu stellen haben wir eine Art "feature detection" in der
ext_localconf.php benutzt (die TYPO3 Version als Weiche zu benutzen schlägt früher oder
später immer fehl!):
if( class_exists( '\TYPO3\CMS\Scheduler\Task\AbstractTask' ) ) {
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['Arcavias\Arcavias\Scheduler\Task\Typo6']
= ...
} else {
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['Tx_Arcavias_Scheduler_Task_Typo4']
= ...
}
Zu guter letzt sollte man sich vor Augen halten, dass die Namen der Tx_ Klassen
in ext_autoload.php immer klein geschrieben werden müssen (das steht auch
irgenwo in der Doku). In manchen Fällen funktioniert es auch mit der
Orginalschreibweise (also camel-cased), aber nicht für den Schedulerteil. Um
die Sache noch etwas komplizierter zu machen betrifft das allerdings nicht die
neuen Klassen mit Namespaces in 6.x! Folgendes Beispiel für 4.x und 6.x
funktioniert:
'tx_arcavias_scheduler_task_typo4' => $extensionPath .
'Classes/Scheduler/Task/Typo4.php',
'tx_arcavias_scheduler_provider_typo4' => $extensionPath .
'Classes/Scheduler/Provider/Typo4.php',
'Arcavias\Arcavias\Scheduler\Task\Typo6' => $extensionPath .
'Classes/Scheduler/Task/Typo6.php',
'Arcavias\Arcavias\Scheduler\Provider\Typo6' => $extensionPath .
'Classes/Scheduler/Provider/Typo6.php',
wobei $extensionPath = t3lib_extMgm::extPath( 'arcavias' );
Wenn ihr vor dem gleichen Problem steht und euere 4.x Extbase Extension fit für
6.x machen wollt, spart euch das hoffentlich einiges an Zeit, die wir nach
vernünftigen Lösungen gesucht haben. Wenn ihr eine bessere Lösung für eines der
Probleme kennt, dann würde ich mich freuen, wenn ihr sie hier posten würdet :-)
Norbert
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
