[PHP] Hoe templates maken?

[Anoniem: 28557]

Ik ben de maintainer van een open source PHP applicatie. Deze applicatie bestaat al ruim 10 jaar en zo'n 5 jaar geleden heb ik de development overgenomen. De applicatie is dus ooit geschreven in PHP3 en slechts mondjesmaat aangepast naar PHP4 en PHP5. De oorspronkelijke auteur was een doorgewinterde OO-ontwikkelaar en die heeft ook een keuring objectmodel bedacht. Ik ben maar een hobby-programmeur en ben zo'n beetje in zijn stijl verder gegaan. De classes bevatten de Model-code, maar Controller en View staan zo'n beetje door elkaar heen.

Vorig jaar heb ik het boek Professional PHP5 (aanrader!) gelezen en er achter gekomen dat veel van mijn PHP-kennis achterhaald was.

Ik ben dus nu begonnen om nieuwe code volgens nieuwe principes te schrijven (public/private, static methods ipv global functions, phpdoc tags, etc.) en daar hoort natuurlijk ook een nette MVC-scheiding bij. Ik wil geen gebruik maken van een framework omdat ik geen afhankelijkheid van externe code wil, frameworks vaak veel meer bieden dan ik nodig heb en natuurlijk ook omdat ik gewoon eigenwijs ben.

Ik heb op GoT en op de rest van Internet van alles gelezen over MVC, templates, etc. Ik heb ook van een aantal frameworks de sourcecode en de documentatie bekeken maar ik ben er toch nog niet uit hoe ik templates netjes op moet lossen. Doordat ik enige ontwikkelaar ben en ik zelf ook niet in de softwaredevelopmenthoek werk mis ik een beetje een sparring partner, daar ga ik jullie dus voor misbruiken :-) en misschien wordt dit nog wel een topic waar anderen nog wat van kunnen leren.

Dit is ruwweg zoals het nu in elkaar zit:

PHP: something.inc.php

class something extends dbTable {
    [...]
    public function get_edit_array() {
        $return=array()
        foreach($this->fields as $name->$value) {
            $return[]=array("name"=>$name, "value"=> $value);
        }
       return $return;
    }
}

PHP: util.inc.php

<?php
function array_to_form($array) {
    $html="<form>\n";
    foreach($array as $field) {
        $html.="    <input name=\"" . $field["name"] . "\">" . $field["value"] . "</input>";
    }
   $html.= "    <input type=submit>";
   $html.="</form>"
}

PHP: something.php

<?php
   $var=getvar("var");
?>
<h1><?php echo $title; ?></h1>
<?php
if($_action="edit") {
    echo array_to_form($something->get_edit_array);
}
?>

Zo zijn er een aantal functies die allerlei soorten HTML elementen genereren, maar her-en-der staat er ook wel wat HTML in de models. Dat moet dus anders.

Het afgelopen half jaar heb ik gewerkt aan een nieuwe feature, en die heb ik ongeveer zo opgezet:

PHP: form.tpl.php

<form action="<?php echo $tpl_action ?>">
  <fieldset>
      <legend>fieldset 1</legend>
      <label>eerste</label>
      <input><?php echo $tpl_field1 ?></input>
      <label>tweede</label>
      <input><?php echo $tpl_field2 ?>/input>
   </fieldset>
   <input type="submit">
</form>

PHP: template.inc.php

class template {
   private $vars=array();
   function __toString() {
       extract($this->vars, EXTR_PREFIX_ALL, "tpl");
       include($this->template);
   }
}

PHP: something.php

$tpl=new template("form", array("action"=>"something.php", "field1"=>"value1", "field2"="value2"))
echo $tpl;

Hier is de HTML netjes van de rest gescheiden en het ziet er allemaal redelijk overzichtelijk uit. Maar, nu ga ik een nieuwe feature toepassen, waar de forms veel uitgebreider en complexer zijn en eigenlijk heb ik geen zin om die forms helemaal handmatig te gaan uitschrijven. Natuurlijk kan ik in de templates gebruik maken van wat foreach-lussen e.d., maar bij complexere formulieren (met geneste fieldsets, verschillende typen input-velden, etc.) wordt dat lastig om dat netjes voor elkaar te krijgen.

Nu zou ik natuurlijk een aantal objecten form, input, fieldset, etc. aan kunnen maken en op die manier een form gaan opbouwen, dit is volgens mij hoe bijvoorbeeld Symfony dat doet.
Dan zou je zoiets krijgen:

PHP:

$form=new form();
$fieldset=new fieldset("fieldset");
$input=new input("field1", "value1");
$fieldset->addField($input);
$form->addFieldset($fieldset);
$form->display();

Maar ja, dan zit de HTML weer in de form/input/fieldset objecten en niet in een template. Dus iemand die een nieuwe template voor mijn applicatie bouwt kan de HTML niet aanpassen...
Natuurlijk kan ik de HTML dan weer uit die objecten halen en daar mini-templates voor maken, maar dan wordt het echt onoverzichtelijk, denk ik.

Kortom: zijn er nog andere manieren om zoiets aan te pakken, hoe zouden jullie dit doen? Is er op een nette manier een combinatie van bovenstaande te maken? Waar ik aan zat te denken was om de manier met de template-class aan te houden en daar voor de complexe en dynamische delen van de site (met name forms dus) een aantal classes aan te maken zoals in het laatste voorbeeld, maar ik ben toch bang dat het dan onoverzichtelijk wordt.

[PatrickH]

Ik maak zelf veel gebruik van Smarty, werkt voor mij erg goed.
Kijk er eens naar zou ik zeggen..

[ReenL]

Je kan de klasse form binden aan een view(-partial).

In de classe form maak je dan een functie in de vorm van:

PHP:

public function __toString()
{
    $view = new Partial_View();
    $view->setForm($this);
    return $view->render('path/to/form/template');
}

In die view kan je vervolgens:

PHP:

<form>
<? foreach ( $elements as $el ) { ?>
    <label>Wat html enzo <?=$el?></label>
<? } ?>

Vervolgens kan je elk sub-element ook een template geven.

[Freeaqingme]

PatrickH schreef op dinsdag 26 oktober 2010 @ 21:13:
Ik maak zelf veel gebruik van Smarty, werkt voor mij erg goed.

Smarty is gewoon een manier om je viewlogica te scheiden van de rest van je applicatie. Dat gebeurt hier (als ik het goed begrijp) al, dus is http://nosmarty.net van toepassing. Je zegt dat je al naar wat frameworks gekeken heb, ik zou je willen aanraden eens naar Zend_View en Zend_Form te kijken (voorzover je dat nog niet gedaan hebt). Deze componenten zijn ook redelijk standalone te gebruiken, dus mocht je de werkwijze interessant vinden kan je ze ook gewoon los gebruiken.

[krvabo]

Freeaqingme schreef op dinsdag 26 oktober 2010 @ 23:09:
[...]


Smarty is gewoon een manier om je viewlogica te scheiden van de rest van je applicatie. Dat gebeurt hier (als ik het goed begrijp) al, dus is http://nosmarty.net van toepassing.

offtopic:
Ieder z'n mening uiteraard, maar met Smarty 3 is een hoop van de syntax ook anders benaderbaar, waaronder {$var='foo'}. Overigens maakt de schrijver daar een lompe fout met z'n method call op een object, dat kan al heel lang in smarty gewoon {$object->call($var)}. Ook {if in_array($needle,$haystack)} is gewoon mogelijk.
Hoewel ik niet denk dat Smarty heilig is, vind ik het een behoorlijk handig templatesysteem wat mij persoonlijk goed helpt bij het scheiden van weergave en mijn logica.

