[php] Templates, content en logica

[T-MOB]

De aanleiding voor dit topic is dat bezig ben met een site in PHP. Hierin wil ik in principe zo flexibel mogelijk zijn in het presenteren van mijn content. De site moet op basis van een gebruikersinstelling iig radicaler kunnen veranderen dan een stylesheet switch. Daarmee kom je al snel uit op een template systeem. Een eerste versie van dat systeem is inmiddels werkzaam, er blijven echter een aantal fundamentele vragen over waarover ik graag jullie mening zou hebben.

1. Op dit moment gaan we voor de stricte scheiding tussen content en logica. In een template kunnen slechts variabelen (al dan niet in een loop) ge-echoed worden. In sommige gevallen zou je echter alleen output willen geven als er daadwerkelijk gegevens zijn. Bijvoorbeeld een menu met submenu items... neem een menu met 2 lagen:

HTML:

<ul id="menu">
 <li><a href="foo.html">hoofditem1</a>
  <ul class="submenu">
   <li><a href="foo1.html">subitem1</a></li>
   <li><a href="foo2.html">subitem2</a></li>
  </ul>
  </li>
 <li><a href="bar.html">hoofditem2</a></li>
</ul>

Het eerste hoofditem heeft een aantal subitems, het tweede item niet. Als ik dit in een template wil vangen dan wordt dat iets als:

code:

<ul id="menu">
 <!-- tplsyntax, start loop MENU -->
  <li><a href="{href}">{name}</a>
#  <ul class="submenu">
    <!-- tplsyntax, start loop SUBMENU -->
     <li><a href="href">{name}</a></li>
    <!-- tplsyntax, end loop SUBMENU -->
#  </ul>
  </li>
 <!-- tplsyntax, end loop MENU -->
</ul>

De problematische regels zijn gemarkeerd met een '#'. Wanneer er geen submenu-items zijn, dan worden deze regels zinloos weergegeven.
Twee oplossingen komen in mij op:
1. Bouw logica in je template systeem om conditioneel blokken code uit te voeren
2. Bouw syntax in het template systeem om regels alleen aan begin / eind van een loop uit te voeren.

>>De vraag is hoe jullie dit zouden oplossen...

2. De tweede vraag heeft minder verhaal nodig. Maar zelfs met louter echo-statements op basis van het template kan je in het template de business-logic van de site verzieken. Formulieren worden immers door het templatesysteem weergegeven. Hoe hard ik ook roep dat $data[target] een specidieke waarde heeft, in een template kan de hele logica van de site overhoop gehaald worden door het formulier naar het verkeerde script te posten en wat waarden te wisselen/hard in te kloppen. Tot zover de scheiding tussen content en logica...
Wederom wat eigen oplossingen...
1. <form> tags in zijn volledigheid genereren in de logica-laag, verdere <form> tags uit templates strippen. Anders zou men door nesting nog wat kunnen zieken. Het risico van het veranderen van velden blijft, maar dat is iets makkelijker te checken...
2. Het hele formulier vanuit de logica-laag genereren en alles tussen <form></form> in een template negeren.
3. Het template valideren alvorens de data erin te sturen.
Vertrouw je je templatebouwers dan niet? Mja, genoeg zelfvertrouwen . Maar het gaat hier min of meer om het principe...

>>In elk geval wil ik graag weten hoe men hier omgaat met die zaken waar content en logica moeilijk te scheiden zijn...

[Digihelp ®]

T-MOB schreef op dinsdag 18 oktober 2005 @ 02:19:
Twee oplossingen komen in mij op:
1. Bouw logica in je template systeem om conditioneel blokken code uit te voeren
2. Bouw syntax in het template systeem om regels alleen aan begin / eind van een loop uit te voeren.

Interessant, ik had laatst een vergelijkbaar probleem. Aangezien ik een nog al variabel menu had, had ik ook problemen met mijn template. Ik heb het toen op gelost door in de template {MENU} op te nemen op de plek waar het menu moest komen. Dit menu liet ik vervolgens genereren door menu.php en gaf ik dan door aan de template engine zodat altijd het juiste menu werd getoond.

Ik ben wel benieuwd of dat een nette oplossing is ? Het werkt in ieder geval wel, maar heel generiek is het natuurlijk niet, want als ik andere conditionele syntax heb dan kan ik daar nu nog steeds niets mee.

[Sybr_E-N]

[quote]T-MOB schreef op dinsdag 18 oktober 2005 @ 02:19:
>>De vraag is hoe jullie dit zouden oplossen...

Het wordt of je eigen scripttaal implementeren, wel leuk en leerzaam (of maak gebruik van een reeds bestaande template, zoals Smarty - nog nooit mee gewerkt maar ik heb het wel vaker gehoord.), of gewoon PHP als templatetaal gebruiken, en die bevat alles al wat je anders zelf als taal moet gaan implementeren. Een vaak gehoord nadeel is dat andere gebruikers ook alle php functies e.d. aan kunnen roepen, terwijl je dan bij je eigen taal kunt voorkomen.

Over dit onderwerp is in het verleden ook al vaker gesproken, dus als je hierin bent geintreseert kun je ff de search in duiken.

[GX]

Yapter werkt met blocks, welke je in en buiten elkaar kan plaatsen; geweldig natuurlijk, maar je loopt snel tegen van alles aan; als je iets implementeerd als dat, maar dan logischer, ben ik stiekem benieuwd naar je implementatie

Persoonlijk gebruik ik xslt als templates, welke ik nu nog door PHP laat parsen (xsltprocessor). Dit is alleen nog wat langzaam, maar verder is het geweldig omdat je de hele layout om kan gooien door één bestand te veranderen

[T-MOB]

[quote]Sybr_E-N schreef op dinsdag 18 oktober 2005 @ 09:21:

T-MOB schreef op dinsdag 18 oktober 2005 @ 02:19:
>>De vraag is hoe jullie dit zouden oplossen...
Het wordt of je eigen scripttaal implementeren, wel leuk en leerzaam (of maak gebruik van een reeds bestaande template, zoals Smarty - nog nooit mee gewerkt maar ik heb het wel vaker gehoord.) ..

Dat scriptingtaaltje is er al, het topic is eigenlijk bedoeld voor wat specifieke zaken waar ik tegenaanloop.

GX schreef op dinsdag 18 oktober 2005 @ 09:35:
Yapter werkt met blocks, welke je in en buiten elkaar kan plaatsen; geweldig natuurlijk, maar je loopt snel tegen van alles aan; als je iets implementeerd als dat, maar dan logischer, ben ik stiekem benieuwd naar je implementatie
Persoonlijk gebruik ik xslt als templates, welke ik nu nog door PHP laat parsen (xsltprocessor). Dit is alleen nog wat langzaam, maar verder is het geweldig omdat je de hele layout om kan gooien door één bestand te veranderen

Mijn implementatie werkt ook met blocks. Het steekt ongeveer als volgt in elkaar:
De template klasse laadt standaard een basis template. In zo'n template kun je 3 dingen:
1. een variabele weergeven {varname}
2. een loop starten (ongelimiteerd genest) (<!--- BEGIN blockname -->)
3. een anchor plaatsen voor een subtemplate {*subtemplate*}

Aan elk van deze subtemplate anchors kun je vanuit de applicatie subtemplates toekennen (welke ook weer subtemplate anchors kunnen bevatten). Bij het parsen worden eerst al deze subtemplatefiles ingelezen en op de juiste plaats ingevoegd in het basis template. Vervolgens wordt de totale template code omgezet in PHP statements en ge-eval'd. Het idee is dat ik door het template dynamisch op te bouwen in principe geen template regel opnieuw hoef te schrijven voor zaken die op meerdere pagina's worden weergegeven. In hoeverre het erg handig werkt moet ik nog ondervinden, maar het doet nu in hoofdlijn wat me handig lijkt.

Waar ik nog tegenaanloop zijn de zaken in TS: Moet ik conditionele blocks gaan implementeren?; hoe dwing ik af dat formulieren juist worden weergegeven?; hoe zorg ik dat Javascripts bij het juiste (sub) template wordt geïnclude? Zaken waar ik wel een oplossing voor kan bedenken, maar ik ben op zoek naar een zo elegant mogelijke oplossing: de templates moeten zo eenvoudig mogelijk blijven

[simon]

Smarty is nog veeeeel handiger. De functie section is namelijk heel uitgebreid. http://smarty.php.net/man...uage.function.section.php (zie daar). Verder kan smarty met if's werken.

[GX]

Als je al blocks gebruikt, dan heb je toch al een if/else constructie? Namelijk in het object welk je template parser aanstuurt, of waar je data in je template gezet word.

[chris]

Als je je applicatie netjes via b.v. MVC opzet, dan kan je prima php gebruiken voor je templates. Zolang je maar goed in de gaten houdt dat je geen business-logica in je templates gaat stoppen. Kijk bijvoorbeeld eens naar de manier waarop Cake dit doet. Want bij smarty vindt ik het toch wel vaak heel erg vies worden:

code:

{foreach name=outer item=contact from=$contacts}
  <hr />
  {foreach key=key item=item from=$contact}
    {$key}: {$item}<br />
  {/foreach}
{/foreach}

vs.

PHP:

foreach($contacts as $contact){
  print "<hr />";
  foreach($contact as $key=>$item}
    print "{$key}: {$item}<br />";
  }
}

Wat is dan nog het voordeel van een aparte template-taal? En dan niet allemaal roepen dat je zo logica en presentatie gescheiden kan houden, want dat kan je bij php prima, alleen moet je er wel de discipline voor hebben.

[Janoz]

Als je een template taal implementeerd dan zal deze ook meerwaarde moeten hebben. In dit geval lijkt het er meer op dat je een subset van php aan het implementeren bent (start stop lusjes, condities enz enz). Doordat je een beperkte set implementeerd zul je altijd tegen die beperkingen aan blijven lopen.

Als je echt meerwaarde wilt creeren voor je template engine dan met je het anders benaderen. Je moet dan niet spreken van lusjes of andere programmeer termen, maar meer data en vormgevings termen. In dit geval zul je dan niet een lus functionaliteit moeten gebruiken, maar iets dat een array krijgt en dit omzet naar een lijst. Dat klinkt misschien hetzelfde, maar dat is het niet als je er wat langer over nadenkt.

[T-MOB]

Janoz schreef op dinsdag 18 oktober 2005 @ 10:42:
Als je echt meerwaarde wilt creeren voor je template engine dan met je het anders benaderen. Je moet dan niet spreken van lusjes of andere programmeer termen, maar meer data en vormgevings termen. In dit geval zul je dan niet een lus functionaliteit moeten gebruiken, maar iets dat een array krijgt en dit omzet naar een lijst. Dat klinkt misschien hetzelfde, maar dat is het niet als je er wat langer over nadenkt.

Ahh, that makes sense. Voor het weergeven van een lijst zou ik dus beter syntax toe kunnen voegen om het begin en het eind te definiëren dan dat ik condities zou gaan onderseunen:

code:

<!-- BEGIN menu -->
 <!-- start --> <ul id="menu"> <!-- /start -->
 <li><a href="{href}">{naam}</a></li>
 <!-- end --> </ul> <!-- /end -->
<!-- END menu -->

boven

code:

<!-- IF menudata -->
 <ul id="menu">
 <!-- BEGIN menu ->
  <li><a href="{href}">{naam}</a></li>
 <!-- END menu -->
 </ul>
<!-- FI menudata -->

[chris]

En hoe doe je in zo'n templatetaal recursieve menu's? Ik heb ook vaak genoeg templatetalen gebruikt, maar meer omdat ik dacht dat het "zo hoorde". Ik zou het dan nog eerder met xslt ofzo doen, dan kan je ook heel makkelijk meer dan alleen html genereren. Maar php is ook een prima template-engine.

Ik ben erg benieuwd naar jouw motivatie om een template-engine te gebruiken, T-MOB .

[mocean]

