[PHP] een template

[Zoolander]

Ik heb geen idee of jullie hier op zitten te wachten,...

Stel we schrijven zelf een template engine, omdat

a: dat nou eenmaal leuker is
b: het op maat is

Dan komen er een aantal punten in mijn op waar ik niet helemaal uitkom qua syntax wat waar hoort.

a: is het handig als je niet werkt met een aparte designer en dus zelf alles doet?
Het antwoord hierop echter was niet eenduidig voor mij. Aangezien, het scheiden van presentatie en logica en db altijd mooi is lijkt me.

Dus kwam ik bij het volgende:

b: een variabele in HTML opzoeken en vervangen met {$varname} is makkelijk.
een db fectch met niks fancy's ook wel {tpl:subtemplate:$varname} (evt recursief).

Maar wat nu als er andere dingen aan de orde zijn zoals dat na elke 3 td's een tr geplaatst moeten worden. Of Sommige td's een andere klasse krijgen, maar dit afhankelijk is van de output van de db fetch.

Hier lijken presentatie en logica niet echt te scheiden zonder dat je template een eigen taal wordt, en dat, dat lijkt me nou ECHT NIET de bedoeling. (zo, mijn mening )

Is het dan zo denken jullie dat sommige templateoptions een paar parameters mee mogen krijgen?
Zo iets van: {tpl(table, cols=3):subtemplate:$varname} of zijn dit soort dingen niet te templaten?

Ik ben benieuwd of jullie deze problemen ook gehad hebben en wat voor keuzes jullie hier gemaakt hebben.

Laten we geen bestaande grote template-engines erbij halen tenzij een bepaalde functionaliteit iets met het onderwerp van doen heeft.

[Bluestorm]

Ik denk dat je globaal twee keuzes hebt. Je kunt je complete datamodel beschikbaar maken in de template. Waar je door tags, etc in de template de data als het ware uit trekt. Het is dan ook logisch dat logica wat betreft bijvoorbeeld je kolommen in de template beschreven staat. Je template wordt dan bijna een soort aparte programmeertaal.
De andere optie is om je template echt uitsluitend de layout te laten bevatten ingedeeld in blokken en plaatsen waar data mag worden ingevuld. Het vullen van die template stuur je dan vanuit je code (eventueel een aparte 'taal' daarvoor) waarmee je dus je logica daadwerkelijk apart hebt, maar je hebt wel een dermate hoge koppeling tussen je code en template dat je je af kunt vragen of je er in productiviteit mee op schiet.

[Zoolander]

Ja precies. Daarom kan je je afvragen of templaten wel zin heeft...
Ik hang eerder naar dat het onzinnig is dan zinnig. Tenzij je genoegen neemt met basisfuncties waarbij je dus niet aparte klassen / aantal rijen / nog meer meegeeft aan je TPL engine.

[Apache]

Geef een template engine gewoon enkele typische programmeer constructies, loops, if's, else, laat if's simpele constructies parsen en laat loops een %i oid beschikbaar stellen. Laat ook toe dat assigned gegevens in een if etc geevalueerd kunnen worden.

alles niet te uitgebreid maar wel voldoende om layout scripting mee te doen.

bvb alternating rows in een table (qua color dmv een css class):

code:

<table>
{foreach=[naam]}
  <tr>
    <td{if=(%i %2) == 0}class='alternate'{/if}>[naam]</td>
  </tr>
{/foreach}
</table>

T'is vast ook mogelijk om aan je designer van die standaard design tricks aan te leren zonder dat hij begrijpt wat er juist staat, desnoods maak je een documentje met screenshots & voorbeeldcode.

[Bluestorm]

nadeel van dat soort dingen is natuurlijk dat je die HTML template echt nooit meer in een WYSIWYG editor zou kunnen laden. Heeft de persoon die de templates doet voldoende kennis om het met de hand te doen dan kan een beetje logica in de templatetaal geen kwaad. Maar als je het toch over PHP hebt... Ik geef dan lekker de voorkeur aan php voor m'n templates. Je kunt het net zo overzichtelijk houden als een echte template, het is snel en als je eens iets raars/customs wilt doen kan het altijd.

[JHS]

Als je zélf je templates bouwt, zie ik geen enkele reden om een hele taal voor je tpl's te ontwikkelen, als PHP daar zelf al uitstekend geschikt voor is . Je moet er dan "alleen" maar op letten dat je in je template alleen code stopt die betrekking heeft hoe de data getoond wordt (denk evt. aan MVC model).