Templates und Overrides für CMS-Entwickler #

Diese Seite richtet sich an Entwickler, die die Darstellung einer Website bauen. Sie zeigt den ganzen Mechanismus an einer Stelle und verweist für Details auf die Seiten der Designer und des Buchs. Wenn Sie sich nur eines merken: Sie ändern nie ein mitgeliefertes Template; Sie fügen ein eigenes Template hinzu und eine Regel, die sagt, wann es gilt.

Inhalt #

1. Wie eine Seite gezeichnet wird
2. Die Design-Kette
3. Override-Regeln
4. Die Template-Sprache in zehn Zeilen
5. Wo Ihre Templates liegen
6. Das Template hinter einer Seite finden
7. Regeln für wartbare Templates
8. Wo es in die Tiefe geht

Wie eine Seite gezeichnet wird #

Request -> siteaccess -> module/view (content/view/full/61)
   view template: node/view/full.tpl  -> override rule -> full/exp_event.tpl  -> $module_result.content
   pagelayout.tpl wraps it: <html>, header, menus, footer, {$module_result.content}

Jede Seite ist das Ergebnis einer View, gezeichnet von einem View-Template und eingesetzt in das Pagelayout (pagelayout.tpl), das äußere Template des Designs. Das Pagelayout erhält das Ergebnis der View als $module_result mit dem Inhalt, dem Pfad und Angaben zum Knoten (Das Pagelayout, Modulergebnis und Inhaltsinformationen). Seiten, die mit Exponential Layouts gebaut sind, ergänzen dieses Bild um Zonen und Blöcke (Layouts für CMS-Entwickler).

Die Design-Kette #

Ein Template-Pfad wie node/view/line.tpl wird in einer Kette von Designs gesucht: im SiteDesign des Siteaccess, dann in AdditionalSiteDesignList[], dann im Standarddesign, jeweils auch innerhalb jeder aktiven Erweiterung, die einen design/-Ordner dafür hat. Der erste Treffer gewinnt. So setzen sich die Templates Ihrer Design-Erweiterung gegen die mitgelieferten durch, ohne diese anzufassen (Die Design-Kette, Die Design-Kaskade).

Override-Regeln #

Für Inhalte reicht die Kette allein nicht: Ein Artikel und eine Veranstaltung verwenden beide node/view/full.tpl. Override-Regeln in override.ini wählen nach Bedingung eine andere Datei:

[exp_mysite_full_event]
Source=node/view/full.tpl
MatchFile=full/exp_event.tpl
Subdir=templates
Match[class_identifier]=exp_event
Priority=10

Die Match-Schlüssel sind class_identifier, class, node, parent_node, parent_class_identifier, object, remote_id, section, section_identifier, depth, url_alias, viewmode und view_offset; alle Bedingungen einer Regel müssen passen, und die erste passende Regel in der Reihenfolge gewinnt (Override-Grundlagen, Match-Schlüssel für Overrides, Reihenfolge der Overrides). Passen Sie auf Bezeichner, nicht auf numerische IDs, wenn eine Regel in jeder Installation funktionieren muss; remote_id ist der stabile Weg, ein einzelnes Objekt anzusprechen.

Die Template-Sprache in zehn Zeilen #

{* a comment *}
{def $children = fetch( 'content', 'list', hash( 'parent_node_id', $node.node_id, 'limit', 5 ) )}
{if $children|count()}
<ul>
    {foreach $children as $child}
        <li>{node_view_gui content_node=$child view='line'}</li>
    {/foreach}
</ul>
{/if}
{undef $children}
<p>{$node.data_map.intro.content|wash()}</p>

Funktionen stehen in geschweiften Klammern ({if}, {foreach}, {def}, {include}), Operatoren werden mit einem senkrechten Strich angehängt (|wash(), |ezurl, |count()), und Templates haben keinen Zugriff auf PHP: Alles, was sie brauchen, kommt aus Fetch-Funktionen, Operatoren und Variablen. wash maskiert Ausgaben; verwenden Sie es für alles, was Sie ausgeben und was nicht bereits HTML aus einem Datentyp ist (Was die Template-Sprache ist, Template-Operatoren). Wenn Sie Smarty kennen, lesen Sie Smarty im Vergleich.

Wo Ihre Templates liegen #

In Ihrer Design-Erweiterung, nie in design/standard oder einem anderen mitgelieferten Design:

extension/exp_mysite/
  design/exp_mysite/templates/pagelayout.tpl              your pagelayout
  design/exp_mysite/templates/node/view/line.tpl          a default for a view mode
  design/exp_mysite/override/templates/full/exp_event.tpl a template chosen by a rule
  design/exp_mysite/stylesheets/ ... javascript/ ... images/
  settings/design.ini.append.php                          registers the design in the extension
  settings/siteaccess/<public siteaccess>/override.ini.append.php   the rules

Templates enthalten keinen <style>-Block und kein style=""-Attribut; CSS gehört in Stylesheets, die über [StylesheetSettings] geladen werden (Kein Inline-CSS). Die Erweiterung Schritt für Schritt bauen: Ihre eigene Design-Erweiterung.

Das Template hinter einer Seite finden #

In einer Entwicklungsinstallation:

./console exp:ini set site.ini/TemplateSettings/ShowUsedTemplates enabled global --allow-root-user
./console exp:ini set site.ini/TemplateSettings/ShowTemplatePathComments enabled global --allow-root-user
php bin/php/ezcache.php --clear-tag=ini --allow-root-user

Die Debug-Ausgabe listet dann jedes Template, das eine Seite verwendet hat, und die Override-Regel, die es gewählt hat, und der Quelltext der Seite nennt das Template jedes Teils in HTML-Kommentaren (Das Template hinter einer Seite finden, Kommentare mit Template-Pfaden). Die Syntax eines Templates prüfen Sie in der Shell mit ./console exp:eztemplatecheck --help.

Regeln für wartbare Templates #

• Ein Template je Klasse und Ansichtsmodus; gemeinsame Teile in {include}-Dateien.
• Rufen Sie Daten im View-Template ab, nicht im Pagelayout, es sei denn, die Daten sind auf jeder Seite gleich (Menüs), und dann in einem Cache-Block (Caching für CMS-Entwickler).
• Geben Sie nur maskierte Werte oder Ausgaben von Datentypen aus; bauen Sie nie HTML durch Verketten aus Benutzereingaben.
• Verwenden Sie i18n für feste Texte (Übersetzungen und Sprachen).
• Halten Sie Geschäftslogik in Operatoren oder Fetch-Funktionen Ihrer Erweiterung, nicht in langen Template-Bedingungen (Stilrichtlinie für Templates).

Wo es in die Tiefe geht #

Verwandte Seiten #

• Ansichtsmodi
• Inhalte in Templates abrufen
• Templates und Design: die Anleitung für Administratoren
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.