30/03 2013

Under Construction

A bunch of new, delicious integration approaches are currently being written for Flux, FluidPages and FluidContent. We may break some stuff but we promise to fix it.

Dear developers

I can't wait to tell you about a number of new features being made for Flux, FluidPages and FluidContent. So here is a small teaser - it's intended to diminish the pain that may come from updating to a Git master which currently has introduced a few breaking changes (however, these breaking changes are located in the two template provider extensions fluidcontent_bootstrap and fluidpages_bootstrap - so you may want to check out the latest stable tag from Git if you have accidentally updated those on an existing site).

The next versions of these three extensions will be new major version numbers: Flux 6.0, Fluid Pages 2.0 and Fluid Content 3.0.

Without further ado, the teasers:

• Flux now has a debugging service; the extension toggle to enable debug output has been changed to set three possible levels - stray Exceptions will no longer be rethrown and almost every part of Flux has received debug output statements with useful information to debug your templates and the integration hereof. This debugging service is also widely in use in FluidContent and FluidPages now.
• Entire collections of page and content templates can now be registered using a single line in PHP, assuming template locations follow conventions. Collections added this way no longer depend on TypoScript being available - but collections can still be affected, for example disabled, through extended TypoScript templates on individual pages.
• Two new conventions will be added: PageControllers and ContentControllers which will operate on page and content records but do so from your own extension. These two new conventions will be used by the two Twitter Bootstrap packages. What this means is that in addition to everything you're used to doing with Fluid Content and Fluid Pages, you can now also have a custom Controller with one action per page template - exactly as if your extension was rendering a special "Page" object when rendering pages and a special "Content" object when rendering content. Yes, this does move it a lot closer to being an actual Extbase plugin used as content element - but there is a mountain of benefits in associating it with Flux (and FluidPages and FluidContent, but mainly because they use Flux for integration). Each controller type is enabled by the corresponding templating extension, i.e. install Fluid Pages to gain access to using PageControllers.
• FluidContent and FluidPages will both be able to use the standard template locations defined in the "view" section of a plugin's setup, but only when registering the extension using PHP and using Page/Content Controllers.
• Flux will be made extension scope aware. This simply means that if you use Flux from an extension (and this also includes FluidContent and FluidPages), then the extension scope of that extension will be used throughout the Flux processing logic. The benefits are plenty, but to name a few... f:translate will not need full paths, links to Controller actions don't need pluginName, extensionName etc., resource URIs can be built without enforcing the extensionName. And much, much more which relates to being able to fully trust the ControllerContext.
• Flux will be made even more localisation friendly. Among other things the "label" attribute is now optional wherever it is used - and if left out, Flux will construct an LLL reference to the default locallang.xml file for your extension. A few new conventions for naming LLL labels have been added; if these labels are added Flux will automatically use them. But that's not all!
• Flux will get a feature (with toggle) which can actually rebuild your LLL files on-the-fly, adding LLL labels you don't already have - this applies to every LLL reference automatically generated by Flux. This will most likely save you hours and hours of development time in the long run. If you need multiple translations for your content/page fields, start by adding an empty LLL file with as many languages as you like, enable the "rebuild" feature in Flux and start creating templates. Leave out every "label" attribute and voila - Flux will build a glorious LLL file with every missing identifier already added in all languages, ready to be properly filled out by a human.

All of these constitute huge improvements - but especially the last one should make Fluid Content and Fluid Pages insanely fast to create while at the same time almost automatically handling every LLL label used by every template. Once again saving you hours and hours of work on the most tedious bits of TYPO3 template development - as well as please your users even more. If you'd like to say thanks for getting those hours back to be used on finer things, feel free to use the "Feeling generous?" buttons on the front page ;)

Cheers,
Claus