Ik heb zelf een MVC-structuur waarbij de view bestaat uit Smarty-templates. Zelf gebruik ik geen Smarty caching om het simpele feit dat ik daarvoor al memcache gebruik voor de data, dus van concurrencyproblemen merk ik persoonlijk niets. Mijn Model-laag bestaat uit een model voor elke databasetabel (load, save, exists, getters/setters en checks, etc) en wat 'handlers' die de models extenden voor uitgebreidere functionaliteit.
De Control-laag voert uiteraard alle logica uit.

Met deze opzet ben ik zelf tevreden, maar hoe deze Smartyopzet zich houdt in een high usage-omgeving zal ik pas over een maand of 3 kunnen testen. Maargoed, omdat de syntax sinds versie 3 behoorlijk op die van php lijkt is omzetten naar php zelf alsnog geen probleem natuurlijk.


Persoonlijk zou ik gaan voor een getest en uitgewerkte template-engine en niet zelf alsnog een eigen systeem schrijven. Het hoeft natuurlijk geen smarty te zijn, maar een ander templatesysteem wat wellicht beter aan je behoeftes voldoet is wellicht handig.

[Cartman!]

Smarty compiles down to PHP. This should give you a hint. Really.

Vooral dat vind ik een samenvattende zin voor het verhaal. Voor Zend Framework gebruikten we ook een template engine (Yapter) en ik vond het toen de bom. Nu weet ik gelukkig beter omdat ik in mn views gewoon native code kan gebruiken en dat is voor iedereen handiger, ook zeker voor je IDE die de syntax gewoon begrijpt.

Dat je view-logica in een ander jasje giet (wat dus weer aangeleerd moet worden) maakt het niet ineens geen logica dus ik mis een beetje het punt om een template engine te gebruiken als scheiding tussen logica en opmaak.

@krvabo: misschien houdt je app zonder Smarty het nog wel veel beter, minder compilatie nodig immers

[krvabo]

Over de scheiding:
Hoewel het natuurlijk niet persé een template hoeft te zijn zorgt het wel voor een striktere scheiding tussen presentatie en dataverwerking. Het is zo enorm makkelijk om 'even' een verandering aan een array door te voeren voordat je hem presenteert als je php als template-engine gebruikt, iets wat het onoverzichtelijk maakt. Als je weergave goed gescheiden is van de logica (en dan bedoel ik niet iets als een simpel ifje) dan maakt het het aanpassen van een layout zoveel makkelijker. Je moet gewoon -nooit- (nooit) hardcoded html in een echo hebben. Nooit. Dat maakt het enorm ruk om iets aan te passen omdat je alsnog al je bestanden door moet gaan lezen.

Cartman!: Ja, waarschijnlijk doet de site het iets beter zonder smarty dan met, maar qua overzicht en ontwikkeltijd scheelt het wel. In Smarty 3 zit bijvoorbeeld wel gedeeltelijke caching die wellicht nog kan helpen. En ach, smartycode zelf is snel genoeg omgezet naar echte phpcode mocht het nodig zijn Het zal voornamelijk het geheugengebruik zijn wat toeneemt door wat overhead.

[FragFrog]

Cartman! schreef op woensdag 27 oktober 2010 @ 09:09:
@krvabo: misschien houdt je app zonder Smarty het nog wel veel beter, minder compilatie nodig immers

Uiteraard wordt de template alleen gecompiled als dat nodig is. Alle volgende calls wordt gewoon de gecompilede versie gebruikt. Tuurlijk, er zit wat overhead van Smarty zelf bij dus netto kost het iets meer geheugen, maar dat heb je met elke template handler.

Punt is ook niet dat je met Smarty meer kan dan normaal - ja, er zitten een berg handige functies in die speciaal voor gebruik in HTML templates nuttig zijn, maar daar gaat het niet om. Waar het om gaat is dat je juist veel minder kan, tenminste, niet zonder plugins te gaan lopen schrijven. Een smarty template is HTML met wat smarty tags, de meeste PHP templates die ik gezien heb zijn overduidelijk PHP met een berg echo's en debiele constructies als arrays om output te combineren. XML en XSLT is ook een optie, maar in mijn ervaring minder duidelijk en makkelijk (al kan dat ook aan de implementatie gelegen hebben, het is een wat zeldzamere optie).

[ Voor 9% gewijzigd door FragFrog op 27-10-2010 18:01 ]

[Cartman!]

krvabo schreef op woensdag 27 oktober 2010 @ 17:20:
Over de scheiding:
Hoewel het natuurlijk niet persé een template hoeft te zijn zorgt het wel voor een striktere scheiding tussen presentatie en dataverwerking. Het is zo enorm makkelijk om 'even' een verandering aan een array door te voeren voordat je hem presenteert als je php als template-engine gebruikt, iets wat het onoverzichtelijk maakt.

Dat is een kwestie van netjes werken, dat staat los van het gebruik van een template engine.

Als je weergave goed gescheiden is van de logica (en dan bedoel ik niet iets als een simpel ifje) dan maakt het het aanpassen van een layout zoveel makkelijker.

Kun je me uitleggen hoe? Een ifje is overigens ook logica imo.

Je moet gewoon -nooit- (nooit) hardcoded html in een echo hebben. Nooit. Dat maakt het enorm ruk om iets aan te passen omdat je alsnog al je bestanden door moet gaan lezen.

En dat heeft te maken met template engines omdat?

Cartman!: Ja, waarschijnlijk doet de site het iets beter zonder smarty dan met, maar qua overzicht en ontwikkeltijd scheelt het wel.

Ik zie echt niet in waarom, geef eens concrete voorbeelden als je wilt/kunt.

In Smarty 3 zit bijvoorbeeld wel gedeeltelijke caching die wellicht nog kan helpen. En ach, smartycode zelf is snel genoeg omgezet naar echte phpcode mocht het nodig zijn Het zal voornamelijk het geheugengebruik zijn wat toeneemt door wat overhead.

Het blijft een extra vertaalslag die je (soms) nodig hebt. Bovendien kun je los ook alles cachen wat je zou willen.

FragFrog schreef op woensdag 27 oktober 2010 @ 18:00:
Uiteraard wordt de template alleen gecompiled als dat nodig is. Alle volgende calls wordt gewoon de gecompilede versie gebruikt. Tuurlijk, er zit wat overhead van Smarty zelf bij dus netto kost het iets meer geheugen, maar dat heb je met elke template handler.

Uiteraard, maar nu een laagje extra omdat smarty de boel eerst toch een keer naar php-code om moet zetten.

Punt is ook niet dat je met Smarty meer kan dan normaal - ja, er zitten een berg handige functies in die speciaal voor gebruik in HTML templates nuttig zijn, maar daar gaat het niet om. Waar het om gaat is dat je juist veel minder kan, tenminste, niet zonder plugins te gaan lopen schrijven.

Minder kunnen een feature? Goeie Ik laat graag alle opties nodig.

Een smarty template is HTML met wat smarty tags, de meeste PHP templates die ik gezien heb zijn overduidelijk PHP met een berg echo's en debiele constructies als arrays om output te combineren.

Dat jij nooit goede code gezien hebt zegt niks over de mogelijkheden natuurlijk. In feite ziet *denk ik* mijn view er net zo uit als in smarty maar dan in native php code, iets wat m'n IDE en iemand die geen Smarty kent ook gewoon begrijpt. Waarom weer een extra syntax leren voor een taal die je al gewoon kent?

XML en XSLT is ook een optie, maar in mijn ervaring minder duidelijk en makkelijk (al kan dat ook aan de implementatie gelegen hebben, het is een wat zeldzamere optie).

Daar heb ik geen ervaring mee verder.

[orf]

