Skip to content

Templates und Template Engines

HTML und CSS, Frameworks wie Bootstrap, Web- und Iconfonts, LESS oder SASS bieten viele Möglichkeiten zur Gestaltung standardkonformer, gut lesbarer und auf verschiedenen Endgeräten nett anzusehender Webseiten. Eine größere Webpräsenz komplett “von Hand” zu pflegen macht allerdings wenig Spaß - und ist auch alles andere als professionell oder eine gute Idee.

Denn regelmäßig ist eine Website oder auch eine Webapplikation gekennzeichnet durch ein “Grundkorsett”, das mit wechselnden Inhalten gefüllt wird. So wird sich meist ein einheitliches Gestaltungskonzept mit Kopf- und/oder Fußzeile, mit einer oder mehreren Spalten und einer Navigation auf allen Seiten wiederfinden. Dieses Grundgerüst der ganzen Webpräsenz sollte sich dann nicht per copy & paste auf jeder Einzelseite wiederholen, sondern vielmehr in Form einer Vorlage, eines Templates, vorliegen, um dann jeweils mit spezifischen Inhalten gefüllt zu werden. Auch ist es - gerade bei Webapplikationen - sinnvoll, die “Technik” von der “Darstellung” zu trennen, damit Änderungen am Design nicht zwingend Änderungen an der Programmierung erfordern und umgekehrt. (Und, natürlich, damit verschiedene Teams an der optischen Darstellung der Seiten und der dahinterstehenden Programmlogik arbeiten können).

Auf diese Art und Weise arbeiten bspw. Blogsysteme wie Wordpress (mit eigenen Template-Funktionen) oder Serendipity (wo das Template-System Smarty genutzt wird) und natürlich auch Content Management Systeme (CMS) oder static site generators.

Das Prinzip ist immer gleich: ein Grundgerüst und mögliche Inhalte werden getrennt definiert, wobei das Grundgerüst oft aus einer HTML-Datei besteht. In dieser (HTML-) Datei können Platzhalter (Variablen) durch passenden Text ersetzt und andere Dateien eingebunden werden, Codefragmente (in einer Programmiersprache wie Perl, PHP, Python oder Ruby und/oder in einer speziellen Template-Sprache) eingebaut und/oder sogar statt HTML andere Auszeichnungssprachen verwendet werden. Das kann “dynamisch” bei jedem Aufruf der Seite erfolgen, ggf. mit Caching, oder die Webseiten können einmal aus ihren Quelltexten generiert werden und dann “statisch” online gestellt - und nur bei Änderungen aktualisiert - werden.

Einbindung von Script-/Programmiersprachen in HTML-Dokumente

PHP ist an und für sich - und ganz ursprünglich - selbst eine Template Engine. In eine HTML-Datei werden PHP-Fragmente eingebunden und die Webseite auf diese Weise dynamisiert. In ähnlicher Weise funktionieren eRuby (das Ruby einbindet), Active Server Pages (ASP) oder Java Server Pages (JSP).

Die Einbindung kompletter Scriptsprachen in Webdokumente führt zwar einerseits zu einem großen Funktionsumfang, ist aber andererseits nicht immer bequem, weil oft komplex, und zudem auch nicht sicher - eben wegen des Funktionsumfangs: wer eine PHP-Datei auf einen Server hochladen kann, darf faktisch dort Programme ausführen.

Spezialisierte Template Engines

Systeme wie Smarty enthalten hingegen eine eigene, abgespeckte “Sprache”, die einerseits nicht unmittelbar die Ausführung beliebigen Codes erlaubt und - vor allem - andererseits speziell auf die Aufgabe, eine Vorlage mit individuellen Inhalten zu füllen, zugeschnitten ist.

Solche Template Engines können unter verschiedenen Sprachen ausgeführt werden; Smarty erfordert bspw. PHP. Ein anderes Beispiel, das unter einer Vielzahl von Sprachen ausgeführt werden kann, wäre mustache. Die dort gebotenen Möglichkeiten sind allerdings nicht ganz so vielseitig.

