While the ctrl and columns section deal with general handling and specific handling of the table and it's fields, the “types” and “palettes” section is basically concerned with the presentation on-screen.
In essense the “types” section lists the fieldnames in the order they should be shown in the form. The field list is separated by comma. Each entry in the list is furthermore exploded by a semi-colon. The first part is the field name , the second part an alternative label for the field (if any), the third part is a reference to a palette to invoke with the field and the forth part is used for special configuration (primarily used with the TEXT field type, eg. to invoke the Rich Text Editor or turning of wrapping in the textarea field).
Consider this configuration:
.....
"types" => Array ( "0" => Array("showitem" => "title;;1,photodate,description,images,fe_cruser_id") ), "palettes" => Array ( "1" => Array("showitem" => "hidden") ));?>... and compare it with the display in the backend below.
When you're looking at these screenshots notice how the configuration of the title-field invokes the display of the palette number 1, which will in turn display the list of fields configured there - in this case only one field, the “hidden” field.
In the Alternative Backend (and wherever the class t3lib_tceforms.php is used to render editing fields) the palette fields needs to be shown together with the masterfield. However in the Classic backend, Doc-module, the whole palette principle is related to form fields found on layers in a specific frame. This concept was invented to save space and make forms less confusing - which it does very well. However it tends to hide the options from people, because you have to place the cursor in the formfield in order to invoke the palette. And finally this concept relies heavily on JavaScript and layers which makes it quite vulnerable to browser behaviours and bugs - in addition to the requirement of the whole database structure being loaded into JavaScript memory when the interface is first started - which quickly amounts to several hundreds kilobytes of JavaScript - which again pushes the client computer on it's resources.
Notice the order from top and down is the same as set by the field name list defined in the “types” section!
Looking at the traditional forms in the Classic backend, Doc-module it looks very similar:
So far I haven't commented the “types” configuration for more than a single, default entry. However the concept of using the “types” section to order the way fields are displayed also allows us to choose various displays depending on the value of a certain field!
Consider this code listing, taken from the sys_action table in Typo3:
<?php// ******************************************************************// sys_action// ******************************************************************$TCA["sys_action"] = Array ( "ctrl" => Array ( "label" => "title", "tstamp" => "tstamp", "default_sortby" => "ORDER BY title", "title" => "Action", "crdate" => "crdate", "cruser_id" => "cruser_id", "adminOnly" => 1, "rootLevel" => 1, "enablecolumns" => Array ( "disabled" => "hidden" ), "type" => "type" ), "interface" => Array ( "showRecordFieldList" => "hidden,title,type,description,assign_to_groups" ), "columns" => Array ( // ..... (more field are configured) "type" => Array ( "label" => $LANG_GENERAL_LABELS["type"], "config" => Array ( "type" => "select", "items" => Array ( Array("", "0"), Array("Create Backend User", "1"), Array("SQL-query", "2") ) ) ), // ..... (more field are configured) ), "types" => Array ( "0" => Array("showitem" => "hidden,title,type"), "1" => Array("showitem" => "hidden,title,type,description,assign_to_groups,--div--, ..."), "2" => Array("showitem" => "hidden,title,type,description,assign_to_groups,--div--,") ));?>In the “ctrl” section we define the “type” key to the value “type” which in turn points to the fieldname “type” as being the fieldname determining the “type” of display (oh boy, al those types...). It works like this:
If the value of the field sys_action.type is “0” (zero), then the “hidden,title,type” fields are displayed:
Changing the “Type” selector to “Create Backend User” the form is rendered differently:
... and finally the “SQL-query” option will show us this form:
This is basically the options.
You can attach the Rich Text Editor component in Typo3 to any field of the TEXT type. The configuration is best shown by looking at how the sys_staticfile_edit table is configured:
"types" => Array ( "0" => Array("showitem" => " edit_file;;1, edit_content;;;nowrap:richtext[*]:rte_transform[flag=rte_enabled|mode=ts_images], rte_enabled, update_status" ) ), "palettes" => Array ( "1" => Array("showitem" => "edit_subpart_marker,always_reload") ));In particular the existence of “richtext[*]” is important and the main parameter in charge of invoking the editor. In addition the RTE can be configured to process the output in various ways including configuration of the toolbar. This is a topic covered in “Inside Typo3” and the Administrators Guide.
The result of this configuration looks like this:
