Template engine, doen of niet doen?

Waarom zou je geen dingen kunnen gebruiken die in simpel PHP niet kan? Kan dit niet gewoon met view helpers?

De designer beperken, kan ik me in vinden op zich. Ik vindt de syntax niet makkelijk en al helemaal niet op JS lijken? althans niet die van Twig? Dus wat betreft de leercurve omlaag brengen ben ik niet helemaal met je eens.

>> Ik vindt de syntax niet makkelijk en al helemaal niet op JS lijken? althans niet die van Twig?
Voorbeeldjes:

Twig	for post in posts
JS	  for( post in posts )

Twig	post.title of post['title']
JS	  post.title of post['title']

Twig	set foo = [1,5,6]
JS	  var foo = [1,5,6]

Twig	set foo = {'foo' : 'bar', 'bar' : 'lorem'}
JS	  var foo = {foo : 'bar', bar : 'lorem'}

>> Waarom zou je geen dingen kunnen gebruiken die in simpel PHP niet kan? Kan dit niet gewoon met view helpers?
Probeer jij maar eens het exclude systeem met blocks na te bouwen in simpele PHP, zodat elke designer het kan. En dan ook nog met default waardes, ik denk niet dat het heel erg makkelijk gaat worden...

He Wouter,

Wat betreft het 'lijken' op JS doelde ik vooral op de % tekens in je bovenste voorbeeld. In dit voorbeeld lijkt het inderdaad al veel meer.

Wat betreft je laatste opmerking, ik heb zeg ook; dat ik geen reden zie om een template systeem te gebruiken als je niet met designers werkt (dan vindt ik het nog wel enigzins discutabel) dus ik denk dat we dat betreft het wel met elkaar eens zijn hoor!

Wat bedoel je met het exclude systeem? Ik denk dat je met die bewering wel uit gaat van het niet gebruiken van een degelijk framework want daar kun je hetzelfde mee als helpers in een template systeem.

Ik heb inderdaad niet heel veel ervaring met een framework. Ooit eens heel even CodeIgnitor en Zend geproefd, vond Zend een beetje basaal en onpersoonlijk overkomen ik had niet echt het gevoel dat ik wist wat er achter de functies zich af speelde en CI waren jullie niet heel positief over. En natuurlijk Rails waar ik me mee bezig heb gehouden, die heeft wel view helpers.
Nu ben ik een tijdje Symfony aan het uitproberen, en die heeft Twig. Dus je kan inderdaad niet zeggen dat ik veel ervaring heb met view helpers. Maar het lijkt mij dat zo'n exclude systeem, waarbij je 1 file in het andere laad en doormiddel van blocks duidelijk maakt waar de content komt, niet in een begrijpelijke syntax voor beginners te maken is.

Twig heeft inderdaad andere open en sluit tekens:

{{ someVar }} // {{ is hetzelfde als <?=someVar?>
{% %} // staat alle logische dingen in, dus for loops enzo, te vergelijken met <?php ?>
{# #} // een comment in Twig, zelfde als <?php # ?>

Maar als je die weg denkt lijkt het erg op JS.

Zonder een heel verhaal te typen over wel of geen template parser, moet we ons niet afvragen of een designer zich überhaupt aan de code moet wagen? Moeten ze niet bezig zijn met de dingen waar ze goed in zijn? (juist designen) Als applicatie ontwikkelaar design ik toch ook niet?

Of bedoelen jullie een frontend webdeveloper ? Ik zie een traject zo voor mij: (overleg met klant en dergelijke even weggelaten)

- Realisatie design (dit doet een designer)
- Templaten van het design (dit doet een fontend webdeveloper)
- Implementeren van de functionaliteiten (dit doet een backend webdeveloper / applicatie ontwikkelaar)

Om die reden gebruik ik dus geen Template parser. Maar zoals Mark zegt moet je daar wel discipline voor hebben. Tja, het leven van een programmeur gaat natuurlijk niet over rozen ;-)

Ik gebruik zelf wel een template taal (Twig), maar werk samen met een andere developer aan één product. Toch heb ik ervoor gekozen om templates te gebruiken terwijl ik hier vroeger niet voor was. Hier heb ik twee belangrijke redenen voor:
- Template inheritence
- Auto escaping

Beide niet eenvoudig na te bootsen met PHP templates icm view helpers. Met name kwa efficientie na het kopieëren niet.

=== Template inheritence ===
Dit is over komen waaien uit het Object Georienteerd programmeren en als eerste geimplementeerd in het Python framework Django (daar is Twig ook weer op gebaseerd). Het is hier mogelijk om blocks in een template te definieren. Vervolgens kan je deze template overerven vanuit een andere template en de blocks overschrijven. Het idee is simpel, maar wel enorm krachtig. Zo hoeven mijn actions binnen het framework namelijk niets meer af te weten van een layout of een base template.

Voorbeeldje:

<html>
 <head>
  <title>{% block title %}{% endblock %}</title>
  {% block css %}
   <link rel="stylesheet" type="text/css" href="css/design.css" />
  {% endblock %}
 </head>
 <body>
  <ul id="menu">
   <li>Home</li>
  </ul>
  <div id="content">
   {% block content %}{% endblock %}
  </div>
  {% block js %}
   <script type="text/javascript" src="js/jquery.js"></script>
  {% endblock %}
 </body>
</html>