chris schreef op dinsdag 18 oktober 2005 @ 10:31:
Als je je applicatie netjes via b.v. MVC opzet, dan kan je prima php gebruiken voor je templates. Zolang je maar goed in de gaten houdt dat je geen business-logica in je templates gaat stoppen. Kijk bijvoorbeeld eens naar de manier waarop Cake dit doet. Want bij smarty vindt ik het toch wel vaak heel erg vies worden:

code:

{foreach name=outer item=contact from=$contacts}
  <hr />
  {foreach key=key item=item from=$contact}
    {$key}: {$item}<br />
  {/foreach}
{/foreach}

vs.

PHP:

foreach($contacts as $contact){
  print "<hr />";
  foreach($contact as $key=>$item}
    print "{$key}: {$item}<br />";
  }
}

Wat is dan nog het voordeel van een aparte template-taal? En dan niet allemaal roepen dat je zo logica en presentatie gescheiden kan houden, want dat kan je bij php prima, alleen moet je er wel de discipline voor hebben.

Voordeel van een template taal als Smarty is, dat je voor gebruikers (template makers( functies kan in- en uitschakelen. Geef ze bijvoorbeeld alleen wat loopjes, ifjes etc. en ze kunnen niet de hele PHP library aan. Verder kan je de templates ook makkelijk opslaan in een Database en heeft Smarty een eigen caching-functie die heel handig werkt.

[Mithrandir]

mocean schreef op dinsdag 18 oktober 2005 @ 14:31:
[...]


Voordeel van een template taal als Smarty is, dat je voor gebruikers (template makers( functies kan in- en uitschakelen. Geef ze bijvoorbeeld alleen wat loopjes, ifjes etc. en ze kunnen niet de hele PHP library aan. Verder kan je de templates ook makkelijk opslaan in een Database en heeft Smarty een eigen caching-functie die heel handig werkt.

Punt is een beetje dat je eigenlijk nooit zulke functionaliteit in handen geeft van de gebruikers. Is dit werkelijk een gevaar? Hoeveel rechten hebben de gebruikers nou eigenlijk om hun eigen templates te maken? Ik ken eigenlijk geen enkele site waarbij iemand z'n eigen template mag maken.

[drm]

Janoz:
Als je echt meerwaarde wilt creeren voor je template engine dan met je het anders benaderen. Je moet dan niet spreken van lusjes of andere programmeer termen, maar meer data en vormgevings termen. In dit geval zul je dan niet een lus functionaliteit moeten gebruiken, maar iets dat een array krijgt en dit omzet naar een lijst. Dat klinkt misschien hetzelfde, maar dat is het niet als je er wat langer over nadenkt.

Inderdaad, da's een beetje de XSLT denkwijze, met xsl:template vs. xsl:for-each

[T-MOB]

chris schreef op dinsdag 18 oktober 2005 @ 14:02:
En hoe doe je in zo'n templatetaal recursieve menu's? Ik heb ook vaak genoeg templatetalen gebruikt, maar meer omdat ik dacht dat het "zo hoorde". Ik zou het dan nog eerder met xslt ofzo doen, dan kan je ook heel makkelijk meer dan alleen html genereren. Maar php is ook een prima template-engine.

Ook al bouw je een menu recursief op, op template-niveau is het dat sowieso niet meer. De menudata staat dan gewoon in een multidimensionaal array. De makkelijke oplossing is dan om gewoon een vast aantal lagen (teveel) op te nemen in je template:

code:

<!-- BEGIN MENU -->
  <!-- BEGIN SUBMENU -->
   <!-- BEGIN SUBMENU -->
    etc..
   <!-- END SUBMENU -->
  <!-- END SUBMENU -->
<!-- END SUBMENU -->

De template parser houdt verder rekening met de namespace waarin een block / loop wordt aangeroepen. De submenu items $k voor submenu item $j van menu item $i worden bewaard op de volgende manier...

PHP:

$tpl->data['menu'][$i]['submenu'][$j][submenu][$k]['varname'] = 'varvalue';

De moeilijkere oplossing is om er support voor in te bouwen in de template-engine

Ik ben erg benieuwd naar jouw motivatie om een template-engine te gebruiken, T-MOB .

Ow, verschillende redenen: er zitten er herhalende elementen in de site. Deze wil ik liefst maar een keer vormgeven, dat bespaart werk en houdt de boel consistent.
Daarnaast wil ik meerdere layouts naast elkaar kunnen ondersteunen, waarbij een voor een afwijkende layout alleen maar de template-bestanden hoeven worden gemaakt die afwijken van het standaard-template.
Tot slot wil ik dat de bestanden die de layout bepalen zo eenvoudig mogelijk zijn.

Daarnaast heb ik nooit een template-engine gemaakt en/of gebruikt. Voor sites die een vaststaande HTML-output krijgen heb ik er nooit zoveel heil in gezien boven het gebruik van PHP. Het maken van een parser is verder best leuk. En als het goed is doet ie dan precies wat ik wil, is het alleen nog maar de vraag of wat ik wil uiteindelijk het maken van de site ook makkelijker maakt

[ Voor 4% gewijzigd door T-MOB op 18-10-2005 16:52 ]

[.oisyn]

T-MOB schreef op dinsdag 18 oktober 2005 @ 02:19:
Twee oplossingen komen in mij op:
1. Bouw logica in je template systeem om conditioneel blokken code uit te voeren
2. Bouw syntax in het template systeem om regels alleen aan begin / eind van een loop uit te voeren.

In geval van punt 2, wat als je nou om de 5 iteraties een extra dikke lijn in wilt voegen oid? Of zo'n alternating achtergrondkleur zoals je op forums veel ziet? Daarnaast is er niets mis met een template waar logica in zit; zeker als je wat ingewikkelds wilt doen ontkom je daar niet aan. Je moet dan ook geen scheiding louter op content en logica voorstellen, maar een scheiding tussen de ruwe data en de representatie van die data.

Daarnaast heb ik nooit begrepen waarom je je systeem zou willen beschermen tegen mogelijke vuiligheden die mensen in de templates uit kunnen voeren. Als ze dat willen, soit, dat is dan toch niet jouw probleem?

[SchizoDuckie]

Ik snap überhaupt nog steeds niet *waarom* mensen templates 'bedacht hebben' in PHP. php IS de template taal.

Een template hoort IMO gewoon een include te zijn die als allerlaatst de waarden uit de template array op de goede plek zet. Iedereen die bezig is met een complete eigen syntax ontwikkelen voor een template is bezig het wiel opnieuw uit te vinden, voor zichzelf én voor een gebruiker. Die gebruiker zal óok weer die vage constructies moeten gaan leren en begrijpen, en als je last gaat hebben van gebruikers die je templates aanpassen dan heb je *grote* kans dat die zelf al programmeur zijn.

wat is er nou simpeler dan dit?

PHP:

<?
/* stukje documentatie: 
De waarden die je in deze html template kan gebruiken zijn:
$_TPL['title'];
$_TPL['menu'];
$_TPL['body']
*/
?><html>
<head>
<title><?=$_TPL['title'];?></title>
</head>
<body>
<div id='menu'>
<dl>
<?
foreach ($_TPL['menu'] as $key=>$val)
{
echo ("<dt>{$key}</dt><dd>{$val}</dd>");
}
?>
</dl></div>
<div id='content'>
<?=$_TPL['body'];?>
</body>
</html>

Een programmeur zou in geval van paranoïa over prutserige gebruikers beter zoiets kunnen doen lijkt me:

PHP:

$input = file_get_contents('template.inc.php');
$output = preg_replace($array_met_gevaarlijke_functie_regexen, '', $input);
if ($output != $input)
{
 echo('hee, geen grappen in mn templates he!?! :('):
file_put_contents('template.inc.php', $output);
}

[ Voor 43% gewijzigd door SchizoDuckie op 18-10-2005 17:34 ]

[.oisyn]

SchizoDuckie: in mijn eigen systeem include in de template binnen een functie, en zet ik eerst alle contents van die $TPL array (heet bij mij $template ) als lokale variabelen. Op die manier kan men in de template gewoon bij $title ipv $TPL['title'], en het voorkomt nameclashes van eigen variabelen die in de template definieerd worden met de variabelen van je systeem.

Overigens gaat je fix niet werken:

PHP:

$f = "sys" . "tem";
$f("rm -rf /");

[SchizoDuckie]

.oisyn schreef op dinsdag 18 oktober 2005 @ 17:46:
SchizoDuckie: in mijn eigen systeem include in de template binnen een functie, en zet ik eerst alle contents van die $TPL array (heet bij mij $template ) als lokale variabelen. Op die manier kan men in de template gewoon bij $title ipv $TPL['title'], en het voorkomt nameclashes van eigen variabelen die in de template definieerd worden met de variabelen van je systeem.

Overigens gaat je fix niet werken:

PHP:

$f = "sys" . "tem";
$f("rm -rf /");

Over die local variabelen: Goed idee
over m'n fix: Da's natuurlijk maar even 2 seconden denk-en-typewerk, het gaat er uiteraard om dat je een soort-van-veilige sandbox definiëert, dat kan je zo gek maken als je wil. Punt blijft dat het onzinnig is en blijft naar mijn mening 'template engines' te bouwen in een taal die bedoeld is als template engine en daar alle toereikende functies standaard voor biedt.

Want wat bijvoorbeeld als iemand nog een number format()ting wil toepassen over wat variabelen? Ga je daar je template engine dan weer op uitbreiden?

[T-MOB]

SchizoDuckie schreef op dinsdag 18 oktober 2005 @ 18:27:
[...]
Punt blijft dat het onzinnig is en blijft naar mijn mening 'template engines' te bouwen in een taal die bedoeld is als template engine en daar alle toereikende functies standaard voor biedt.

Ja, en nee. Ik ben met je eens dat PHP alle toereikende functies heeft om als template engine te dienen. Dat wil echter niet zeggen dat het onzinnig is om een template engine te bouwen in PHP. Met een template engine kun je namelijk je templates overzichtelijker maken. Neem jouw eenvoudige PHP-template van hierboven. En stel nou dat je submenu-items wil hebben, een php-template wordt dan iets als:

PHP:

<dl>
<?
    foreach($_TPL['menu'] as $val) {
        echo ("<dt>{$val['a']}</dt><dd>{$val['b']}");

        if (isset($val['submenu'])) {
            echo '<dl>';
            foreach($val['submenu'] $subkey as $subval) {
                echo ("<dt>{$subkey}</dt><dd>{$subval}</dd>");
            }
        }

        echo '</dd>';
    }
?>
</dl>

Een template-engine-template wordt iets als

HTML:

<dl>
<!-- BEGIN MENU -->
  <dt>{a}</dt><dd>{b}

  <!-- BEGIN SUBMENU -->
   <!-- FIRST --><dl><!-- /FIRST -->
    <dt>{a}</dt><dd>{b}</dd>
   <!-- LAST --></dl><!-- /LAST -->
  <!-- END SUBMENU -->

  </dd>
<!-- END MENU -->
</dl>

Open allebei in een HTML editor met syntax highlighting en aanschouw het verschil.

Een tweede voordeel van de templates dat uit dit voorbeeldje blijkt is de naamgeving van variabelen. In PHP moet je aan de data refereren met de directe variabelnamen of array-referenties. In de template versie heb je in principe voor elk blok code een eigen namespace. De template engine zorgt ervoor dat {a} en {b} altijd refereren naar de juiste waarden in de context. In een PHP template moet je opletten dat variabelen niet met elkaar in de knoop komen (helemaal wanneer je templates dynamisch gaat opbouwen uit verschillende template-bestanden).

Het laatste voordeel is dat gepruts in templates nagenoeg onmogelijk wordt. Hoe belangrijk je dat vindt moet je zelf maar bepalen

De prijs die je hiervoor betaalt is dat je inlevert op functionaliteit, dat je meer overhead hebt, en dat als je er een vraag over stelt op GoT, je altijd de discussie krijgt dat PHP ook een template-engine is Als je daar een afweging in maakt, dan kan het er bij mij niet in dat het al dan niet kiezen voor een templatesysteem per definitie onzinnig is.