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
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
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\Forminstance built directly in PHP.
- Configure some (not all!) aspects of the controller context - the extension key, the
$this->settingsstorage, 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
fluidpages. Each of these override a different selection of methods on the Provider base class to get two quite