Feature: #103581 - Automatically transform TCA field values for record objects
See forge#103581
Description
With forge#103783 the new
\TYPO3\ object has been
introduced. It is an
object representing a raw database record, based on TCA and is usually used in
the frontend (via Fluid Templates), when fetching records with the
RecordTransformationProcessor
(
record-) or by collecting content elements with the
PageContentFetchingProcessor
(
page-).
The Records API - introduced together with the Schema API in forge#104002 -
now expands the record's values for most common field types (known
from the TCA Schema) from their raw database value into "rich-flavored" values,
which might be
Record ,
File,
\TYPO3\ or
\Date objects.
This works for the following "relation" TCA types:
categoryfilefoldergroupinlineselectwithMMandforeign_table
In addition, the values of following TCA types are also resolved and expanded automatically:
datetimeflexjsonlinkselectwith a static list of entries
Each of the fields receives a full-fledged resolved value, based on the field configuration from TCA.
In case of relations (
category,
group,
inline,
select with
MM and
foreign_), a collection
(
Lazy) of new
Record objects is attached as
value. In case of
file, a collection (
Lazy)
of
File objects and in case of type
folder, a collection
(
Lazy) of
Folder objects are attached.
Note
The relations are only resolved once they are accessed - also known as "lazy loading". This allows for recursion and circular dependencies to be managed automatically. It is therefore also possible that the collection is actually empty.
Example
<f:for each="{myContent.main.records}" as="record">
<f:for each="{record.image}" as="image">
<f:image image="{image}" />
</f:for>
</f:for>
New TCA option relationship
In order to define cardinality on TCA level, the option
relationship is
introduced for all "relation" TCA types listed above. If this option is set to
one or
many, then relations are resolved directly
without being wrapped into collection objects. In case the relation can
not be resolved,
NULL is returned.
'image' => [
'config' => [
'type' => 'file',
'relationship' => 'manyToOne',
]
]
<f:for each="{myContent.main.records}" as="record">
<f:image image="{record.image}" />
</f:for>
Note
The TCA option
maxitems does not influence this behavior. This means
it is possible to have a
one relation with maximum one value
allowed. This way, overrides of this value will not break functionality.
Field expansion
For TCA type
flex, the corresponding FlexForm is resolved and therefore
all values within this FlexForm are processed and expanded as well.
Fields of TCA type
datetime will be transformed into a full
\Date object.
Fields of TCA type
json will provide the decoded JSON value.
Fields of TCA type
link will provide the
\TYPO3\ object,
which is an object oriented representation of the corresponding TypoLink
parameter configuration.
Fields of TCA type
select without a
relationship will always provide
an array of static values.
Note
TYPO3 tries to automatically resolve the
relationship for type
select fields, which use
render and
having a
foreign_ set. This means, in case no
relationship has been defined yet, it is set to either
many
as the default or
many for fields with option
MM.
Impact
When using
Record objects through the
\TYPO3\ API, e.g. via
RecordTransformationProcessor
(
record-) or
PageContentFetchingProcessor
(page-), the corresponding
Record
objects are now automatically processed and enriched.
Those can not only be used in the frontend but also for Backend Previews in the page module. This is possible by configuring a Fluid Template via Page TSconfig to be used for the page preview rendering:
mod.web_layout.tt_content.preview {
textmedia = EXT:site/Resources/Private/Templates/Preview/Textmedia.html
}
In such template the newly available variable
{record} can be used to
access the resolved field values. It is advised to migrate existing preview
templates to this new object, as the former values will probably vanish in the
next major version.
By utilizing the new API for fetching records and content elements, the need
for further data processors, e.g.
Files (
files),
becomes superfluous since all relations are resolved automatically when
requested.