Mijn IDE begrijpt de Smarty syntax uitstekend. Maar dat doet niet terzake denk ik. Ik denk dat er twee opties zijn voor het probleem van de TS:

Helpers maken die gemakkelijk stukjes formulier kunnen maken (zoals Smarty bijvoorbeeld ook heeft)

PHP:

<select name="categorie">
    <?=$this->html_options($options, $selected)?>
</select>

Met genoeg handige helpers bespaar je jezelf een hoop typewerk. Ikzelf gebruik een form object waarmee je formulieren opbouwt. Het is geen MVC, maar ik maak voor formulieren een uitzondering. Er zit zoveel logic in formulieren dat ik dat liever oplos met een form object. Attributen en tags zijn toch altijd hetzelfde voor een type form-element. Met slimme masks en functies kun je het goed opmaken. Je kunt voor een voorbeeldje eens kijken naar FormHandler. Zelf zou ik het iets abstracter oplossen, maar er zitten een hoop handigheden in (onComplete, validatie, etc).

[krvabo]

Cartman! schreef op woensdag 27 oktober 2010 @ 20:05:
[...]

Dat is een kwestie van netjes werken, dat staat los van het gebruik van een template engine.

Klopt, maar met name in teamverband forceer je het gedrag nu gewoon. Als jij alle data achter elkaar opbouwt en output is dat natuurlijk ook prima. Het gaat natuurlijk om de zeer strikte scheiding van je echte programmeerwerk en de weergave.

Kun je me uitleggen hoe? Een ifje is overigens ook logica imo.

Ik moet op mijn werk toevallig net een site een nieuwe layout geven. Deze site is uit 2007/2008. De html-code wordt ergens in een loopje opgebouwd, roept terloops nog een functie aan die ook wat hardcoded html output, gaat dan 50 regels wat queries zitten uitvoeren, echoot de opgebouwde html van het loopje, sluit php (?>), output wat html, start php (<?) en gaat zo nog wat verder.
Om de layout aan te passen moet ik dus eigenlijk door alle bestanden van de hele site heenlezen om te kijken of er ergens (de juiste) html wordt geoutput. Er is niet één centraal punt waar ik de html kan terugvinden.

Een if is logica, ja, maar er is een groot verschil tussen

Smarty:

{if $sError}
  <div class="error">{$sError}</div>
{/if}

en het uitvoeren van een forloop waarin twee arrays worden samengevoegd tussen de outputs door.

En dat heeft te maken met template engines omdat?

Niet specifiek template engines, maar het is een manier om er voor te zorgen dat er geen html in de code komt. Als je het in een php-bestand wil doen is dat ook prima. Ik zeg alleen dat je nooit hardcoded html moet echoën.

Ik zie echt niet in waarom, geef eens concrete voorbeelden als je wilt/kunt.

Afgezien van het feit dat Smarty natuurlijk dingen heeft om html-formulieren op te bouwen kun je ook simpel je eigen extensies schrijven die ook netjes, per file, worden opgeslagen. Dit kun je natuurlijk ook gewoon zelf doen. Je hebt ook wat standaardfuncties die je meteen kunt gebruiken:

Smarty:

{if $var == ''} // of $var eq ''
 <span>bar</span>
{else}
 <span>{$var}</span>
{/if}

->

<span>{$var|default:'bar'}</span>

Of iets als

Smarty:

{mailto address=$email encode='javascript' subject='Hoi'}

Het heeft onder andere als voordeel dat je html kunt hergebruiken (bijv met {capture}) en template-overerving/including en in de geinclude file dan een variabele zetten.

Smarty:

{include file='header.tpl' title='Waa?!'}

HTML:

<head>
<title>{$title|default:'Meukee'}</title>
</head>

Of row alternate styles:

HTML:

<table>
{section name=item loop=$items}
  <tr class="{cycle values='odd,even'}">
    <td>{$items[item].title}</td>
    <td>{$items[item].description}</td>
  </tr>
{/section}
</table>

Het is zeker geen heilige graal ofzo, maar het heeft z'n handigheden.
Als je php écht goed inzet dan heb je natuurlijk ook vrij snel zelf zoiets geschreven, maar het scheelt wel ontwikkeltijd. Misschien is dat imho .

Het blijft een extra vertaalslag die je (soms) nodig hebt. Bovendien kun je los ook alles cachen wat je zou willen.

Er wordt eenmalig iets omgezet, en ja, naar php, maar verder valt het met parse time erg mee (aangezien je die checks ook uit kunt zetten op productieservers). Natuurlijk kun je zelf ook alles cachen, dat doe ik ook. Echter kun je nu vrij makkelijk bepaalde stukken van de site cachen waardoor je vrij simpel je site nog een stukje langer mee kan laten gaan zodat je op je gemak kan optimaliseren

Wederom: Ja, je kun het ook zelf maken, maar nu is het al voor je gedaan.

Het omzetten naar native php als template-engine is niet iets wat ik verwacht te moeten doen, maar een weinig ingrijpende optie als het _wel_ moet.

Uiteraard, maar nu een laagje extra omdat smarty de boel eerst toch een keer naar php-code om moet zetten.

Zie puntje hierboven

Minder kunnen een feature? Goeie Ik laat graag alle opties nodig.

Standaard is smarty expres beperkt qua functionaliteit om ervoor te zorgen dat er geen grove logica in de template komt. Je kunt echter wel gewoon alle php-functies gebruiken, afhankelijk van de plaats waar je ze gebruikt. Als je method/function een string als argument pakt en ook een string teruggeeft kun je ze zelfs heel makkelijk gebruiken: {$aUsers.$i.name|htmlentities|stripslashes|trim}, wat uit de $i-de entry in $aUsers de naam pakt en daar functions op uitvoert. Je kunt hier ook je eigen methods op uitvoeren.

Dat jij nooit goede code gezien hebt zegt niks over de mogelijkheden natuurlijk. In feite ziet *denk ik* mijn view er net zo uit als in smarty maar dan in native php code, iets wat m'n IDE en iemand die geen Smarty kent ook gewoon begrijpt. Waarom weer een extra syntax leren voor een taal die je al gewoon kent?

Het is dan ook niet puur voor php-programmeurs, maar meer iets voor de 'frontenders' in je bedrijf. De front-end mensen moeten eigenlijk niet in de php-code mogen snuffelen, en door de beperkte standaard methodes die Smarty heeft is de leercurve van smarty vele malen lager dan die van (ietwat gevorderde) php.


Nogmaals: Smarty is verre van heilig, maar het is _een_ manier om een vrij gestandaardiseerde template-engine te gebruiken die wijd wordt gebruikt, itt tot de wat exotischere, maar misschien betere, andere template-engines.

Als je zelf php-templates wilt maken dan zullen die over het algemeen iets beter performen, maar zul je ook zelf soms iets meer moeten schrijven.
Als je de data voor je eigen php-template gewoon klaarzet en dan de template output is dat een goede manier waarop je ook forceert dat de html gescheiden is.Dan haal je dus eigenlijk Smarty er tussenuit.

[Freeaqingme]

De front-end mensen moeten eigenlijk niet in de php-code mogen snuffelen

WAarom niet? Als je ze niet vertrouwt had je ze niet moeten aannemen.

offtopic:
Ik had graag meer willen reageren, maar mijn trein is over 20 seconden op z'n eindpunt

[Wolfboy]

Freeaqingme schreef op woensdag 27 oktober 2010 @ 22:45:
[...]


WAarom niet? Als je ze niet vertrouwt had je ze niet moeten aannemen.

offtopic:
Ik had graag meer willen reageren, maar mijn trein is over 20 seconden op z'n eindpunt

Hangt heel erg van de persoon af natuurlijk. Maar waar ze geen toegang toe hebben kunnen ze ook niet slopen

Afhankelijk van de template developer krijgen ze wat mij betreft volle toegang tot de code of helemaal niets. Al is het voor de netheid meestal wel een goed idee om de code en templates apart te houden.

[Gomez12]

Wolfboy schreef op woensdag 27 oktober 2010 @ 23:05:
[...]
Al is het voor de netheid meestal wel een goed idee om de code en templates apart te houden.

Niet alleen netheid hoor, ook onderhoudbaarheid.

Ik wil niet eens gaan tellen hoevaak ik wel niet constructies heb gezien dat er ergens in de basis html-codes zaten die vroeger altijd standaard waren. In de loop der tijd is er wat veranderd, het kon niet in de basis aangepast worden want dan raakte het alles. Oftewel er werd een quick-fix gedaan om de html-codes weer weg te halen als situatie x/y.
Iemand anders vind dat stukje code weer, doet even Ctrl-C / Ctrl-V en past de output weer ietwat aan. etc etc.

Veel plezier met het daarna onderhouden / aanpassen.
Meest extreme voorbeeld wat ik ben tegengekomen was een stukje basis-code wat door 10 functies / classes heenging en overal bewerkt werd om uiteindelijk weer als de basis-code geoutput te worden.
Elke verandering aan een tussenfunctie sloopte wel ergens weer iets

[krvabo]

Freeaqingme schreef op woensdag 27 oktober 2010 @ 22:45:
[...]


WAarom niet? Als je ze niet vertrouwt had je ze niet moeten aannemen.

offtopic:
Ik had graag meer willen reageren, maar mijn trein is over 20 seconden op z'n eindpunt

Wellicht wat ongelukkig gekozen van me, maar ik bedoelde dat de front-enders absoluut geen toegang tot de php-code moeten hebben om dingen aan te passen. Dit om het doodsimpele feit dat ze:
1) Geen php-programmeur zijn
2) Niet weten wat er allemaal met die data gebeurd / de structuur in elkaar zit.
3) Bij fouten in de code die zij hebben geschreven is de programmeur de verantwoordelijke.

[Gomez12]

krvabo schreef op woensdag 27 oktober 2010 @ 23:27:
[...]

Wellicht wat ongelukkig gekozen van me, maar ik bedoelde dat de front-enders absoluut geen toegang tot de php-code moeten hebben om dingen aan te passen. Dit om het doodsimpele feit dat ze:
1) Geen php-programmeur zijn
2) Niet weten wat er allemaal met die data gebeurd / de structuur in elkaar zit.
3) Bij fouten in de code die zij hebben geschreven is de programmeur de verantwoordelijke.

Geen idee van de grote van je bedrijf, maar bij de kleinere bedrijven heeft een stuk inzage over het algemeen wel weer voordelen.
- Ze kunnen inschatten wat er met de gevraagde data gebeurt en of het wel realistisch is
- Ze kunnen ( heel erg beperkt, je wilt niet elke dag een discussie over methode x/y hebben ) de programmeur ook wijzen op fouten in hun toekomstvisie.

Persoonlijk heb ik een redelijke hekel aan complete scheiding. De een kan dan niet meer de ander checken.
Een php-programmeur kan een performance kunststaaltje uithalen op een gevraagde front-end functie. Maar als de frontender al weet dat er volgende maand weer iets bijkomt dan kan dat hele kunststukje pure verloren tijd zijn geweest.

[Cartman!]

krvabo schreef op woensdag 27 oktober 2010 @ 22:10:
[...]
Klopt, maar met name in teamverband forceer je het gedrag nu gewoon. Als jij alle data achter elkaar opbouwt en output is dat natuurlijk ook prima. Het gaat natuurlijk om de zeer strikte scheiding van je echte programmeerwerk en de weergave.

Dat ligt echt aan je werkomgeving dan, hier werkt iedereen volgens dezelfde codestandaard en in principe zien alle views er dan ook t zelfde uit.

Ik moet op mijn werk toevallig net een site een nieuwe layout geven. Deze site is uit 2007/2008. De html-code wordt ergens in een loopje opgebouwd, roept terloops nog een functie aan die ook wat hardcoded html output, gaat dan 50 regels wat queries zitten uitvoeren, echoot de opgebouwde html van het loopje, sluit php (?>), output wat html, start php (<?) en gaat zo nog wat verder.
Om de layout aan te passen moet ik dus eigenlijk door alle bestanden van de hele site heenlezen om te kijken of er ergens (de juiste) html wordt geoutput. Er is niet één centraal punt waar ik de html kan terugvinden.

Dat heeft gewoon niks met deze discussie te maken dat jij een brak project hebt. Met een template engine kun je nog steeds html-code opbouwen in php en dan injecten. Het is een afspraak dat je dat niet doet, template engine of niet.

Een if is logica, ja, maar er is een groot verschil tussen

Smarty:

{if $sError}
  <div class="error">{$sError}</div>
{/if}

en het uitvoeren van een forloop waarin twee arrays worden samengevoegd tussen de outputs door.

Dat hangt er vanaf, als die outputs 'normaal' 2 losse onderdelen zijn die je in een andere view evt. los wilt laten zien en in deze view gemerged dan zou je dat best in je view kunnen doen imo. Je controller doet niks anders dan de data aan de view doorgeven, view-specifieke logica hoort daar niet thuis (zoals bijv. mergen van data).

Niet specifiek template engines, maar het is een manier om er voor te zorgen dat er geen html in de code komt. Als je het in een php-bestand wil doen is dat ook prima. Ik zeg alleen dat je nooit hardcoded html moet echoën.

Ben ik met je eens maar heeft dus niks te maken met deze discussie.

Afgezien van het feit dat Smarty natuurlijk dingen heeft om html-formulieren op te bouwen kun je ook simpel je eigen extensies schrijven die ook netjes, per file, worden opgeslagen. Dit kun je natuurlijk ook gewoon zelf doen. Je hebt ook wat standaardfuncties die je meteen kunt gebruiken:

Smarty:

{if $var == ''} // of $var eq ''
 <span>bar</span>
{else}
 <span>{$var}</span>
{/if}

->

<span>{$var|default:'bar'}</span>

Of iets als

Smarty:

{mailto address=$email encode='javascript' subject='Hoi'}

Het heeft onder andere als voordeel dat je html kunt hergebruiken (bijv met {capture}) en template-overerving/including en in de geinclude file dan een variabele zetten.

Smarty:

{include file='header.tpl' title='Waa?!'}

HTML:

<head>
<title>{$title|default:'Meukee'}</title>
</head>

Of row alternate styles:

HTML:

<table>
{section name=item loop=$items}
  <tr class="{cycle values='odd,even'}">
    <td>{$items[item].title}</td>
    <td>{$items[item].description}</td>
  </tr>
{/section}
</table>

Het is zeker geen heilige graal ofzo, maar het heeft z'n handigheden.
Als je php écht goed inzet dan heb je natuurlijk ook vrij snel zelf zoiets geschreven, maar het scheelt wel ontwikkeltijd. Misschien is dat imho .

Je zegt t zelf al, je kunt dit zo makkelijk zelf doen in native code, je maakt gewoon een extra syntax boven op de syntax die php zelf al hanteert. In Zend Framework heb ik ook gewoon view-helpers die ik kan aanroepen vanuit m'n view, alleen dan native.

Er wordt eenmalig iets omgezet, en ja, naar php, maar verder valt het met parse time erg mee (aangezien je die checks ook uit kunt zetten op productieservers). Natuurlijk kun je zelf ook alles cachen, dat doe ik ook. Echter kun je nu vrij makkelijk bepaalde stukken van de site cachen waardoor je vrij simpel je site nog een stukje langer mee kan laten gaan zodat je op je gemak kan optimaliseren

Wederom: Ja, je kun het ook zelf maken, maar nu is het al voor je gedaan.

Het omzetten naar native php als template-engine is niet iets wat ik verwacht te moeten doen, maar een weinig ingrijpende optie als het _wel_ moet.

Ik cache gewoon volledige pagina's of losse blokjes, veel meer vrijheid imo waarbij je meer kunt cachen dan alleen de rendering van je template.

Standaard is smarty expres beperkt qua functionaliteit om ervoor te zorgen dat er geen grove logica in de template komt. Je kunt echter wel gewoon alle php-functies gebruiken, afhankelijk van de plaats waar je ze gebruikt. Als je method/function een string als argument pakt en ook een string teruggeeft kun je ze zelfs heel makkelijk gebruiken: {$aUsers.$i.name|htmlentities|stripslashes|trim}, wat uit de $i-de entry in $aUsers de naam pakt en daar functions op uitvoert. Je kunt hier ook je eigen methods op uitvoeren.

Ik vind dit zeer onleesbaar, $users[$i]['name'] vind ik zoveel leesbaarder, met een view helper kan t er in php zo uitzien:

PHP:

<?= $this->escape($users[$i]['name']); ?>

Voor een gemiddelde php-ers gaat dat veel leesbaarder zijn. Ik zou er wel uitkomen maar zou me afvragen waarom er een syntax op een syntax gebouwd is.

Het is dan ook niet puur voor php-programmeurs, maar meer iets voor de 'frontenders' in je bedrijf. De front-end mensen moeten eigenlijk niet in de php-code mogen snuffelen, en door de beperkte standaard methodes die Smarty heeft is de leercurve van smarty vele malen lager dan die van (ietwat gevorderde) php.

Het is al gezegd, maar wat voor brakke frontenders heb je dan? Je belangrijkste code zit hoop ik in je controllers/models/services waar ze niet hoeven te kijken. En een leercurve is er natuurlijk niet echt, je leert een syntax aan die waar je alleen binnen Smarty wat aan hebt. De echte php syntax is veel waardevoller om te kennen.

Nogmaals: Smarty is verre van heilig, maar het is _een_ manier om een vrij gestandaardiseerde template-engine te gebruiken die wijd wordt gebruikt, itt tot de wat exotischere, maar misschien betere, andere template-engines.

Het is _een_ manier ja, zeker.

Als je zelf php-templates wilt maken dan zullen die over het algemeen iets beter performen, maar zul je ook zelf soms iets meer moeten schrijven.
Als je de data voor je eigen php-template gewoon klaarzet en dan de template output is dat een goede manier waarop je ook forceert dat de html gescheiden is.Dan haal je dus eigenlijk Smarty er tussenuit.

Ik vind ook niet dat je de html volledig hoeft te scheiden van je php-code. Eigenlijk doe jij die scheiding net zo goed niet, het enige wat je doet is het in een ander jasje gieten maar stiekem komt t op t zelfde neer. Je moet alleen onderscheid maken in controller-logica en view-logica. Dat je door de resultaten gaat loopen om weer te geven hoort in je view, niet in je controller.

[.oisyn]

Grappig dat er dus blijkbaar voor PHP-programmeurs een andere syntax nodig is om ervoor te zorgen dat ze geen prutscode produceren, terwijl het in geen enkele andere taal een probleem is om de view-laag in dezelfde taal te implementeren. Zegt dat iets over de PHP-programmeurs, of eigenlijk iets over de validiteit van het argument?

[Cartman!]

Exact mijn punt maar dan iets beter samengevat

[FragFrog]

.oisyn schreef op donderdag 28 oktober 2010 @ 11:20:
terwijl het in geen enkele andere taal een probleem is om de view-laag in dezelfde taal te implementeren.

Je vergeet dat er sowieso een andere taal gebruikt wordt in views: HTML. Dat is nou net het probleem: je hebt al twee talen door elkaar, en juist die combinatie zorgt voor slecht leesbare code. Tel daar bij op dat je in HTML ook weer CSS en JS gebruikt en het wordt een grote bende van talen die door elkaar lopen.

Er is niemand die beweert dat je CSS inline moet doen, niemand die beweert dat je beter javascript niet in losse bestanden kan zetten, dus waarom zou het vreemd zijn om HTML in losse bestanden te zetten tov je PHP code? Smarty zorgt ervoor dat je net iets meer kan in die HTML bestanden zodat er ook dynamische content in past, maar juist door de limitaties blijft het totaalplaatje van zo'n template HTML. Geen functies, geen queries, geen switches, HTML met wat extra tags om content te injecteren.

Als je echt niet ziet waarom dat duidelijkere code oplevert heb je waarschijnlijk nog nooit intensief gewerkt met verschillende template varianten, of het geluk gehad nooit iemand anders' code te moeten onderhouden.

[.oisyn]

FragFrog schreef op donderdag 28 oktober 2010 @ 13:06:
[...]

Je vergeet dat er sowieso een andere taal gebruikt wordt in views: HTML. Dat is nou net het probleem: je hebt al twee talen door elkaar, en juist die combinatie zorgt voor slecht leesbare code.

Er zijn zoveel dingen die kunnen zorgen voor slecht leesbare code. Mensen moeten gewoon nette code schrijven, en dat kunnen ze best.

dus waarom zou het vreemd zijn om HTML in losse bestanden te zetten tov je PHP code?

