Since TYPO3 10.0 it is possible, actually necessary, to use FQCN (=Fully Qualified Class Names) for controllers when configuring plugins and modules. This provides a new benefit in terms of reusing and sharing code between different extensions.
This blog post will explain the benefit and provide an outlook in a possible future of TYPO3 Extbase extensions.
The technical change ¶
The new feature was introduced in TYPO3 10.0 as an actual deprecation of the old way to register plugins and modules when working with Extbase. Refer to TYPO3 Changelog 10.0 Deprecation #87550 to have a detailed explanation of the change.
Before 10.0 one registered the vendor independent from the actual controller name. Controller class names were build by Extbase, based on their provided alias and the vendor. Since 10.0 there is no more vendor but fully qualified class names (=FQCN). An example configuration of a plugin looks like this:
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin( $extensionName, $pluginName, [ \DanielSiepmann\ExtensionName\Controller\Frontend\CalendarController::class => implode(',', [ 'month', 'week', 'day', ]), ] );
The benefit ¶
This allows to use controllers from all possible namespaces. Therefore a plugin can be configured to use a controller from a foreign Extension. That Extension should be required in
Why is that actual a benefit? This small change allows to reuse existing controllers. The example above contains a calendar controller to view a month, week and day. The extension also has some models which are part of the controller actions. Another extension which might need a calendar could now define a dependency and configure their own plugins to reuse this controller and models.
That way the extension does not need to reimplement logic to build up data structure for calendars. Instead it can focus on their own parts.
The conclusion ¶
In order to make all that work, controllers and models should be selfincluded. They should "just work" and solve a single issue. Otherwise one will easily mix up things and create bloated plugins.
As templates belong to the extension namespace configuring the plugin, the new extension can provide custom templates with rendering for month, week and day. Each of them can contain links back to other actions, e.g. of controllers provided by the second Extension.
Also in case the calendar Extension makes it possible to easily attach custom records to these models, they would be available in the templates already.
Possible Outlook ¶
I'm not investing time in developing Extbase and therefore my outlook might not match the actual future. But in my opinion Extbase is changing and so should developers. It looks like most Extensions are built without thinking in a Unix / composer way. Instead of putting everything into an Extension, it would make more sense to focus on one thing and reuse existing components, either TYPO3 Extensions or composer packages.
That way issues should be solved way faster. Developers would focus on the important things.
Imagine an calendar Extension that would do all the calendar stuff. Another extension would provide data and logic to buy tickets for events. Combine both with a third extension, or add support for the calendar Extension within the ticket Extension. Without further overhead, all would have less code with more features. That would make Extensions easier to maintain.
Maybe some "Extensions" no longer will be Extensions, but pure composer packages providing some specific logic that can be reused by TYPO3 Extbase Extensions, as well as other systems.
Further reading ¶
- Changelog entry regarding the change: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.0/Deprecation-87550-UseControllerClassesWhenRegisteringPluginsmodules.html
- Tweet mentioning the idea to write this blog post: https://twitter.com/daniel_siepmann/status/1319900536683040768