Template Engines und Markup Languages

Setzen die vorgenannten Beispiele in der Regel auf ein HTML-Dokument, also eine konventionelle Webseite, auf, und ergänzen das HTML mit zusätzlicher Funktionalität - Variablen, Funktionen, Datenbankanbindung usw. -, gibt es auch Template Engines, die eine eigene Auszeichnungssprache mitbringen und auf diese Art und Weise die Vorteile eines Templates mit einer vereinfachten Auszeichnungssprache wie Markdown oder Textile verbinden.

Eines dieser Systeme ist HAML. HAML-Templates bestehen nicht aus HTML, sondern einer vereinfachten Variante, die v.a. ohne schließende Tags auskommt und zudem die logische Struktur des Dokuments durch Einrückungen abbildet. Das hat - neben eingesparter Schreibarbeit - den charmanten Vorteil, dass das Problem “vergessener” schließender Tags der Vergangenheit angehört. Darüber hinaus bietet HAML zum einen die Möglichkeit des Einbindens von Ruby-Code (ersetzt insoweit also eRuby) und zum anderen den Einsatz von Filtern, so dass bspw. Markdown oder Textile in HAML-Templates eingebaut werden können. Letzteres ist schon deshalb wichtig, weil das Verfassen längerer Texte in HAML durch die Notwendigkeit, für jedes neue Tag einen neuen eingerückten Abschnitt zu beginnen, doch ziemlich umständlich ist.

Nach dieser komplizierten Erläuterung ein Beispiel für HAML in der Praxis. Der folgende kurze HTML-Schnipsel:

<section class="container">
  <h1>Ein neues Kapitel</h1>
  <div class="content">
    <p>
      Hier könnte jetzt ein längerer Text stehen,
      der sich über viele Zeilen erstreckt!
    </p>
  </div>
</section>

würde in HAML folgendermaßen aussehen:

%section.container
  %h1 Ein neues Kapitel
  .content
    %p
      Hier könnte jetzt ein längerer Text stehen,
      der sich über viele Zeilen erstreckt!

Sollte der “längere Text” weitere Tags enthalten, wird das in HAML allerdings eher umständlich:

<p>Hier könnte jetzt ein <strong>längerer</strong> Text stehen,
  der sich über <em>viele</em> Zeilen erstreckt!</p>

wird zu:

%p
  Hier könnte jetzt ein
  %strong längerer
  Text stehen,
  der sich über
  %em viele
  Zeilen erstreckt!

Daher kann man stattdessen - innerhalb von HAML - Markdown (oder auch Textile) verwenden und direkt auch (via eRuby) variable Elemente einbinden:

= render 'header'
%section.container
  %h1= chapter.title
  .content
    :markdown
      Hier könnte jetzt ein **längerer** Text stehen,
      der sich über *viele* Zeilen erstreckt!
= render 'footer'

Schick, nicht wahr?

Template Engines im Vergleich

Die Anzahl der verfügbaren Template Engines ist ähnlich unüberschaubar wie das bei CMS oder static site generators der Fall ist. Die englischsprachige Wikipedia bietet immerhin eine Vergleichstabelle für einen ersten Überblick an.

Dieser Beitrag gehört zur Reihe “Webdesign anno 2015”.

Trackbacks

Netz - Rettung - Recht am : Markup mit HAML

Vorschau anzeigen
Websites bestehen - hoffentlich - in der Regel aus (wenigen) Templates, die dann mit (vielen verschiedenen) Inhalten gefüllt werden. So arbeiten Blogs und CMS, so arbeitet auch ein static site generator. Die Templates können dabei HTML-Dateien sein - müss

Netz - Rettung - Recht am : Naives MVC

Vorschau anzeigen
Seit 2014 setze ich sowohl bei neuen Websites als auch bei der “Renovierung” alter auf static site generators, also Generatoren für statische Webseiten, die aus Templates und Inhalten in verschiedenen Markups, aus Helper-Klassen und ggf. auch

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen