Deprecation: #100670 - DI-aware FormEngine nodes¶
See forge#100670
Description¶
When the FormEngine construct (used when editing records in the backend) has been rewritten back in TYPO3 v7, dependency injection for non-Extbase constructs has not been a thing, yet.
With dependency injection being part of the TYPO3 Core extension since TYPO3 v10, and the Extbase solution being out-phased, it is time to make FormEngine dependency injection aware as well.
This has some impact on classes implementing
\TYPO3\CMS\Backend\Form\NodeInterface
directly, or indirectly by
extending \TYPO3\CMS\Backend\Form\AbstractNode
and
\TYPO3\CMS\Backend\Form\Element\AbstractFormElement
. Custom
implementations can use this already, but the full power will
only be leveraged with TYPO3 v13.
Similar changes as described below can be done for classes implementing
\TYPO3\CMS\Backend\Form\NodeResolverInterface
as well, but the
impact is much smaller since this construct is used less often in the wild.
Additionally, classes should either implement one of the interfaces
directly, or extend an appropriate abstract. They must not extend any
of the existing "leaf" classes the core provides, since those will be
declared final
with TYPO3 v13.
Impact¶
Using dependency injection within FormEngine related classes becomes possible in TYPO3 v12.
Affected installations¶
Instances with extensions that come with own FormEngine additions may be affected. The extensions scanner is not configured to find affected classes.
Migration¶
Compatibility with TYPO3 v11 and v12¶
Extensions that strive for both TYPO3 v11 and v12 compatibility should just keep their implementation as is.
Compatibility with TYPO3 v12 and v13¶
Extensions that strive for TYPO3 v12 compatibility, skipping v11, that want to support v13 as well, must adapt their implementations.
As main change, NodeInterface
no longer declares __construct()
,
the class constructor is now "free" for injection. The NodeFactory
uses
the existence of method setData()
as indicator if NodeFactory
and
$data
array should be hand over as manual constructor argument (old way),
or if setData()
should be called after object instantiation. Note
setData()
will be activated as interface method with TYPO3 v13.
A class with both TYPO3 v12 and v13 compatibility should look like this:
public function __construct(
// If the class creates sub elements
NodeFactory $nodeFactory,
// If the class needs IconFactory
IconFactory $iconFactory,
// Further dependencies
private readonly MyService $myService,
) {
$this->nodeFactory = $nodeFactory;
$this->iconFactory = $iconFactory;
}
public function setData(array $data): void
{
$this->data = $data;
}
public function render(): array
{
// Implement render(), note the "array" return type hint,
// which will be mandatory in TYPO3 v13.
}
The class has to be registered for public DI in Services.yaml
as well, since
it is instantiated by NodeFactory
using GeneralUtility::makeInstance()
:
MyVendor\MyExtension\Form\Element\MyElementClass:
public: true
Compatibility with v13¶
Extensions dropping TYPO3 v12 compatibility and going with v13 and up, can
simplify the construct: In v13, setData()
will be added to AbstractNode
,
extending classes don't need to implement it anymore. The class
property $iconFactory
(AbstractFormElement
only) will be removed from the abstracts, constructor property promotion
can be used. NodeFactory
will be injected in the abstracts, without
polluting __construct()
. Also, a dependency injection service provider pass will
be added, to automatically set classes public that implement implement NodeInterface
,
so a public: true
entry in Services.yaml
can be skipped.
A typical class extending AbstractNode
looks like this:
public function __construct(
private readonly IconFactory $iconFactory,
private readonly MyService $myService,
) {
}
// Implement render().