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:
category
file
folder
group
inline
select
withMM
andforeign_
table
In addition, the values of following TCA types are also resolved and expanded automatically:
datetime
flex
json
link
select
with 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.