12/02 2015
Coming changes in Flux 7.2

Information for developers about what to expect in Flux 7.2 in terms of new and deprecated features.

Dear developers,

As usual, here is a small article about which changes and features you as a developer should expect in Flux 7.2 and how your projects can be improved when you use the new version.

Obviously, Flux 7.2 and associated extensions are compatible with TYPO3 CMS 7.x. As usual we make an effort to always support the most recently released TYPO3 version as well as the most recent LTS version.

Legacy supports removed

We have removed support for the long deprecated legacy TypoScript registration methods which Flux has contained ever since the FED days. This means that:

 

  1. You can no longer use plugin.tx_fluidpages.collections.*, plugin.tx_fed.page.* (and corresponding for Fluidcontent) to register collections.
  2. The only way to ship a collection of templates is in a Provider Extension.

Although this is not a change in Flux itself it is done to homogenise the template path setups that Flux consumes. The relevant commits are:

 

If you are upgrading a project that uses these legacy registrations and your templates already exist in a Provider Extension, migration is easy - simply switch to the new way of registering all your templates by extension key: https://fluidtypo3.org/documentation/templating-manual/templating/provider-extension/registration-in-php.html.

If the project is old enough that your templates are located in for example fileadmin, you need to create a Provider Extension and move your template files into it. Choose the same extension key for your Provider Extension as was the name of your collection in TypoScript so you don't have to migrate database records! To learn more about generating a Provider Extension, see <link https: fluidtypo3.org documentation templating-manual templating provider-extension generating-extensions.html>fluidtypo3.org/documentation/templating-manual/templating/provider-extension/generating-extensions.html.

Unified template paths

One of the new features is a unified support for ways to configure template paths in TypoScript. Since TYPO3 CMS 6.2 the new templateRootPaths (note the "s") configuration options to define multiple paths have become available, but Flux until now had retained it's support for "overlays" configured like EXT:view.

The new change means that all of the following configuration methods are now supported transparently without a need for migration:

 

  • plugin.tx_myext.view.templateRootPath of course, acting as a default/fallback containing a single path.
  • plugin.tx_myext.view.templateRootPaths containing an array of paths (ideally using the extension key that added them as key in the TypoScript array).
  • plugin.tx_myext.view.overlays.xyz.templateRootPath containing a single path, EXT:view style.

And of course the corresponding locations for partialRootPath(s) and layoutRootPath(s).

The new preferred way of defining template paths is to use the TYPO3 core's preferred way - which is the plugin.tx_myext.view.templateRootPaths way containing an array of paths, all of which are checked when Fluid tries to find a template file.

MultiRelation field type

A new Flux field type has been added which (re-)introduces the support for creating the "group" TCEforms field type - which basically is a multi-value field that can contain references to not just multiple records, but multiple records from multiple tables.

The rendering type of this field is slightly different - most importantly, it includes the browse feature that opens a popup window with a page tree enabled browse component. Many users prefer this UX over the single relation field type which lacks this browse feature (but had a less capable alternative in the form of Wizards).

In short: if your UX goals would imply a "group" type field in TCA then you may want to try using flux:field.multiRelation in your Flux Form to get as close to that as possible.

Preview Widget replaced

We have replaced the way Flux generates previews when a Grid is involved. Before, Flux would render the Grid from the Fluid template file which means the template had to be parsed (or loaded from compiled cache) and then rendered, involving a significant amount of processing. The content element container areas are now rendered by a special View class, significantly increasing performance when working with multiple nested elements.

The new behaviour:

 

  • Renders a Grid as content element container in the page module if your template defines one, regardless of whether or not you have a Preview section.
  • Deprecates flux:widget.grid which no longer has any function.
  • Removes all support for setting the Fluid template used to render the Grid.

Basically, we sacrifice the rarely used template replacement feature for increased performance in very frequently executed code.

Form options made easier

To make it easier to define options previously defined using <flux:form ... options="{}" /> we have added ViewHelpers that can be used as children of flux:form to define options:

<flux:form ...>
    <flux:form.option name="icon" value="..." />
    <flux:form.option name="group" value="MyElements" />
    <flux:form.option name="preview" value="{mode: 'append'}" />
    <flux:form.option name="Fluidcontent" value="{sorting: 123}" />
</flux:form>

And so on with all supported options. Although now a major new feature, it does allow you to avoid very large options arrays on flux:form - and it allows us and you to create dedicated ViewHelpers that define individual options.

Hint: any options, including custom ones that you yourself define, <link https: fluidtypo3.org documentation templating-manual advanced-provider-extensions custom-flux-controllers controller-actions.html>can be retrieved from a Flux-enabled controller's actions via the Provider associated with the controller. All thanks to the presence of $this->provider and the methods you can call on it.