Vervolgens kan ik vanuit een andere template delen overschrijven:

{% extends "base.html" %}

{% block title %}Andere titel{% endblock %}

{% block css %}
 {{ parents() }}
 <link rel="stylesheet" type="text/css" href="css/specifieke_pagina.css" />
{% endblock %}

{% block content %}
<!-- pagina content -->
{% endblock %}

<!-- Geen javascript toe te voegen, dus dat block overschrijf ik niet -->

In mijn action zal ik alleen die tweede template aanroepen en die template bepaalt vervolgens zelf weer welke template er geladen moet worden.

=== Auto escpaping ===

Alle waarden die ik in Twig weergeef worden automatisch geescaped mits niet anders aangegeven:

{{ title }} <!-- Geescaped -->
{{ title|raw }} <!-- Niet geescaped -->

Bij het compilen wordt vervolgens netjes naar PHP omgezet op de manier zoals je zou verwachten. Bij een PHP template kan je auto escaping wel instellen, maar dan is het weer heel lastig om het te omzeilen of je krijgt overal $this->escape($var) in je template.

Het inschakelen van short_tags is verder ten strengste af te raden. Dit levert namelijk problemen op zodra je met XML files gaat werken. Vanaf PHP 5.4 is er wel een optie om alleen de <?= notatie in te schakelen.

=== Framework gebruiken == geen templates ===

Ik ben het niet eens met het statement dat een framework gebruiken direct het gebruik van templates overbodig maakt. Het is niet voor niets dat elk framework in PHP gebruik maakt van templates. Hetzij PHP templates, hetzij een andere template parser. Het framework zorgt ervoor dat je verdere code op een standaard manier gestructureerd is zodat het voor derden die ook het framework kennen eenvoudiger aan te passen is. Daarnaast zal het je wat tijdwinst opleveren met ontwikkelen op het moment dat je het framework onder de knie hebt. De learning curve van de verschillende frameworks is namelijk behoorlijk stijl.

Een goed voorbeeld van het combineren van een framework met een template parser is Symfony 2 waar tegenwoordig standaard Twig gebruikt wordt :)

Edit:
Je zit hier PHPHulp al hoe die mis gaat!!! Ik gebruik een shorttag en er wordt direct vanuit gegaan dat ik een code block wil starten

@Mark, als je dit doet: <[b][/b]?= zal het hier niet op PHP hulp als codeblock gezien worden.
Verder een erg goed en duidelijk verhaal!

@Mark, dat in Symfony Twig wordt gebruikt is niet heel verbazingwekkend. Het is allebei namelijk van de zelfde maker/bedrijf... Wel een goed framework trouwens.

@Mark,

Wat betreft auto escaping, in Zend Framework 2 zit dit standaard (zonder template engine) en in Zend Framework 1 kun je dit zeer eenvoudig zelf maken door gebruik te maken van Stream wrappers. In mijn eigen uitbreiding op ZF zit het al. (Pike_View_Stream).

En Zend Framework implementeert standaard geen template taal in ieder geval. Daar wordt dus standaard geen template engine gebruikt.

@iedereen, bedankt voor de enorme hoeveelheid inzichten en meningen, Mark, jij weet je verhaal erg goed te onderbouwen en ondanks dat ik eerst niet geneigd was om Twig te gebruiken heb je me toch weten te overtuigen.

Template talen zijn (bij voorkeur) onnodig, maar ik zie hier op dit moment de voordelen wel van in. Een designer moet er ook goed mee overweg kunnen. Ik kan ze wel een basis in PHP gaan geven maar dingen als escaping (niet eens bij stil gestaan..) doen me de das om. Een template taal levert toch meer voordelen op als het gaat om de scheiding tussen logica en presentatie en dat is denk ik het belangrijkste dat je hier mee wint.

Over de view_helpers, ik heb me er voor deze discussie nooit in verdiept en het idee lokt me ook wel maar in de basis doet het precies hetzelfde als wat elke template taal doet, wat een template taal als extra "functionaliteit" heeft is een scheiding tussen eerdergenoemde logica en presentatie.

Zoals het er nu naar uit ziet ga ik wel een template taal gebruiken, welke waarschijnlijk Twig wordt:

1. Twig
2. RainTPL

Twig heeft de extra voordelen van inheritance, wat waarschijnlijk erg lastig uit te leggen valt aan designers, maar functionaliteit die wel verdomd handig is. De syntax vind ik in beide gevallen wel netjes al zal het natuurlijk eigen voorkeur zijn.

Iedereen bedankt voor de berichten en als ik een keuze heb gemaakt, zal ik het laten weten.

@Merijn,
Wat schort er precies aan mijn ongenuanceerde mening? De compile tijd van de template engines doet er niet toe, alleen de tijd die nodig is om gecompileerde templates te renderen en aangezien dat gewoon plain PHP is kan de pagina worden weergegeven met een minimale overhead (template zoeken, cache valideren), die in het niet valt bij 1 enkele DB query.
En dat het lastig op te zetten is? Al eens naar Doctrine, Symfony2 of een LAMP stack gekeken?

@kees
Hoe wordt die auto-escaping dan in plain PHP geïmplementeerd? Gewoon Controller#get($var, $raw = false); ?
En hoe heb je het zelf gedaan? fread('input://var') ? Lijkt me niet echt de mooiste optie, toch?