Danke Für das Teilen Deiner Erkenntnisse. Normalerweise Solltest du deine Classen Nicht in ext_autoload eintragen müssen wenn sie dem Typo3 Namenschema entsprechen. Dann findet typo3 sie automatisch.
Ext_autoload.php ist nur für classen gedacht die nicht dem typo3 namenschema entsprechen z.b weil sie aus einer externenlibary kommen. Es kann sein das es einschränkungen beim autoloading für "low-level" entry points gibt. (eID,scheduler) das weiss ich nicht genau. Es stimmt das man die classenamen in ext_autoload.php kleinschreiben muss (jedenfalls unter typo3 4.5 später wurde das behoben) Gruss chris -----Ursprüngliche Nachricht----- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Norbert Sendetzky Gesendet: Freitag, 14. Februar 2014 12:02 An: typo3-german@lists.typo3.org Betreff: [TYPO3-german] Tipps, wie man Extensions für TYPO3 4.x und 6.x implementieren kann 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 _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
