For now, default properties for a type are declared in a static protected property ($propertyNames) in the according model class (e.g. Person). For additional properties (from sections, like autos or bib, or from custom extensions) a PSR-14 event is available. At runtime, the PSR-14 events are dispatched if no cache entry for this type is available.
This has some drawbacks:
The very first call after flushing the cache has to build up the cache for the according properties for the necessary types.
An exhaustive list of properties for a type is only available in the instantiated class.
The advantages with this approach are:
Improved loading speed of initial request. The properties for the types are cached when warming up the caches.
The type model class is then just a wrapper for the API and the view helpers with no additional code.
The properties for a type can be accessed independently from the instantiated class. For example, the types can be displayed in the Configuration module together with the registered properties, which is not possible by now.
The disadvantages are:
The types and default properties may be separated from each other (when using the approach below, see example). Maybe this can be solved with annotations/attributes in the class or with reflection.
Attention must be paid to a smooth migration from custom additions. The PSR-14 event and the new registration must live together some time. The PSR-14 event can then be deprecated and removed in version 3.
A possible solution may be to use the already existing Configuration/TxSchema folder to register additional properties, for example:
where Person is the type (derived from the file name) and the returned array values jobTitle and gender are the additional properties.
The installed extensions are then scanned for the folder Configuration/TxSchema/AdditionalProperties and the found properties for available types are added to the default properties for that type and cached. The registration of new types is working this way already. These can then also registered via a service container.
For now, default properties for a type are declared in a static protected property (
$propertyNames
) in the according model class (e.g.Person
). For additional properties (from sections, like autos or bib, or from custom extensions) a PSR-14 event is available. At runtime, the PSR-14 events are dispatched if no cache entry for this type is available.This has some drawbacks:
The advantages with this approach are:
The disadvantages are:
A possible solution may be to use the already existing
Configuration/TxSchema
folder to register additional properties, for example:File name:
Configuration/TxSchema/AdditionalProperties/Person.php
Content:where
Person
is the type (derived from the file name) and the returned array valuesjobTitle
andgender
are the additional properties.The installed extensions are then scanned for the folder
Configuration/TxSchema/AdditionalProperties
and the found properties for available types are added to the default properties for that type and cached. The registration of new types is working this way already. These can then also registered via a service container.With TYPO3 v12 the CacheManager is not available anymore at build time. A workaround was introduced to circumvent this problem in v12: https://github.com/brotkrueml/schema/commit/7b92e4402a272b69a4877fb09255fc43073afa48. When registering types on build time this can be streamlined and the cache avoided.