1.1 Extension Based Storage

The new way: the Provider Extension

Fluid Powered TYPO3 encourages a new approach when creating the templating assets for your sites:

• We recommend using an extension to store all your files: templates, icons, images, stylesheets, scripts and all. This approach allows a few clever conventions to do most of the referencing. For example, your LLL files can reside in standard locations and your translation function calls can be much shorter. You can in almost all cases still reference your files using EXT:myext... paths if you need to.
• We recommend using known Extbase conventions for placing configuration files, language files, private/public resources, class files and in short, everything that you are building.

The main difference lies in the recommended use of an extension to store your files. We call this particular type of extension a "Provider Extension" - it "provides templates and configuration for those templates".

A Provider Extension may still contain the usual Extbase plugins, static TypoScript and such, but should prepare to respect a few reserved controller names and therefore also template locations:

• The Page Controller name and template path is reserved for page template files using EXT:fluidpages.
• The Content Controller name and template path is reserved for content element template files using EXT:fluidcontent.
• The CoreContent Controller name and template path is reserved for content element template files using EXT:fluidcontent_core.
• The Backend Controller name and template path is reserved for backend module template files using EXT:fluidbackend.

This approach is much different from what you are used to from TemplaVoila but is easily understood (or learned by example; good places to learn this way are the generic provider extensions you get from Fluid Powered TYPO3). Once you get used to this other approach which focuses on files instead of database configurations you will find your work flow more consistent; editing in your editor instead of through the TYPO3 backend and of using version control software on your template files and assets (don't despair - you can always learn this last bit once you are comfortable with the new way of doing things).

It is quite a change if you are used to editing files through TYPO3's backend. But it's also a jump that's very much worth making.

Why is this way better?

There are quite a few ways why we think this new way is a lot better than the old way. Among our favorite reasons are:

• It's better to use Fluid to define additional, flexible fields for a record than to use a traditional FlexForm. Not only does it become dynamic (conditions, loops etc. become possible) - it is also around 10x more compact than FlexForm XML and the difference just increases as complexity rises: your Flux field is still one ViewHelper tag but the XML could be 30+ nodes.
• It's better to use files than database storage for a site's design. It's less error prone (remember those UTF8-upgrades that broke your TemplaVoila template mappings...?) and allows for much better version control and conflict resolution when multiple authors work on the same template file.

But really, what we consider the main benefit is that we get to use Fluid for every single design and layout aspect of our sites. And that we don't have to spend a lot of time worrying about integration - now, much more than before, we can focus on the core task of creating excellent designs, useful and flexible content elements and much more.

Continue: Chapter 1.2: Flux usage.