Feature: #103581 - Automatically transform TCA field values for Record objects¶
See forge#103581
Description¶
With forge#103783 the new Record
object has been introduced. It's 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
Record
(record-
)
or by collecting content elements with the Page
(page-
).
The Records API - introduced together with the Schema API in forge#104002 -
now expands the Records
'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
, Folder
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's 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 Typolink
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 Record
API, e.g. via
Record
(record-
)
or Page
(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.