Core API
4.1.3. Main levels in the $TCA array
The table entries (first level)
On the "first level" of the $TCA array you will find key values which matches with database table names:
$TCA['pages'] = Array (
...
);
$TCA['tt_content'] = Array (
...
);
$TCA['tx_myext'] = Array (
...
);
Here three tables, "pages", "tt_content" and "tt_myext" is shown as examples.
The structure of a table entry (second/third level)
Each table is defined by an array which configures how the system handles the table, both for display and processing in the backend (the frontend is mostly independant of the TCA except from some features in the [ctrl] section).
On this "second level" (configuring a single table) the structure is as follows:
$TCA['tablename'] = Array (
'ctrl' => Array(
....
),
'interface' => Array(
....
),
'feInterface' => Array(
....
),
'columns' => Array(
'fieldname_1' => Array(
....
),
'fieldname_2' => Array(
....
),
....
),
'types' => Array(
....
),
'palettes' => Array(
....
),
);
(The bold/italic strings in blacks indicate that here actual table/fieldnames are used as keys)
This table describes each of the sections. Over the next pages you will see each section described in detail with all features.
|
Section |
Description |
|---|---|
|
ctrl |
The table The "ctrl" section contains properties for the table in general. These are basically devided in two main categories;
|
|
interface |
The backend interface handling The "interface" section contains properties related to the tables display in the backend, mostly the Web>List module. |
|
feInterface |
Frontend Editing The "feInterface" section contains properties related to Front End editing of the table, mostly related to the feAdmin_lib. Is depricated in the sense that it will still exist, but will not be (and should not be) extended further. |
|
columns |
The individual fields The "columns" section contains configuration for each table field (also called "column") which can be edited by the backend. The configuration includes both properties for the display in the backend as well as the processing of the submitted data. Each field can be configured as a certain "type" (eg. checkbox, selector, input field, text area, file or db-relation field, user defined etc.) and for each type a separate set of additional properties applies. These properties are clearly explained for each type. |
|
types |
The form layout for editing The "types" section defines how the fields in the table (configured in the "columns" section) should be arranged inside the editing form; in which order, with which "palettes" (see below) and with which possible additional features applied. |
|
palettes |
The palette fields order A palette is just a list of fields which will be arranged horizontally side-by-side. But the main idea is that these fields can be displayed in the top-frame of the backend interface on request so they don't display inside the main form. In this way they are kind of hidden fields which are brought forth either by clicking an icon in the main form or (more usually) when you place the cursor in a form field of the main form). |
Glossary
Before you read on, lets just refresh the meaning of a few concepts mentioned on the next pages:
-
TCE: Short for "TYPO3 Core Engine". Also referred to as "TCEmain". This class (class.t3lib_tcemain) should ideally handle all updates to records made in the backend of TYPO3. The class will handle all the rules which may be applied to each table correctly. It will also handle logging, versioning, history/undo features, copying/moving/deleting etc.
-
"list of": Typically used like "list of fieldnames". Whenever "list of" is used it means a list of strings separated by comma and with NO space between the values.
-
field name: The name of a field from a database table. Another word for the same is "column" but it is used more rarely, however meaning the exact same thing when used.
-
record type: A record can have different types, expressed by the value of a certain field in the record. This field is defined by the [ctrl][type] value and it affects also which fields ("types"-configuration) is used to display possible form fields.
-
(LS): "LanguageSplitted" - meaning that
-
the value can be a plain string which will be splitted by the "|" token where each part corresponds to a language as found in the constant "TYPO3_languages" (obsolete concept! Depricated!)
-
or the string can fetch a value from a locallang file by prefixing the string with "LLL:" (please see the description of [ctrl][title] for details).
-
The [ctrl] section vs. the other sections
In almost the whole system the [ctrl] section of the $TCA entry for a table plays a crucial role. For all tables configured in $TCA this section must exist in $TCA. The other sections (except [feInterface]) can optionally be stored in another file.
This feature allows scalability since hundreds of tables can be configured with their complete [ctrl]-sections while leaving a relatively small memory footprint since they don't define all the other sections by default (eg. the "columns" section can group quite large!). Please see the [ctrl]-property "dynamicConfigFile" and the section "Loading the full $TCA dynamically" for details.
However this means that:
-
You can always depend on accessing information in the [ctrl] section, eg. $TCA['your_table_name']['ctrl']
-
But before you can depend on information in any other section (except [feInterface]) you should:
-
1) Call t3lib_loadTCA('your_table_name'); (This will dynamically load the full content of the TCA section for the table)
-
2) Then access the information, eg. $TCA['your_table_name']['columns']['your_field_name']
-
See more information in the section about handling after the $TCA array reference section.