Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

TCEformsRecommendedLayout

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Core Team (category Core Team)

TCEforms Recommended Layout since TYPO3 4.5

Having a complex table which can be edited in the backend requires a complex $TCA setup. This array defines how TCEforms will render the form to edit a record of that table. The possibilities of the TCA are described in the TYPO3 Core API documentation.

This additional documentation describes rules on how fields should best be arranged to allow a consistent interface for the users. Since TYPO3 4.5 the layout of the tables "Pages" and "Content elements" have been rearranged to meet these guidelines, so they can be used as a example on how to apply them.

Terms and explanations

  • Fields can be grouped in tabs. Only one tab is displayed at a given time, and the user can switch from one tab to another with a click.
  • A palette is a group of fields. A palette might be tied to a "main field" (the palette is then called "secondary options") or just have a title. Fields in a palette are usually rendered side-by-site, but might also contain line breaks (--linebreak--).

Guidelines

Limit rules

  1. A maximum of 7 tabs should not be exceeded
  2. A maximum of 4 element groups (palettes) per tab should not be exceeded
  3. A maximum of 3 rows within each palette should not be exceeded while floated at a default screen size
  4. Whenever possible, scrollbars should be avoided

The goal: Get rid of secondary options by using strong defaults.

Ordering rules

  1. Tabs will be arranged according to their importance for the daily work.
  2. The more likely it is that the average user wants to edit a field the closer it should be to the first tab.
  3. First tab (called "General") should contain the main fields of a record
  4. There are fields which might affect the layout in frontend rendering of a record (like "Layout", "Spacing", ...) and others which affect the functionality of a record in the frontend. If it makes sense, separate these two in different tabs: Appearance and Behaviour

Label rules

  1. Labels of groups should always be separate from the field labels
  2. Field labels should not be abused as group labels
  3. Labels should always contain precise wording that can easily be understood even by non-geeks

Other notes

  1. Use adjectives like "Enabled" / "Disabled" in forms (describing the state of a checkbox) and verbs like "Enable" / "Disable" in context menus and action buttons.
  2. Title Case:
    1. Use "Title Case" ([1]) for palette titles and short labels (capitalizing all important words except closed-class words, i.e. "be", "the", "this", etc). Example: "Enlarge on Click"
    2. Use regular case for longer explanations which might be part of the label (for example extra text in parenthesis). Example: "Links (one per line, one link per image)"
    3. This rule only applies on English. Use the normal grammatical rules when translating these text to other languages.
  3. Do not include a colon ":" after labels in forms

Implementation tips

Use palettes to group a set of fields with a common title. Use a setup like this to achieve that:

PHP script:
$GLOBALS['TCA']['<table>']['palettes']['<paletteName>']['showitem'] = '<field list to be shown.. use --linebreak-- to split lines>';
$GLOBALS['TCA']['<table>']['palettes']['<paletteName>']['canNotCollapse'] = true;
$GLOBALS['TCA']['<table>']['types']['<type>']['showitem'] = '--palette--;<paletteTitle>;<paletteName>;