Extension context overrides for Form Components

Behind the slightly generic title lies a common problem: Flux supports placing parts of each Form in one or more Partial templates which can then be overridden by an integrator/developer to let her change the fields. However, when doing this, the original extension context is retained which means that any automatic labels for the form fields would be attempted fetched from the original extension instead of the one containing the Partial template.

To let you have complete control over that behavior, we have added (or rather, exposed - because it was already there) the extensionName property on every Form Component. Setting this property on a flux:form.field.* or flux:form.sheet or any other component causes Flux to look in that extension when generating automatic label references.

This has the additional impact that on flux:form.field.controllerActions, the argument formerly known as extensionName which defined the extension to look in when determining available controller actions, is now known as controllerExtensionName - and the old argument now behaves as described above.

Convention-based icons for templates

Rather than requiring you to define the (optional) icon file that gets associated with each template and displayed in the new content wizard, page layout selectors etc., we have added a feature that lets you simply place the icon file at an expected location in your Provider Extension and Flux will then use that file as icon.

If for example your template file is located in EXT:myext/Resources/Private/Templates/Content/MyContent.html then the expected icon file location will be EXT:myext/Resources/Public/Icons/Content/MyContent.png (.gif extension also supported).

The icon that gets resolved is always resolved based on the extension context (note: the previous section is also relevant here!) and file subfolder. Basically, overriding a Flux template and giving it another extensionName to use as context, makes Flux look for the icon in that other extension instead.

If a convention-based icon file exists, Flux can avoid costly calls to retrieve the icon setting from within the template file thus further increasing the backend's performance in daily use.

TypoScript overrides

Although this feature is still on the drawing board and cannot be described in detail, it's worth mentioning here. We are working on a way to let integrators override options and composition of Flux forms by using TypoScript - which will for example allow the integrator to use TypoScript to control which page/content template may be used, as well as selectively override settings like the sorting value of Fluidcontent elements or the allowed content types inside a Fluidpages-enabled page template's Grid.

Essentially, TypoScript overrides for Flux Forms which can be used as an alternative to overriding and changing the template file that contains the Flux Form definition. With the added benefit that these options can be overridden anywhere in the page tree - something which you until now had to manually support via the {settings} array and conditions in Fluid.

That's all - for now

More information will follow about the TypoScript overrides as the feature gets built - stay tuned!


Kind regards,
The FluidTYPO3 Team

 

Archive

09/01 2017
09/11 2016
09/06 2016
21/12 2015
07/12 2015
25/11 2015
25/09 2015
22/09 2015
01/08 2015
10/03 2015
03/03 2015
12/02 2015
25/11 2014
01/11 2014
16/10 2014
02/10 2014
02/10 2014
19/09 2014
18/09 2014
05/09 2014
22/08 2014
02/08 2014
27/06 2014
06/06 2014
13/04 2014
27/03 2014
12/03 2014
11/03 2014
05/02 2014
25/01 2014
17/12 2013
08/12 2013
03/12 2013
04/11 2013
Flux 7.0 Teaser
06/08 2013
21/07 2013
10/06 2013
04/06 2013
01/06 2013
27/05 2013
19/05 2013
19/05 2013
11/05 2013
26/04 2013
30/03 2013
19/03 2013
17/03 2013
13/03 2013
10/03 2013
10/03 2013
05/03 2013
04/03 2013
03/03 2013
02/03 2013
01/03 2013
28/02 2013
27/02 2013
25/02 2013
24/02 2013
24/02 2013
23/02 2013
10/02 2013
03/02 2013
03/02 2013
27/01 2013
Asset management in Fluid
20/01 2013
16/01 2013
13/01 2013
08/01 2013
16/12 2012
25/11 2012
18/11 2012
08/11 2012
07/11 2012
05/11 2012
04/11 2012
28/10 2012
22/10 2012
14/10 2012
13/08 2012
08/08 2012
31/07 2012
30/07 2012
25/07 2012
29/04 2012
29/04 2012
22/04 2012
16/04 2012
21/03 2012
Flux 1.4.0 released
08/03 2012
Flux 1.3.0 released
04/03 2012
03/03 2012
28/02 2012
19/02 2012
A Sneaky Sneak Preview of the next version of Flux
13/02 2012
12/02 2012
06/02 2012
30/01 2012
27/01 2012
15/01 2012
26/12 2011
24/12 2011
11/12 2011
11/12 2011
10/12 2011
04/12 2011
04/12 2011
30/11 2011
26/11 2011
25/11 2011