[TYPO3-english] Hints for writing extensions for TYPPO3 4.5 to 6.1

[Helmut Hummel]

Hi Norbert!

Thanks for sharing your insights!
I have some comments, further hints and some questions.

On 14.02.14 11:18, Norbert Sendetzky wrote:

> $this->flashMessageContainer->add( ... );
>
> In TYPO3 6.x the implmentation of the flash message objects changed very much and is totally incompatible with the $this->flashMessageContainer object because method names and nested objects are not the same as in the Tx_ variant. Also, no compatibility layer is provided for that. But, there's one for the very old t3lib_ implementation! So instead of using the cool new object, we have to use the "ancient" one to get things running for 4.x and 6.x:
>
> t3lib_FlashMessageQueue::addMessage( new t3lib_FlashMessage( '<message>', 'Error', t3lib_Flashmessage::ERROR );

I wouldn't recommend doing so. Instead I would use the API introduced in 
6.2 (compatible to FLow API) that is calling ->addFlashMessage in your 
controller code. Since there is no such API is present in older versions 
you would need to implement the method yourself and do feature detection 
in there.

I would however support any effort to backport this API to older Extbase 
versions to make life easier in this area for developers.

> The scheduler tasks are another source of problems because the interface of the additional field provider has changed in a way that isn't backwards compatible.
>
> In TYPO3 4.x, additional fields provider only extends from tx_scheduler_Task and must implement these methods:
> - 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 )
>
> Additional fields provider in 6.x must implement the \TYPO3\CMS\Scheduler\AdditionalFieldProviderInterface, which has the following method signatures:
> - 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 )

Old interface names are aliased to the new interface names. With PHP > 
5.3.7 using old interface names should work out without issues. Be sure 
to remove require statements on TYPO3 core classes or interfaces though.

> The differences are what is expected as the last parameter of the methods. The objects handed over are not compatible and have different methods there is also no translation layer available that could be used. Our solution was to create two different classes, one for 4.x and one for 6.x that provides the correct interface and an abstract class with the common code for both, that is called by getAdditionalFields(), saveAdditionalFields() and validateAdditionalFields(). To use the correct class for the TYPO3 version, we used some kind of feature detection in ext_localconf.php (checking for version sooner or later always fails!):

Same for tx_scheduler_Module which is aliased to 
\TYPO3\CMS\Scheduler\Controller\SchedulerModuleController

Of course some things changed there, but basically the same methods are 
there. It also should not be needed to access methods in this class as 
it mostly deals with showing the scheduler module.

What differences are the ones that made you do different implementations 
for 6.0 and above?

> The last thing you have to be aware of (and the docs also mention this somewhere) is that the names of the Tx_ classes in ext_autoload.php must be always in lower case. Sometimes it also works when using the camel-cased names but not for the scheduler part! To make things more confusing, this must not be the case for the namespaced classes, so it must be:

First off: It should not matter if a class is namespaced or not, whether 
to use correct casing or all lowercased. Before 6.0 all classes in 
ext_autoload.php files needed to be lowercased, since 6.0 they can be, 
but must not be lowercased. Namespaced or not does not matter. Any 
different behaviour is a bug which needs to be fixed.

> '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',

Besides that, I highly recommend *not* to use the autoloding registry at 
all. Instead use class names and file structure according to our naming 
convention.

If you use Extbase, class names will be resolved automatically since 
TYPO3 4.3

If you do not use Extbase class names following the naming convention 
are still automatically resolved since TYPO3 6.0 and in your extension 
that needs to be compatible with older TYPO3 versions, it is very easy 
to implement your own autoloader and register it for lower TYPO3 versions.

Kind regards,
Helmut

-- 
Helmut Hummel
Release Manager TYPO3 6.0
TYPO3 Core Developer, TYPO3 Security Team Member

TYPO3 .... inspiring people to share!
Get involved: typo3.org