4.2.2 Creating Providers

In order to define which DB table name and which field name (if any) your Provider should connect with, use the class properties you see in AbstractProvider - named tableName, fieldName and so on. For example, Flux's ContentProvider connects with the tt_content table when the field pi_flexform is involved and when the CType (in the Provider class called contentObjectType) matches fluidcontent_content.

Finally, there is a priority setting which can even further increase or decrese the proirity of your Provider for records in the table it connects with. The default is 50 and can be lowered to make the Provider less important and raised if more important.

In some cases - such as tt_content preview rendering in the page module - the first Provider which renders a preview also is able to stop other Providers from rendering theirs; which means that in particular when your Provider connects with the tt_content table, you must be a bit more careful not to override the priority of fx fluidcontent's ContentProvider - or you could prevent the nested content grids from being displayed.

What should a Provider not contain?

In order to separate concerns of your application, your Provider's main responsibility should be to delegate to other methods. For example, a Provider could...

• Inject Services from your application which manipulates records.
• Use the ConfigurationManager to insert TypoScript in template variables from multiple locations.
• Dynamically remove and change template variables before they reach the Controller.
• Dynamically change the template paths your Flux-enabled controller should use.
• Switch the template file your Controller renders, based on values in the record it renders.
• Return a custom FluidTYPO3\Flux\Form instance built directly in PHP.
• Configure some (not all!) aspects of the controller context - the extension key, the $this->settings storage, and more.

But it should not...

• Contain larger pieces of business logic, for example to manipulate records in complicated ways.
• Use specialised methods which only work in backend or frontend.

Utilising the Provider features

To have your Provider's methods called in the appropriate places simply register your Provider - Flux takes care of the rest for you. Override as many of the methods as you need in order to make your Provider perform the task it should, in just the right way. Before you override a method you should first check the original method - in many cases method on the Provider will call other methods on the same class frequently (for example, getTemplateVariables is called from many places but getGrid is only called from the outside). Finding the right method to override and making sure your modifications perform well should be your main priorities. A great place to study how custom Providers should override methods is in the ContentProvider of flux and the PageProvider of fluidpages. Each of these override a different selection of methods on the Provider base class to get two quite different results.