4.1.1 Use case for custom Flux Controllers

You can opt to use a Flux-enabled controller whenever you want your controller to work more closely with your Provider class. Using the controller base gives you automatic access to the Provider and lets the Provider deliver view variables and more. While you are not required to use this controller base, it makes it easier to implement many view-related features. You can get the same result by manually making your Provider instance and calling methods to read variables, template paths and other settings.

Custom controllers in Provider Extensions

Some features of Fluid Powered TYPO3 - such as fluidcontent and fluidpages - support custom controller classes which Flux will use instead of the controllers that ship with each of those features. Naturally this allows much more flexibility (as an example, a custom PageController can accept custom arguments in the action that corresponds to the template that gets rendered). If and when you add custom controller classes the location and naming of these also must follow Extbase conventions.

The fluidcontent extension for example contains a ContentController which has a custom Provider - together, these two classes are capable of detecting which template file to use, which template root path it is located in, which variables editors saved in the Flux form fields - and more.

Which features you wish to use - if any at all - is determined by your end goal, just like when you create an Extbase controller. You may not need all actions, you may not need arguments, you may not need the special View initialisation methods - and so on. The real power of a Flux controller is that it is able to integrate closely with a Provider class, which is where you can (and should) implement things like dynamic template variables, dynamic template paths and more. Your options when using a custom Provider is explained in much more detail in the following chapter about custom Providers.