Companion extensions

Templating manual

Edit this chapter on Github Jump to...

1.8 Development companion extensions

In addition to the rendering and management of pages and content templates, Fluid Powered TYPO3 also offers a handful of extensions which help solve common tasks while you are working on your templates.

Extension: view

The extension called view allows you to do two fairly simple things with great impact:

  1. Overlays for template paths, which means that instead of for example copying all template files from EXT:news into your provider extension in order to change the rendering, you can define a so-called "overlay" which makes Fluid try to load the template file from your folder first and then fall back to the original (EXT:news's) templates for those files that do not exist. Like the language overlay in TYPO3 which only applies when a record has a translation and displays untranslated records if no translation exists.
  2. Overrides of default argument values and overrides of all argument values used in every ViewHelper. By changing a default value you make Fluid use another value as default when no argument is provided. By changing an override value you can forcibly change the value of this argument throughout templates - ideal for example when used with the f:widget.paginate widget, in which case you can for example force-override the items per page value of all paginators everywhere, using a single setting.

Installing this extension is highly recommended as soon as your site requires customisations for any template provided by any extension.

Note: Fluid Powered TYPO3 extensions which depend on Flux, all natively support such overlays without the need for EXT:view. If you use no other extensions, you will most likely not need EXT:view. If you create an extension which also uses Flux - for example, a custom provider extension for fluidcontent - this extension will also support overlays in template path settings just like the official Fluid Powered TYPO3 extensions, also without needing EXT:view.

The extensions below this point are NOT for production use! Most of them cause a significant drop in performance!

Extension: builder

The extension called builder is exactly this - a builder companion which creates code for you and analyses/validates the code you yourself write. Among other things, builder can generate new provider extensions very quickly, can validate all ViewHelper tags in all templates in the site, can provide useful metrics about your templates (compilability, node counts, problematic structures, "monolithic" templates and overuse of f:if and other conditions which greatly increase the size of cached code).

The extension has three main purposes:

  1. Build standards-compliant code quickly - generate a complete extension skeleton to start working on site templates within a few seconds.
  2. Validate and scrutinise your work upon deployment - for example, checking that the Fluid ViewHelper arguments you used in templates are working on the TYPO3 version you target.
  3. Detect problems when you encounter unexplainable errors - for example, builder can tell you if a bad ViewHelper argument was used in a particular Partial or Layout, which you normally cannot (easily) deduce from the Exceptions thrown when rendering the template.

Extension: flll

Behind the somewhat cryptic name which sounds like a particularly distressing bowel movement is a very powerful productivity feature: automatic writing of any LLL value which does not currently exist. In plain English this means that every time you use f:translate or indeed any translation feature in TYPO3 which is based on .xlf or .xml templates, flll will on-the-fly create the label with a default value in every language currently active on the site. It works in Fluid templates, TypoScript, TCA, old translation functions, Extbase's LocalizationUtility - literally any file-based localisation which TYPO3 supports.

No more editing of locallang files to manually add labels. That alone should save you a bunch of time - but needless to say, the performance impact is quite significant. You may want to use flll sparingly because of this (or at the very least make sure you use the whitelisting feature of flll).

Extension: schemaker

This extension has one purpose: documenting ViewHelpers (your own ones, Fluid's, VHS's, Flux's,...) by use of the XSD (XML Schema Description) format which is a standardised format to define rules for XML - which arguments a tag type must have, the type of arguments, etc.

Schemaker creates these .xsd files for you and (when so enabled) also renders a live frontend-based argument inspection (the very one used on http://fluidtypo3.org/viewhelpers.html). The .xsd files you can use for auto completion support when editing Fluid templates in PHPStorm and the plugin you can (just as an example) use on internal wiki sites to document your team's private ViewHelpers.

Continue: Chapter 2: Install

Jump to...