3.1.2 Extension scope explanation

By isolating each package of templates and configuration into Provider Extensions we clearly separate them - and allow them to be used together in sites. Just as an example, there is no reason why you cannot install both a Twitter Bootstrap and Foundation based set of templates in different Provider Extensions and simply pick-and-choose which type of template to use on a per-page basis. Without any conflicts (assuming the Provider Extension follows our suggested best practice as described in this manual).

Among the most important benefits of using an extension for storage are:

Isolated contexts

By far the greatest advantage of placing templates in an extension is the conventions for expected file locations. Without going into too much detail this simply means that ViewHelpers like f:translate will know which LLL file to look for without the need to add LLL:EXT:myextensionkey/Resources/Private/Language/locallang.xlf to every instance, that f:uri.resource knows to look in your extension's public resources folder - and more along the same line. Extbase and Fluid both rely on stricter conventions than you may be used to - but this is all for the better. Instead of having to inspect configuration to know where you placed your template files and resources, all you need to know is the extension key to which they belong.

Shared settings

Because of the extension scope Extbase can expect to find TypoScript configuration in the reserved location plugin.tx_yourextensionkey.settings - which when used, is transferred to controllers and views throughout your extension without requiring you to manually assign them as view variables, transfer them in arguments of f:render and more.

Even more so, this special reserved settings name can be used as prefix for your names of form fields you create using Flux - in which case the value that the content editor enters, gets merged with (and overrides) any TypoScript settings of the same name. You can even control this behavior in detail when you use a custom controller for a Flux-enabled feature.

Conventions for file paths

Extbase states very clear conventions for where to (by default) look for template files associated with an extension. While this in itself may not be the greatest advantage you see right away (the paths tend to be quite long compared to fx an old fileadmin/templates/ path), it should become obvious as you work in teams to create templates for sites. Agreeing on a convention is a great benefit to teams - and Extbase allows you to adopt one instead of inventing your own.

Controller based features

All of the key features in Fluid Powered TYPO3 depend on Extbase controllers to get the job done. We chose a way of creating and using controllers which also allows you to drop-in replace our controllers with your own classes. However, Extbase controllers are tightly bound to an extension context which means you will have an inordinate amount of trouble if you attempt to create an Extbase controller class outside an extension scope and then want to make this class available.

By agreeing on the convention of an extension as storage a controller convention follows automatically. This means Flux can detect the presence of drop-in replacement controllers simply by attempting to load the expected class name - which naturally exists within the namespace of your extension.

Best possible starting point

When your starting point is already an extension - with LLL files, template folders, TypoScript configuration and all the rest - it becomes easier than ever to begin adding more advanced features. For example, true Extbase plugins which exist in the same extension as the page templates and content elements for a site.

In summary: Extbase dictates the use of an extension scope to gain access to all the benefits that a convention-over-configuration strategy implies.