Daar is niets vreemds aan. Maar op een of andere manier wordt een include() vanuit PHP waarin je <?=$bla?> toepast (ja, ik weet het, deprecated, maar ze kunnen mijn kont kussen bij Zend, 't is gewoon een praktische feature) ineens gezien als "oei er staat code in mijn HTML". Terwijl PHP wel net dat beetje meer mogelijkheden biedt dan Smarty. Niemand beweert hier dat de view-laag maar uit 1 php file bestaat waar ook alle HTML in staat. Maar er is sowieso logica nodig, en Smarty kan niet in die vraag voorzien.

Geen functies

Onpraktisch

geen switches

Ook onpraktisch

Als je echt niet ziet waarom dat duidelijkere code oplevert heb je waarschijnlijk nog nooit intensief gewerkt met verschillende template varianten.

Of wellicht heb jij alleen maar code van prutsers gezien? Of wellicht was het antwoord op mijn vorige post wel gewoon dat PHP-programmeurs idd vaak prutscode opleveren?

En 't is niet alsof je met Smarty geen lelijke code kunt produceren.

[ Voor 4% gewijzigd door .oisyn op 28-10-2010 13:21 ]

[Janoz]

FragFrog schreef op donderdag 28 oktober 2010 @ 13:06:
[...]

Je vergeet dat er sowieso een andere taal gebruikt wordt in views: HTML. Dat is nou net het probleem: je hebt al twee talen door elkaar, en juist die combinatie zorgt voor slecht leesbare code. Tel daar bij op dat je in HTML ook weer CSS en JS gebruikt en het wordt een grote bende van talen die door elkaar lopen.

Er is niemand die beweert dat je CSS inline moet doen, niemand die beweert dat je beter javascript niet in losse bestanden kan zetten, dus waarom zou het vreemd zijn om HTML in losse bestanden te zetten tov je PHP code? Smarty zorgt ervoor dat je net iets meer kan in die HTML bestanden zodat er ook dynamische content in past, maar juist door de limitaties blijft het totaalplaatje van zo'n template HTML. Geen functies, geen queries, geen switches, HTML met wat extra tags om content te injecteren.

Je mist het punt. HTML alleen is niet genoeg om een dynamische view in elkaar te zetten. Zoals je zelf al aangeeft heb je daarvoor nog een extra taal nodig. Waarom zou je dan naast css, html, javascript en php nog een taal toe gaan voegen aan je project terwijl php je precies die mogelijkheden geeft die je nodig hebt om je view volledig dynamisch te maken?

[Cartman!]

FragFrog schreef op donderdag 28 oktober 2010 @ 13:06:
[...]
dus waarom zou het vreemd zijn om HTML in losse bestanden te zetten tov je PHP code?

Maar dat doe jij toch ook niet? Jij 'vervuilt' je HTML met smarty-tags ipv. met php-tags, wat is het concrete verschil dan volgens jou?

[krvabo]

Cartman! schreef op donderdag 28 oktober 2010 @ 09:29:
[...]

Dat ligt echt aan je werkomgeving dan, hier werkt iedereen volgens dezelfde codestandaard en in principe zien alle views er dan ook t zelfde uit.

Bij mijn vorige werkgever hadden we een team van 6 backend-programmeurs, 10 php'ers en 6 front-enders. We werkten allemaal met dezelfde codestandaard en met een 'zelfgebakken' template-engine van het bedrijf. De backenders schreven het CMS, de front-enders maakten de html en css/javascript en de programmeus ontwikkelden de functionaliteit. De front-enders konden over het algemeen geen php en als ze het wel deden dan was het (uit ontwekendheid) gewoon een rotzooi en spaghetti-geprogrammeer.

Als we kijken naar de TS dan is hij de maintainer van een open source applicatie. Daar werken ook mensen aan die niet zo goed zijn of mensen die geen ruk geven om enige standaard. Wellicht zijn ze het ook niet eens met "jouw standaard". Het gebruiken van een vaste structuur met een extern uitgewerkte template-engine is dan echt geen dom idee.

Dat heeft gewoon niks met deze discussie te maken dat jij een brak project hebt. Met een template engine kun je nog steeds html-code opbouwen in php en dan injecten. Het is een afspraak dat je dat niet doet, template engine of niet.

Jup, maar als jij een php-bestand als view gebruikt wordt het gewoon makkelijker gedaan 'als bugfix' of uit ontwetendheid. In Smarty kun je bijvoorbeeld het gebruik van de {php}-tag blokkeren, waardoor het gewoon simpelweg niet mogelijk wordt om het in je view te plaatsen.

Uiteraard kun je alsnog je view in de controller gooien op manier die je zegt, maar dan heb je het gewoon nog niet helemaal begrepen (de programmeur die dat doet). Het is gewoon erg makkelijk om een stukje control-logica in de view te zetten als het een php-bestand is. Dan wordt het gewoon uitgevoerd, in een template-bestand niet.

Dat hangt er vanaf, als die outputs 'normaal' 2 losse onderdelen zijn die je in een andere view evt. los wilt laten zien en in deze view gemerged dan zou je dat best in je view kunnen doen imo. Je controller doet niks anders dan de data aan de view doorgeven, view-specifieke logica hoort daar niet thuis (zoals bijv. mergen van data).

En het mergen van data hoort nou juist imho niet in een view. Een view hoort zo to the point mogelijk te zijn zonder vervuiling, zodat je juist makkelijk de lay-out kunt veranderen zonder door een hoop php-code heen te moeten scrollen.

Je zegt t zelf al, je kunt dit zo makkelijk zelf doen in native code, je maakt gewoon een extra syntax boven op de syntax die php zelf al hanteert. In Zend Framework heb ik ook gewoon view-helpers die ik kan aanroepen vanuit m'n view, alleen dan native.

De extra syntax is sinds de laatste smarty-versie grotendeels optioneel. Nu kun je ook gewoon php-syntax gebruiken voor een groot aantal functies zoals het toewijzen van een waarde aan een variabele {$var = 'foo'} of loopen {for $i=1; $i<count($array); $i++}, etc.
De extra syntax is er om het voor non-programmeurs makkelijker te maken er iets mee te doen.

En ik zeg ook niet dat Smarty hier de enige in is, wellicht werkt Zend Framework ook wel geweldig, dat weet ik niet daar ik het nooit heb gebruikt. Het is gewoon 'een van de'.

Ik cache gewoon volledige pagina's of losse blokjes, veel meer vrijheid imo waarbij je meer kunt cachen dan alleen de rendering van je template.

Dat kan, maar smarty kan dat dus ook. Hij cachet dan de html-output waardoor je gewoon statische files serveert voor een x-periode. Natuurlijk kun je native ook cachen, dat doe ik ook, maar het is gewoon een van de features die je met een template-engine makkelijk kunt doen. Voor beginnende programmeurs is het bijvoorbeeld erg handig om snel wat meer performance te krijgen uit hun website zonder na te hoeven denken over een cache-systeem.

Ik vind dit zeer onleesbaar, $users[$i]['name'] vind ik zoveel leesbaarder, met een view helper kan t er in php zo uitzien:

PHP:

<?= $this->escape($users[$i]['name']); ?>

Voor een gemiddelde php-ers gaat dat veel leesbaarder zijn. Ik zou er wel uitkomen maar zou me afvragen waarom er een syntax op een syntax gebouwd is.

In smarty kun je ook gebruik maken van de $users[$i]['name'] syntax. Zoals hierboven geschreven is het dus een andere syntax om het makkelijker te maken voor non-phpers en niet zozeer voor php-programmeurs. Dáárom is er een andere syntax.

Je kunt ook gwoon een method schrijven voor smarty genaamd 'escape' waarin je hetzelfde doet. Je krijgt dan {$users[$i]['name']|escape} of {$users.$i.name|escape} Ik zie het verschil niet, afgezien van dat het korter is.

Het is al gezegd, maar wat voor brakke frontenders heb je dan? Je belangrijkste code zit hoop ik in je controllers/models/services waar ze niet hoeven te kijken. En een leercurve is er natuurlijk niet echt, je leert een syntax aan die waar je alleen binnen Smarty wat aan hebt. De echte php syntax is veel waardevoller om te kennen.

In de strikter gescheiden bedrijven is het noodzaak dat de front-enders doen waar ze goed in zijn: het bouwen van goede html, css en javascript. Ze hoeven de php-syntax niet te kennen, noch hebben ze er iets aan, want er zijn speciaal mensen voor betaald om wél goede code te schrijven. De tijd die je nodig hebt om php te leren is meer dan die van een template-systeem om het doodsimpele feit dat er meer phpfuncties zijn dan template-functies. Door een template-manual kun je nog wat bladeren om te kijken of er handige methodes zijn itt de php-manual die zo enorm groot is (en sommige functions enorm cryptisch genaamd) dat je wel even bezig bent.

Ik vind ook niet dat je de html volledig hoeft te scheiden van je php-code. Eigenlijk doe jij die scheiding net zo goed niet, het enige wat je doet is het in een ander jasje gieten maar stiekem komt t op t zelfde neer. Je moet alleen onderscheid maken in controller-logica en view-logica. Dat je door de resultaten gaat loopen om weer te geven hoort in je view, niet in je controller.

Ik bedoel dus dat je view uit je controller gehaald moet worden, niet dat je php uit je view gehaald moet worden. Ik dacht dat ik daarin duidelijk ben geweest, maar schijnbaar niet?
Je kunt prima php gebruiken om je view te behandelen, maar als je uitgebreide complexe logica gaat doen dan ben je gewoon fout bezig. Een view moet basic zijn en niet volzitten met code die het overzicht weghaald. De reden dat je templates gebruikt is zodat je er makkelijk veranderingen in kunt aanbrengen en structuur te brengen in je werkwijze. Als je nu weer uitvoerige php-code in je template gaat zetten dan ben je gewoon verkeerd bezig.
Loopen door resultaten is iets wat perfect in je view thuishoort, maar het samenvoegen van arrays is op het randje. Entries uit de array gaan zitten veranderen (bijv entries uit de array gooien of data toevoegen aan de array) is al over de rand, dat hoort niet.

.oisyn schreef op donderdag 28 oktober 2010 @ 11:20:
Grappig dat er dus blijkbaar voor PHP-programmeurs een andere syntax nodig is om ervoor te zorgen dat ze geen prutscode produceren, terwijl het in geen enkele andere taal een probleem is om de view-laag in dezelfde taal te implementeren. Zegt dat iets over de PHP-programmeurs, of eigenlijk iets over de validiteit van het argument?

Zoals gezegd is de template-engine niet zozeer voor de php-programmeurs maar meer voor mensen die geen php kennen, maar wel kunnen designen en html kennen.
Het is prima mogelijk om gewoon php te gebruiken als template-engine, zolang je maar dezelfde werkwijze aanhoudt door je dataverwerking strikt gescheiden te houden van je dataweergave, iets dat hoort bij het MVC-model en niet specifiek bij een template.
De reden dat 'we' templates aanraden is omdat het gewoon een ontwikkeld product is waar wat extra features inzitten. Ik heb al eerder gezegd dat het net zo handig en makkelijk is om alles in php te doen. Het gaat om de denkwijze en niet de uitvoering. Met templates forceer je dat gedrag gewoon net wat makkelijker omdat de functionaliteit ervoor ontbreekt (bewust wordt uitgeschakeld), zeker als je net als de TS een open source applicatie ontwikkeld met andere mensen.

[Cartman!]

krvabo schreef op donderdag 28 oktober 2010 @ 13:46:
Bij mijn vorige werkgever hadden we een team van 6 backend-programmeurs, 10 php'ers en 6 front-enders. We werkten allemaal met dezelfde codestandaard en met een 'zelfgebakken' template-engine van het bedrijf. De backenders schreven het CMS, de front-enders maakten de html en css/javascript en de programmeus ontwikkelden de functionaliteit. De front-enders konden over het algemeen geen php en als ze het wel deden dan was het (uit ontwekendheid) gewoon een rotzooi en spaghetti-geprogrammeer.

Dan is dat een ander probleem. Want of je ze nu leert omgaan met de basis van PHP of van Smarty, het concept is hetzelfde, alleen de syntax is anders. Plus dat je jezelf in de vingers snijdt want als ze daarna een keer in PHP moeten kijken (wellicht vooruitgang) dan moeten ze dat weer opnieuw aanleren.

Als we kijken naar de TS dan is hij de maintainer van een open source applicatie. Daar werken ook mensen aan die niet zo goed zijn of mensen die geen ruk geven om enige standaard. Wellicht zijn ze het ook niet eens met "jouw standaard". Het gebruiken van een vaste structuur met een extern uitgewerkte template-engine is dan echt geen dom idee.

Maar wat is het gebruik van een andere syntax een vaste structuur? Je bereikt precies hetzelfde ermee maar dan zonder extra syntax.

Jup, maar als jij een php-bestand als view gebruikt wordt het gewoon makkelijker gedaan 'als bugfix' of uit ontwetendheid. In Smarty kun je bijvoorbeeld het gebruik van de {php}-tag blokkeren, waardoor het gewoon simpelweg niet mogelijk wordt om het in je view te plaatsen.

Dat is aan de programmeur, wellicht werken er bij jou in je team alleen maar prutsers

Uiteraard kun je alsnog je view in de controller gooien op manier die je zegt, maar dan heb je het gewoon nog niet helemaal begrepen (de programmeur die dat doet). Het is gewoon erg makkelijk om een stukje control-logica in de view te zetten als het een php-bestand is. Dan wordt het gewoon uitgevoerd, in een template-bestand niet.

je view in de controller gooien je moet gewoon weten wat controller logica is en wat view logica. Het loopen van je lijstje entities hoort bij je view logica, het ophalen van de entities zelf in je controller.

En het mergen van data hoort nou juist imho niet in een view. Een view hoort zo to the point mogelijk te zijn zonder vervuiling, zodat je juist makkelijk de lay-out kunt veranderen zonder door een hoop php-code heen te moeten scrollen.

Dat hangt er maar net vanaf. Misschien wil je het in html wel mergen maar in XML niet. Als je die merge dan al in je controller doet dan ben je fucked.

De extra syntax is sinds de laatste smarty-versie grotendeels optioneel. Nu kun je ook gewoon php-syntax gebruiken voor een groot aantal functies zoals het toewijzen van een waarde aan een variabele {$var = 'foo'} of loopen {for $i=1; $i<count($array); $i++}, etc.
De extra syntax is er om het voor non-programmeurs makkelijker te maken er iets mee te doen.

Maar waarom dan? Wat is er anders aan syntax A of syntax B als iemand beiden niet kent? Leer dan gewoon de normale syntax direct aan, heb je veel meer aan.

En ik zeg ook niet dat Smarty hier de enige in is, wellicht werkt Zend Framework ook wel geweldig, dat weet ik niet daar ik het nooit heb gebruikt. Het is gewoon 'een van de'.

Zend Framework is ook geen template engine, het biedt een volledige MVC-structuur die je naar hartelust kunt aanpassen. Je zou eventueel ook smarty kunnen gebruiken icm. ZF mocht jij dat willen.

Dat kan, maar smarty kan dat dus ook. Hij cachet dan de html-output waardoor je gewoon statische files serveert voor een x-periode. Natuurlijk kun je native ook cachen, dat doe ik ook, maar het is gewoon een van de features die je met een template-engine makkelijk kunt doen. Voor beginnende programmeurs is het bijvoorbeeld erg handig om snel wat meer performance te krijgen uit hun website zonder na te hoeven denken over een cache-systeem.

Persoonlijk vind ik cache een beetje een loze discussie in deze.

In smarty kun je ook gebruik maken van de $users[$i]['name'] syntax. Zoals hierboven geschreven is het dus een andere syntax om het makkelijker te maken voor non-phpers en niet zozeer voor php-programmeurs. Dáárom is er een andere syntax.

Handig, nog meer soorten mogelijke syntax, daar wordt het toch juist onduidelijk van? Ik herhaal mezelf weer even: leer je frontender gewoon direct de echte syntax aan, wellicht ontpopt hij/zij zich nog tot deskindige in PHP.

Je kunt ook gwoon een method schrijven voor smarty genaamd 'escape' waarin je hetzelfde doet. Je krijgt dan {$users[$i]['name']|escape} of {$users.$i.name|escape} Ik zie het verschil niet, afgezien van dat het korter is.

Precies, dus kun je t net zo goed direct native schrijven, ziet er veel logischer uit ook functie(waarde) ipv. waarde|functie.

In de strikter gescheiden bedrijven is het noodzaak dat de front-enders doen waar ze goed in zijn: het bouwen van goede html, css en javascript. Ze hoeven de php-syntax niet te kennen, noch hebben ze er iets aan, want er zijn speciaal mensen voor betaald om wél goede code te schrijven. De tijd die je nodig hebt om php te leren is meer dan die van een template-systeem om het doodsimpele feit dat er meer phpfuncties zijn dan template-functies. Door een template-manual kun je nog wat bladeren om te kijken of er handige methodes zijn itt de php-manual die zo enorm groot is (en sommige functions enorm cryptisch genaamd) dat je wel even bezig bent.

Hoe moeilijk kan t zijn dan? Pak dan de manual van smarty en wijzig de syntax daarvan in echte php-code als je frontenders te lui zijn om te leren.

Ik bedoel dus dat je view uit je controller gehaald moet worden, niet dat je php uit je view gehaald moet worden. Ik dacht dat ik daarin duidelijk ben geweest, maar schijnbaar niet?

Wie heeft het over view uit je controller halen? Ik heb gewoon een losse view en een losse controller. De discussie gaat over native php in je view tov. een extra tussenlaag met andere syntax.

Je kunt prima php gebruiken om je view te behandelen, maar als je uitgebreide complexe logica gaat doen dan ben je gewoon fout bezig. Een view moet basic zijn en niet volzitten met code die het overzicht weghaald. De reden dat je templates gebruikt is zodat je er makkelijk veranderingen in kunt aanbrengen en structuur te brengen in je werkwijze. Als je nu weer uitvoerige php-code in je template gaat zetten dan ben je gewoon verkeerd bezig.

Dat ben ik met je eens, wederom zie ik geen verschil waarom smarty dan beter is.

Loopen door resultaten is iets wat perfect in je view thuishoort, maar het samenvoegen van arrays is op het randje. Entries uit de array gaan zitten veranderen (bijv entries uit de array gooien of data toevoegen aan de array) is al over de rand, dat hoort niet.

zoals ik net zei, dat kan per view verschillend zijn (json, xml, html)

Zoals gezegd is de template-engine niet zozeer voor de php-programmeurs maar meer voor mensen die geen php kennen, maar wel kunnen designen en html kennen.
Het is prima mogelijk om gewoon php te gebruiken als template-engine, zolang je maar dezelfde werkwijze aanhoudt door je dataverwerking strikt gescheiden te houden van je dataweergave, iets dat hoort bij het MVC-model en niet specifiek bij een template.

Daar zijn we het toch over eens dan? Jij introduceert er echter nog een laag tussen html en php in: smarty.

De reden dat 'we' templates aanraden is omdat het gewoon een ontwikkeld product is waar wat extra features inzitten. Ik heb al eerder gezegd dat het net zo handig en makkelijk is om alles in php te doen. Het gaat om de denkwijze en niet de uitvoering. Met templates forceer je dat gedrag gewoon net wat makkelijker omdat de functionaliteit ervoor ontbreekt (bewust wordt uitgeschakeld), zeker als je net als de TS een open source applicatie ontwikkeld met andere mensen.

Bewust dingen uitschakelen voor je programmeurs? Ik vertrouw m'n team gewoon, ook m'n frontenders. Die kwamen namelijk als specialisten binnen in html/css/js en nu kunnen ze ook gewoon php-en, heerlijk.

[Anoniem: 35775]

Om maar even antwoord op de gestelde vraag te geven en niet de Smarty vs Php etc discussie weeeer aan te gaan.

Veel frameworks gebruiken voor het genereren van formulieren en formulier velden een Decorator constructie of maken gebruik van ViewHelpers (Zend doet beide eigenlijk) , vaak is dit een fijne en stabiele oplossing omdat je Decorators kan 'stacken' dus meerdere over elkaar heen kan laten draaien. Het genereren van een HTML element en de formulier logica zoals validatie staat dan ook los van het decoreren (lees: stylen) van het formulier.

Het decorator pattern is net zo'n goede manier om display-logic te scheiden van business(logic) als het gebruik van template engines,

[krvabo]

Cartman! schreef op donderdag 28 oktober 2010 @ 14:39:
[...]

Ik ga er even niet meer punt voor punt op in, aangezien dat een hoop werk is

De reden da ik smarty aandraag is puur voor de TS. Hij heeft een opensource applicatie en wil dit graag structureren. Aangezien (volgens .oisyn ) het merendeel van de php-programmeurs prutsers zijn (zo denk ik er overigens ook over) is het een goed idee de scheiding tussen de view en de controller strikt te maken en niet teveel te verwachten van afspraken. Ik raad geen Smarty aan omdat 'in mijn team alleen prutsers zitten'. Ik zeg het omdat in de open source wereld het lastig is om goede programmeurs geïnteresseerd te krijgen in je project dat ze helpen. overigens werk ik ook niet meer in een team, maar nu bij een ander bedrijf zonder front-enders

Ik zeg nergens dat Smarty (of welke template-engine dan ook) béter is dan het gebruik van pure php, ik zeg alleen dat het enkele (niet altijd toepasbare) voordelen heeft. Het heeft ook zeker nadelen.

Met 'view in de controller' bedoel ik het ouputten of assignen van html in de controller.

Je hebt gelijkt wat betreft het mergen van arrays als het verschilt per view.

De cache-discussie was er op gespitst om een van de voordelen van Smarty te laten zien.

In essentie zijn we het eens, maar jij vertrouwt op afspraken binnen een vast team, terwijl ik gericht ben op de mogelijkheid van slechte(re) programmeurs. Ik ben van mening dat het soms de moeite waard kan zijn om wat performance op te geven voor een beetje meer controle op de code.

[.oisyn]

krvabo schreef op donderdag 28 oktober 2010 @ 19:11:
Aangezien (volgens .oisyn ) het merendeel van de php-programmeurs prutsers zijn

Ho ho, dat heb ik nooit beweerd. Dat destilleerde ik uit jouw argumenten . Overigens denk ik wel dat dat waar is.

[ Voor 17% gewijzigd door .oisyn op 29-10-2010 00:17 ]

[krvabo]

.oisyn schreef op vrijdag 29 oktober 2010 @ 00:17:
[...]

Ho ho, dat heb ik nooit beweerd. Dat destilleerde ik uit jouw argumenten . Overigens denk ik wel dat dat waar is.

offtopic:
Ik lees wel meer van je berichten
Het is natuurlijk ook (aantoonbaar) zo dat het merendeel van phpcode ondermaats is.

[juggle]

Ik wil mij graag aansluiten bij het antwoord van thioz.

In mijn eigen framework maak ik gebruik van view helpers. Dit zijn classes die je in de view laadt en je veel gebruikte html voor je parsed. In mijn ogen moet je ten alle tijden vermijden dat je html in je controllers gaat stoppen. Hier zijn ze absoluut niet voor bedoeld.

Een voorbeeld van een view helper kan bijvoorbeeld zijn:

PHP:

class form_helper {

    public function textfield($p_sName, $p_sValue = '', $p_aAttributes = '')
    {
        print('<input type="text" value="'.$p_sValue.'" '.$this->_parse_attributes($p_aAttributes).' />');
    }

    private function _parse_attributes($p_aAttributes)
    {
        $sHtml = '';
        if (is_array($p_aAttributes))
        {
            foreach ($p_aAttributes as $sKey => $sValue)
            {
                $sHtml .= $sKey.'="'.$sValue.'" ';
            }
        }
        return $sHtml;
    }

}

Bovenstaand is een zeer versimpeld voorbeeld maar je ziet hoe krachtig dit is. In je template kun je dan simpelweg zeggen:

PHP:

$form = new form_helper;
$form->textfield('voorbeeld', 'test', array('id' => 'textfield', 'class' => 'txt');

In mijn eigen framework kun je in de controllers aangeven welke helpers je wil gaan gebruiken en die zijn dan in alle views voor die controller beschikbaar.

[ Voor 9% gewijzigd door juggle op 29-10-2010 01:09 ]

[Wolfboy]

krvabo schreef op vrijdag 29 oktober 2010 @ 00:23:
[...]

offtopic:
Ik lees wel meer van je berichten
Het is natuurlijk ook (aantoonbaar) zo dat het merendeel van phpcode ondermaats is.

offtopic:
Imho kan je gerust zeggen dat het meerendeel van de programmeurs prutsers zijn.
Maar PHP spant de kroon kwa goed/slecht ratio lijkt het

Mja... to be fair, waarschijnlijk prutsen we allemaal wel op z'n tijd