[PHP] Wat is beter, binnen of buiten tags.

[BLACKfm]

Hallo,

Ik ben bezig onze bedrijfswebsite wat op te frissen. De eerste build bestaat nog uit tables en ik wil de boel geheel omzetten naar divjes.

Het framewerk heb ik nu, maar nu moet de inhoud er weer terug in. Er wordt veel informatie uit de database gehaald en daarom komt er dus geregeld PHP om de hoek kijken.

Ik wil het graag zo compact mogelijk hebben, mijn redenering is dat kleine bestanden ook sneller geladen worden. Maar wellicht zit ik daar naast.

Graag zou ik horen welke manier efficiënter is;

PHP:

<?

$var = 'foo';

echo 'Dit is een stukje html '.$var.' en dit het einde ervan';
echo 'Dit is dan de 2e regel '.$var.' en dit het einde ervan';
echo 'Dit is dan de 3e regel '.$var.' en dit het einde ervan';

?>

of

PHP:

<? $var = 'foo'; ?>

Dit is een stukje html <? echo $var ?> en dit het einde ervan
Dit is dan de 2e regel <? echo $var ?> en dit het einde ervan
Dit is dan de 3e regel <? echo $var ?> en dit het einde ervan

In het eerste geval ben ik meer tekens, en dus bestandsgrootte (jah, bits...), kwijt en in het 2e geval wordt de enkel de het PHP gedeelte aangesproken als dat moet.

Behalve dat het wat minder fout gevoelig is als je de PHP aan 1 stuk door typt, is mijn vraag wat nou het beste is zonder daar nou gelijk een persoonlijke voorkeur aan te hangen.

[Aloys]

Hangt wat mij betreft van het bestand af. Is het een view, dan heeft de html de overhand en moeten de uit php geladen stukjes even kort in tags. Is het een php file waarbij toevalig een klein beetje html/output komt kijken, dan gewoon netjes een string printen/echo'en in php.

Vergeet overigens niet dat je wel degelijk `<?php echo $var ?>` moet doen (of `<?= $var ?>`).

[BLACKfm]

Aloys schreef op zondag 13 januari 2013 @ 01:29:
Vergeet overigens niet dat je wel degelijk `<?php echo $var ?>` moet doen (of `<?= $var ?>`).

Die had ik net al ge-edit. Ik moest er even over twijfelen , is al een jaartje dat ik niet meer actief ben XD.

In principe komt alle info uit een database, dus het is alleen maar HTML+CSS opmaak en de inhoud komt uit de database.

[Compizfox]

Ik weet zo niet wat sneller is, maar wat ik zou doen hangt af van hoeveel PHP en HTML er in het bestand staat.

In je voorbeeld heb je voornamelijk plain text en 3 variabelen die geprint moeten worden. Ik zou dan voor het onderste voorbeeld gaan.

Aloys schreef op zondag 13 januari 2013 @ 01:29:
Vergeet overigens niet dat je wel degelijk `<?php echo $var ?>` moet doen (of `<?= $var ?>`).

Hoe bedoel je dat?

code:

<p><?php echo($var); ?> </p>

klopt toch prima?

[ Voor 36% gewijzigd door Compizfox op 13-01-2013 01:35 ]

[BLACKfm]

Naja, plain tekts, laat ik dat maar houden op de normale HTML en teksten.

code zoals in het echie..

PHP:

<? $var = 'foo'; ?>

<div class="container">
  <div class="sub">
     <p> Dit is de eerste regel <? echo $var ?> en maak er dan maar 3 van <br />
     </p>
  </div>
</div>

of

PHP:

<?

$var = 'foo';

echo '<div class="container">';
  echo '<div class="sub">';
     echo '<p> Dit is de eerste regel '.$var.' en maak er dan maar 3 van <br />';
     echo '</p>';
  echo '</div>';
echo '</div>';

[Compizfox]

Ook dan zou ik voor de bovenste kiezen. Voelt gewoon semantischer imho.

[F.West98]

Ik doe altijd de bovenste maar dan zo:

PHP:

<? $var = 'foo'; ?>

<div class="container">
  <div class="sub">
     <p> Dit is de eerste regel <?=$var?> en maak er dan maar 3 van <br />
     </p>
  </div>
</div>

Nog sneller

[mrc4nl]

anders moet je al die html ook escapen, ik zou het gewoon hele lappen html in de file zetten en de php ertussen waar nodig. t hang zoals eerder gezegd is gewoon af wat er meer voorkomt php of html

[Douweegbertje]

Tja, wat is 'beter'.
Even als nerd moet ik zeggen dat het allebei niet zo geweldig is, wellicht zou je eens kunnen kijken naar een leuke template parser.

Jouw voorbeelden geven namelijk nog maar een verkapt beeld.
Als ik het zelf even inschat, verwacht ik dat je allerlei code nog hebt om;
- kijken welke pagina er is
- welke content er gehaald moet worden
- variabelen setten

Eigenlijk best veel PHP.

Daarom zijn template parser zou fijn, omdat je dan van alles in een verkapte controller kan zetten, en dit mee kan geven aan je 'view' / template.
Deze is in feite plain HTML met dan dingen als (even SMARTY als voorbeeld)

code:

//php
<?=$foo?>

<?=$foo['bar']?>

<?php foreach($foo as $bar): ?>
...
<?php endforeach; ?>


//smarty
{$foo}

{$foo.bar}

{foreach $foo as $bar}
...
{/foreach}

Dit is al 10x netter + overzichtelijker.

Maar om dan maar concreet op je vraag antwoord te geven:

Volledige stukken HTML laten echo'en ziet er gewoon vies uit, en heeft eigenlijk geen reden
Hoe zou je bestand er het beste uit zien:

code:

<?php
//INIT allerlei dingen
require_once('functie.dit1.php');
require_once('functie.dit2.php');
require_once('functie.dit3.php');
// Set wat variabelen
$blaat = getPage();
$foo = getContent();
$bar = getRandomIets();

// Einde
?>
<html>
<head>
</head>
<body>

<p> hier gewoon plain html doen en dan <?php echo $blaat; ?> </p>
<p> Over het algemeen worden shorttags zoals <?=$blaat?> 'vies' gevonden. </p>

Oftewel schrijf je PHP vooral bovenaan, om vervolgens je php te 'sluiten' en verder te gaan naar HTML als basis.
In een iteratie, en/of een loop in je HTML zou je eventueel weer je php kunnen openen en sluiten, vooral als het om veel HTML code gaat. Is het bijvoorbeeld maar 1 lijntje HTML, dan zou ik het echo'en.

[ Voor 9% gewijzigd door Douweegbertje op 13-01-2013 02:12 ]

[BtM909]

Een PHP vraag zoals deze hoort ook gewoon in Programming, dus tikkie terug Jaap!

---

Overigens is het in beginsel netter om voor optie 2 te gaan (in je openingspost). Dit vanwege o.a.

For outputting large blocks of text, dropping out of PHP parsing mode is generally more efficient than sending all of the text through echo or print.

[ Voor 57% gewijzigd door BtM909 op 13-01-2013 02:19 ]

[Damic]

Meen je dat nu, is dit dan niet handiger?

PHP:

<?php
$var = 'foo';
echo '<div class="container">
 <div class="sub">
  <p> Dit is de eerste regel '.$var.' en maak er dan maar 3 van <br /></p>
  </div>
</div>';
?>

en zoals Btm al heeft gezegd volgende is dan beter

PHP:

<?= $var = 'foo';?>
<div class="container">
 <div class="sub">
  <p> Dit is de eerste regel <?= $var ?> en maak er dan maar 3 van <br /></p>
  </div>
</div>

[ Voor 33% gewijzigd door Damic op 13-01-2013 02:26 ]

[Compizfox]

mrc4nl schreef op zondag 13 januari 2013 @ 01:49:
anders moet je al die html ook escapen, ik zou het gewoon hele lappen html in de file zetten en de php ertussen waar nodig. t hang zoals eerder gezegd is gewoon af wat er meer voorkomt php of html

Zeker een goed argument, die was ik nog vergeten!

[Klojum]

F.West98 schreef op zondag 13 januari 2013 @ 01:49:
Ik doe altijd de bovenste maar dan zo:

PHP:

<? $var = 'foo'; ?>

<div class="container">
  <div class="sub">
     <p> Dit is de eerste regel <?=$var?> en maak er dan maar 3 van <br />
     </p>
  </div>
</div>

Nog sneller

Volgens mij is het al een tijdje geleden dat de default mogelijkheid van shorttags <? ...?> is uitgeschakeld, en dat elke keer gewoon de volledige tags gebruikt moeten worden. Dus met <?php .. ?>. Met een installatie van een recente PHP-versie gaat jouw script dus niet (goed) werken.

[sgt frankieboy]

Ik zou deze manier kiezen.

PHP:

echo <<<EOD

<span>$var</span>
<div>$array[banaan]</div>

EOD;

Het is niet nodig om de vars in php tags te zetten.

[Aham brahmasmi]

sgt frankieboy schreef op zondag 13 januari 2013 @ 05:26:
Ik zou deze manier kiezen.

PHP:

echo <<<EOD

<span>$var</span>
<div>$array[banaan]</div>

EOD;

Het is niet nodig om de vars in php tags te zetten.

Dat is de "heredoc" syntax. http://php.net/manual/en/language.types.string.php
Het is soms handig maar het is wel belangrijk om te weten hoe het geparsed wordt als je enkele of dubbele aanhalingtekens gebruikt, en soms moet je accolades { } rond variabelen plaatsen. Hier wat discussie: http://stackoverflow.com/...son-to-use-heredoc-in-php

[Cartman!]

douweegbertje schreef op zondag 13 januari 2013 @ 02:10:
<snip>
Oftewel schrijf je PHP vooral bovenaan, om vervolgens je php te 'sluiten' en verder te gaan naar HTML als basis.
In een iteratie, en/of een loop in je HTML zou je eventueel weer je php kunnen openen en sluiten, vooral als het om veel HTML code gaat. Is het bijvoorbeeld maar 1 lijntje HTML, dan zou ik het echo'en.

Nofi, maar dat is misschien zo in een hobbyproject maar met de grote MVC frameworks is er gewoon een scheiding gemaakt, PHP in je view is geen enkel probleem. Wat een alternatieve syntax in een template engine voor nut heeft heb ik nooit begrepen.

TS: Ik zou sowieso gaan voor optie 2, veel leesbaarder.

[Gomez12]

douweegbertje schreef op zondag 13 januari 2013 @ 02:10:
Tja, wat is 'beter'.
Even als nerd moet ik zeggen dat het allebei niet zo geweldig is, wellicht zou je eens kunnen kijken naar een leuke template parser.

Sinds wanneer is php geen template parser meer?

[Douweegbertje]

Gomez12 schreef op zondag 13 januari 2013 @ 10:29:
[...]

Sinds wanneer is php geen template parser meer?

Sinds wanneer heeft php functies voor templates?
Ja, php en HTML outputten, dat kan en is natuurlijk logisch.

Maar als topicstarter aangeeft

Het framewerk heb ik nu

En je gaat als framework volledige HTML er in zetten, mhah.. dat is één oplossing die KAN.. maar zoals ik aangaf :

Even als nerd moet ik zeggen dat het allebei niet zo geweldig is

Onderscheid maken tussen je logic en templates is namelijk zeer wenselijk.
Wil je nog niet een MVC framework gebruiken, dan is een template parser een goede tussen stap.

[PatrickH89]

douweegbertje schreef op zondag 13 januari 2013 @ 10:53:


Sinds wanneer heeft php functies voor templates?

Sinds altijd? Wat kan ik met smarty meer dan met PHP? In smarty zul je toch ook nog steeds moeten foreachen en printen? Smarty biedt hiervoor alleen een alternatieve syntax. In mijn ogen nutteloos, omdat mensen dan weer een nieuwe (template) taal moeten leren terwijl PHP al deze functies ook gewoon biedt (+extra overhead).

Hierin zeg ik overigens niet dat views aparte files geen aparte files moeten zijn om logic en views gescheiden te houden, maar dat heeft dan ook niets te maken met welke template parser je gebruikt.

[ Voor 16% gewijzigd door PatrickH89 op 13-01-2013 11:01 ]

[Grijze Vos]

douweegbertje schreef op zondag 13 januari 2013 @ 10:53:

Onderscheid maken tussen je logic en templates is namelijk zeer wenselijk.
Wil je nog niet een MVC framework gebruiken, dan is een template parser een goede tussen stap.

Dat onderscheid tussen logic en templates kun je nog steeds maken zonder smarty, dat kan ook gewoon met php.

[Douweegbertje]

Kijk, volgens mij missen jullie mijn punt.

Ik geef aan dat het kan, zelfs heel goed in PHP.
Wat ik echter probeer, is om wat extra diepgaande tips te geven voor de topic starter.
Als jullie zeggen dat je alles maar klakkeloos in PHP moet gooien, alles in PHP en het liefst met echo dit, echo dat.. ok prima maar dan stop ik sowieso al de discussie.

Ik probeer uit te leggen dat je moet nadenken om je LOGIC gescheiden te houden van je TEMPLATES.
Als voorbeeld geef ik SMARTY, maar al doe je het in PHP zelf (waarbij je zelf alles nog moet schrijven dan) dan is dat natuurlijk ook prima.

Ik ben ook bewust dat SMARTY verder niet veel boeiends toevoegt en in vele gevallen je applicatie alleen maar meer bloated maakt. Echter is SMARTY (of elke andere template parsen) een goede manier om met een bestaand 'verkapte framework' te werken waarbij de drempel niet al te hoog is. Zo leer je alvast dingen te scheiden om vervolgens een keer over te stappen naar een MVC framework zoals CodeIgniter of 'insert random MVC framework'.

Want laten we eerlijk zijn, wie zou voor zijn werk in topicstarter zijn framework updates willen gaan uitvoeren? Ik niet, ik neem dan liever ontslag.
Daarom dus mijn tips (want antwoord op zijn vraag had ik al gegeven), in de hoop dat hij misschien er wat van kan leren en mooiere code kan gaan maken. 9/10 snap je het wel, maar weet je niet hoe iets werkt

[Ultimation]

Ligt eraan wat je verstaat onder beter. Daarnaast beter hoeft niet efficiënter te zijn.

PHP is serverside code, dus hoe minder de code de server hoeft uit te voeren des te beter het is voor de resources van de server.
Als je leesbaarheid als beter ziet dan zou je misschien voor de 1 optie te gaan.
Als je voor minder fout gevoelig wilt gaan is de 2e optie misschien de betere.

[armageddon_2k1]

PatrickH89 schreef op zondag 13 januari 2013 @ 10:59:
[...]


Sinds altijd? Wat kan ik met smarty meer dan met PHP? In smarty zul je toch ook nog steeds moeten foreachen en printen? Smarty biedt hiervoor alleen een alternatieve syntax. In mijn ogen nutteloos, omdat mensen dan weer een nieuwe (template) taal moeten leren terwijl PHP al deze functies ook gewoon biedt (+extra overhead).

Hierin zeg ik overigens niet dat views aparte files geen aparte files moeten zijn om logic en views gescheiden te houden, maar dat heeft dan ook niets te maken met welke template parser je gebruikt.

Een taal die toevallig ook voor views gebruikt kan worden en een dedicated templating engine (Twig, Smarty) zijn echt compleet andere dingen. Het is inderdaad waar dat je met PHP precies hetzelfde kan wat je met Twig en Smarty ook kan, maar de functies die de laatste twee extra hebben voegen ontzettend veel toe.

Denk aan template inheritance en sandboxing bijvoorbeeld. Deze dingen kan je ook prima in PHP implementeren, maar waarom zou je? De taal van Twig is zo ontzetend simpel en hij rendert ook nog eens naar bloedsnelle, veilige PHP.

Uiteraard moet je voor simpele views lekker plain PHP gebruiken, maar indien het iets complexer wordt zou je gek zijn als je geen Twig oid gebruikt. Het standaard argument dat er overhead bij zou zijn gaat niet op, omdat het voor productie geprerenderd wordt naar pure PHP, en geeft alleen maar aan dat je nooit serieus met zulke oplossingen gewerkt hebt.

[HuHu]

Persoonlijk zie ik geen nut om voor views een aparte syntax te hanteren, die stiekem onderwater weer nieuwe PHP code genereert. Alles wat smarty of twig kan, kun je ook prima in PHP code doen. Neem bijvoorbeeld Zend_View, een template systeem dat gewoon met PHP werkt in plaats van een zelfverzonnen syntax (inclusief eigen leercurve).

Als TS zelf een simpel framework heeft gebouwd, dan zou ik gewoon adviseren de programma logica en de view gescheiden te houden. Dit kan desnoods in één PHP bestand:

PHP:

include 'db.php';

// doe wat dingen
$var = 5;
$appel = 'banaan';
// nog meer logica of berekeningen
$aa = 5 * 6 + 3;

// --- HIERONDER ALLEEN VIEW CODE --- \\
?>
<html>
Dit is een stukje html <?php echo $var; ?> en dit het einde ervan 
Dit is dan de 2e regel <?php echo $appel; ?> en dit het einde ervan 
</html>

Als je dan voor jezelf netjes de scheiding hanteert, dan lijkt me dat voor een simpel framework al voldoende. Het gaat meer om de scheiding van logica en opmaak, dan hoe je dat precies doet.

[PatrickH89]

armageddon_2k1 schreef op zondag 13 januari 2013 @ 12:04:
Het standaard argument dat er overhead bij zou zijn gaat niet op, omdat het voor productie geprerenderd wordt naar pure PHP, en geeft alleen maar aan dat je nooit serieus met zulke oplossingen gewerkt hebt.

Hoho, simpele conclusies daar. Weer een gevalletje 'mijn mening is een feit'?

Ik heb 'serieus met zulke oplossingen gewerkt', maar ik vond ze persoonlijk vrij tedious en het zijn vooral zaken die PHP ook prima zelf kan. Ook template inheritance en sandboxing zijn vrij eenvoudig te implementeren in PHP. Dat je daaruit de conclusie trekt dat ik nooit serieus met zulke oplossingen heb gewerkt is uiteraard complete onzin.

Ik houd persoonlijk niet van deze manier van discussiëren, ieder zijn eigen mening lijkt me?

[NMe]

Jongens, templating engines bovenop PHP voegen wat features toe zoals sandboxing en.caching. Dat kun je uiteraard ook gewoon zelf in PHP bouwen als je specifieke eisen hebt of inderdaad domweg overslaan als je die features niet nodig hebt. Of je dat al dan niet doet verschilt van bedrijf tot bedrijf, van project tot project en van programmeur tot programmeur. In zijn algemeenheid een ander proberen te overtuigen van je eigen gelijk is in deze discussie net zoiets als iemand ervan proberen te overtuigen dat aardbeien en spinazie samen heel lekker zijn.

[armageddon_2k1]

PatrickH89 schreef op zondag 13 januari 2013 @ 12:26:
[...]


Hoho, simpele conclusies daar. Weer een gevalletje 'mijn mening is een feit'?

Ik heb 'serieus met zulke oplossingen gewerkt', maar ik vond ze persoonlijk vrij tedious en het zijn vooral zaken die PHP ook prima zelf kan. Ook template inheritance en sandboxing zijn vrij eenvoudig te implementeren in PHP. Dat je daaruit de conclusie trekt dat ik nooit serieus met zulke oplossingen heb gewerkt is uiteraard complete onzin.

Ik houd persoonlijk niet van deze manier van discussiëren, ieder zijn eigen mening lijkt me?

Dit is ook mijn mening Mijn mening is dat ik vaak genoeg mee heb gemaakt dat mensen elke keer weer het hele wiel opnieuw uitvinden omdat Twig/Smarty/whatever overhead/onhandig/moeilijk/nieuw/NIH is en ze vervolgens alle goede dingen die die tot-in-den-treure-doorgeteste producten niet hebben en alle bugs en architectuurfouten die bovenstaanden al opgelost hebben wel hebben.
Dat dat in jouw geval niet zo is, mea culpa, maar ik mag nog steeds mijn eigen conclusie wel trekken dat ik bijna altijd meegemaakt heb dat het wel zo is

NMe schreef op zondag 13 januari 2013 @ 12:45:
Jongens, templating engines bovenop PHP voegen wat features toe zoals sandboxing en.caching. Dat kun je uiteraard ook gewoon zelf in PHP bouwen als je specifieke eisen hebt of inderdaad domweg overslaan als je die features niet nodig hebt.

Maar wat is toch die drang van veel mensen dan om het zelf te bouwen? Elke doorgewinterde developer weet dat je dan een hele lading problemen op de hals haalt, of maakt het niet uit omdat de klant toch betaald? Als het project hele specifieke eisen heeft dan kan ik erin komen, maar een templating engine als Twig is zo licht en zo generiek dat je een hele goede reden moet hebben om die na te gaan bouwen.

In zijn algemeenheid een ander proberen te overtuigen van je eigen gelijk is in deze discussie net zoiets als iemand ervan proberen te overtuigen dat aardbeien en spinazie samen heel lekker zijn.

Hold it. You're not convinced?

[ Voor 29% gewijzigd door armageddon_2k1 op 13-01-2013 13:18 ]

[Carharttguy]

HuHu schreef op zondag 13 januari 2013 @ 12:15:
Persoonlijk zie ik geen nut om voor views een aparte syntax te hanteren, die stiekem onderwater weer nieuwe PHP code genereert. Alles wat smarty of twig kan, kun je ook prima in PHP code doen. Neem bijvoorbeeld Zend_View, een template systeem dat gewoon met PHP werkt in plaats van een zelfverzonnen syntax (inclusief eigen leercurve).

Als TS zelf een simpel framework heeft gebouwd, dan zou ik gewoon adviseren de programma logica en de view gescheiden te houden. Dit kan desnoods in één PHP bestand:

PHP:

include 'db.php';

// doe wat dingen
$var = 5;
$appel = 'banaan';
// nog meer logica of berekeningen
$aa = 5 * 6 + 3;

// --- HIERONDER ALLEEN VIEW CODE --- \\
?>
<html>
Dit is een stukje html <?php echo $var; ?> en dit het einde ervan 
Dit is dan de 2e regel <?php echo $appel; ?> en dit het einde ervan 
</html>

Als je dan voor jezelf netjes de scheiding hanteert, dan lijkt me dat voor een simpel framework al voldoende. Het gaat meer om de scheiding van logica en opmaak, dan hoe je dat precies doet.

Hoewel het zo wel netjes is, is het wel lastig om dat in de praktijk toe te passen, als je bijvoorbeeld data uit een DB wilt weergeven in een tabel, moet je zoiezo al omgekeerd werken, want dan moet je jouw rijen aanmaken via een for of een while of zoiets.

Ik wil gewoon maar zeggen: theorie != praktijk.

[PatrickH89]

Ik doe persoonlijk nooit aan opnieuw het wiel uitvinden (tenzij het 'wiel' nog niet bestaat of niet voldoet), maar engines als Smarty en Twig zijn voor mij gewoon niet de tools die ik nodig heb (hoewel ik Twig al een stuk interessanter vind dan Smarty).

'Template inheritance' (om een voorbeeld te noemen) of wat voor hippe term je eraan wilt geven zitten voor mij al in de frameworks waar ik over het algemeen mee werk zonder dat ik er een vage syntax bij krijg wat juist alleen maar complexiteit toevoegt (hiermee bedoel ik niet dat ik het moeilijk vind, maar gewoon nutteloos).

Dan mag je altijd de conclusie trekken dat 'je bijna altijd hebt meegemaakt dat dat wel zo is', maar de conclusie die je op basis van mijn post niet kunt trekken is dat ik nooit serieus heb gewerkt met oplossingen als Smarty en Twig.

[HuHu]

Carharttguy schreef op zondag 13 januari 2013 @ 14:19:
[...]


Hoewel het zo wel netjes is, is het wel lastig om dat in de praktijk toe te passen, als je bijvoorbeeld data uit een DB wilt weergeven in een tabel, moet je zoiezo al omgekeerd werken, want dan moet je jouw rijen aanmaken via een for of een while of zoiets.

Ik wil gewoon maar zeggen: theorie != praktijk.

Valt mee hoor:

PHP:

include 'db.php'; 

$rowSet = $db->query("SELECT id, naam, geboortedatum FROM persoon WHERE YEAR(geboortedatum) = '1986';");

// --- HIERONDER ALLEEN VIEW CODE --- \\ 
?> 
<table> 
  <tr>
    <th>ID</th>
    <th>naam</th>
    <th>geboortedatum</th>
  </tr>
<?php foreach ($rowSet as $row) : ?>
  <tr>
    <td><?php echo $row['id']; ?></td>
    <td><?php echo $row['naam']; ?></td>
    <td><?php echo $row['geboortedatum ']; ?></td>
  </tr>
<?php endforeach; ?>
</table>

Je moet gewoon consequent zijn in het scheiden van logica en weergave.

[Saven]

douweegbertje schreef op zondag 13 januari 2013 @ 02:10:
Tja, wat is 'beter'.
Even als nerd moet ik zeggen dat het allebei niet zo geweldig is, wellicht zou je eens kunnen kijken naar een leuke template parser.

Jouw voorbeelden geven namelijk nog maar een verkapt beeld.
Als ik het zelf even inschat, verwacht ik dat je allerlei code nog hebt om;
- kijken welke pagina er is
- welke content er gehaald moet worden
- variabelen setten

Eigenlijk best veel PHP.

Daarom zijn template parser zou fijn, omdat je dan van alles in een verkapte controller kan zetten, en dit mee kan geven aan je 'view' / template.
Deze is in feite plain HTML met dan dingen als (even SMARTY als voorbeeld)

code:

//php
<?=$foo?>

<?=$foo['bar']?>

<?php foreach($foo as $bar): ?>
...
<?php endforeach; ?>


//smarty
{$foo}

{$foo.bar}

{foreach $foo as $bar}
...
{/foreach}

Dit is al 10x netter + overzichtelijker.

Maar om dan maar concreet op je vraag antwoord te geven:

Volledige stukken HTML laten echo'en ziet er gewoon vies uit, en heeft eigenlijk geen reden
Hoe zou je bestand er het beste uit zien:

code:

<?php
//INIT allerlei dingen
require_once('functie.dit1.php');
require_once('functie.dit2.php');
require_once('functie.dit3.php');
// Set wat variabelen
$blaat = getPage();
$foo = getContent();
$bar = getRandomIets();

// Einde
?>
<html>
<head>
</head>
<body>

<p> hier gewoon plain html doen en dan <?php echo $blaat; ?> </p>
<p> Over het algemeen worden shorttags zoals <?=$blaat?> 'vies' gevonden. </p>

Oftewel schrijf je PHP vooral bovenaan, om vervolgens je php te 'sluiten' en verder te gaan naar HTML als basis.
In een iteratie, en/of een loop in je HTML zou je eventueel weer je php kunnen openen en sluiten, vooral als het om veel HTML code gaat. Is het bijvoorbeeld maar 1 lijntje HTML, dan zou ik het echo'en.

Ga ik toch even in op je opmerking dat smarty 10x netter en overzichtelijker is. Ben het daar namelijk niet mee eens. Ben zelfs van mening dat met php shorttags overzichtelijker is, al is het dan alleen al omdat je dan code highlighting hebt en snel kunt zien waar je dynamische shizz hebt.

Daarnaast is smarty een stuk zwaarder in gebruikt dan een simpele parser. Een template parser/engine is ook niet bedoeld om php van je html te scheiden. (Niet dat je dat hebt gezegd, maar kreeg wel het idee dat je dat bedoelde)

[HuHu]

Je hebt ook highlighters voor smarty. Smarty wordt gecompileerd naar PHP code, waardoor het niet "zwaarder" is.

[NMe]

armageddon_2k1 schreef op zondag 13 januari 2013 @ 13:14:
[...]

Maar wat is toch die drang van veel mensen dan om het zelf te bouwen? Elke doorgewinterde developer weet dat je dan een hele lading problemen op de hals haalt, of maakt het niet uit omdat de klant toch betaald? Als het project hele specifieke eisen heeft dan kan ik erin komen, maar een templating engine als Twig is zo licht en zo generiek dat je een hele goede reden moet hebben om die na te gaan bouwen.

Het hele idee is dat je het niet nabouwt maar het specifiek bouwt naar je eigen wensen. Begrijp me niet verkeerd, op kantoor gebruiken we ook Smarty en gaan we een dezer dagen nog eens overstappen op Twig, maar dat wij het gebruiken wil niet zeggen dat het per definitie voor iedereen de beste oplossing is. Vandaar ook dat het zinloos is om deze discussie zo fel te voeren als sommige mensen hier aan het doen zijn.

Hold it. You're not convinced?

[armageddon_2k1]

PatrickH89 schreef op zondag 13 januari 2013 @ 14:19:
Ik doe persoonlijk nooit aan opnieuw het wiel uitvinden (tenzij het 'wiel' nog niet bestaat of niet voldoet), maar engines als Smarty en Twig zijn voor mij gewoon niet de tools die ik nodig heb (hoewel ik Twig al een stuk interessanter vind dan Smarty).

'Template inheritance' (om een voorbeeld te noemen) of wat voor hippe term je eraan wilt geven zitten voor mij al in de frameworks waar ik over het algemeen mee werk zonder dat ik er een vage syntax bij krijg wat juist alleen maar complexiteit toevoegt (hiermee bedoel ik niet dat ik het moeilijk vind, maar gewoon nutteloos).

Dan mag je altijd de conclusie trekken dat 'je bijna altijd hebt meegemaakt dat dat wel zo is', maar de conclusie die je op basis van mijn post niet kunt trekken is dat ik nooit serieus heb gewerkt met oplossingen als Smarty en Twig.

Okee, daar heb je gelijk in Bedoelde ook niet zo over te komen, maar je oorspronkelijke post kwam voor mij nogal kort door de bocht over, waardoor het leek alsof je nog nooit serieus naar zulke templating engines gekeken hebt.

[Saven]

HuHu schreef op zondag 13 januari 2013 @ 14:30:
Je hebt ook highlighters voor smarty. Smarty wordt gecompileerd naar PHP code, waardoor het niet "zwaarder" is.

maar hij laad smarty wel, al die includes etc. heb wel eens getest en scheelt toch redelijk wat in je parsetime

[Gomez12]

Saven schreef op zondag 13 januari 2013 @ 14:59:
[...]

maar hij laad smarty wel, al die includes etc. heb wel eens getest en scheelt toch redelijk wat in je parsetime

Standaard advies : Betere server nemen of meer code schrijven.

Op het moment dat dit echt gaat schelen in je parsetimes heb je gewoon een te lichte server of te weinig code.

Op een hello world example zal het vast schelen, maar op een beetje applicatie vallen de extra includes niet meer op, de laadtijd wordt weer deels overschaduwd door betere optimalizeringen in smarty dan dat jij zelf maakt. Etc etc.
Oftewel het maakt niets significants meer uit.

[HuHu]

Saven schreef op zondag 13 januari 2013 @ 14:59:
[...]

maar hij laad smarty wel, al die includes etc. heb wel eens getest en scheelt toch redelijk wat in je parsetime

Het gebruik van PHP is ook zwaar ten opzichte van een statische HTML pagina. Ik heb het wel eens getest en het scheelt toch redelijk wat in je parsetime.

[s.stok]

Smarty heb ik vroeger gebruikt (2.x versie) en ik liep eigenlijk constant tegen problemen aan waardoor ik in Smarty (wat je overigens niet in hoofdletters spelt) php moest gebruiken. Ik had goede hoop voor 3.0 maar hier zijn ze dingen gaan doen die echt nergens opslaan! Vooral het fijt dat de hele code met plakband aan elkaar zat en vreselijk langzaam werkte (omdat iedere variabel in een object werd gezet).

Sinds ik Symfony2 ben gaan gebruiken gebruik eigenlijk alleen nog Twig, de syntax is makkelijk te begrijpen, het werkt snel. En vooral: Automatic output escaping! Hoevaak je wel niet hebt gehad dat je site lek was voor XSS omdat je net één keer was vergeten te escapen? Het bied echt voordelen als Template engine vergeleken met php en zit zeer robuust in elkaar.

[Gomez12]

s.stok schreef op zondag 13 januari 2013 @ 16:01:
Sinds ik Symfony2 ben gaan gebruiken gebruik eigenlijk alleen nog Twig, de syntax is makkelijk te begrijpen, het werkt snel. En vooral: Automatic output escaping!

Yes, er zijn nog steeds genoeg php'ers die het vervloeken dat er ooit in php iets heeft gezeten als magic_quotes. En het voordeel van template engines zou dan zijn : Automatic output escaping...

Hoevaak je wel niet hebt gehad dat je site lek was voor XSS omdat je net één keer was vergeten te escapen?

Ehm 0x...
XSS voorkom je niet door output te escapen, XSS voorkom je door je input te valideren.

In wezen zeg jij dat je sites nog net zo lek zijn voor XSS, enkel kan het nu niet meer direct via de site / browser opgegeven worden. Iedereen die losse posts gaat sturen treft nog steeds dezelfde XSS-gaten aan...

[HuHu]

Dat is onzin Gomez12; XSS voorkom je door de juiste output escaping toe te passen. Je invoer valideren is niet de oplossing.

Onbekende content in HTML -> escape de HTML uitvoer
Onbekende content in JavaScript -> escape met een JS ding
Onbekende content in CSS -> aparte CSS escape

Door de invoer te controleren kun je niet correct de juiste output escaping toepassen, want je weet niet waar je het allemaal voor gaat gebruiken.

Ik weet ook niet je zou willen valideren? Je verwacht ergens tekst en het is tekst? Dan is de validatie geslaagd, ondanks de mogelijke inhoud van de tekst.

[Booster]

Ik zie hem zo snel niet in dit topic staan, maar een (naar mijn idee) erg groot voordeel van het gebruik maken van de mogelijkheid om even de parser uit te gaan en plain html in te voegen is dat je gebruik kunt maken van normale indentation, zoals F.West98 hieronder in de quota doet.

Dit merk je met name als je de output van je PHP als source wilt bekijken in de browser source view bijvoorbeeld. Het is erg prettig als ook daar de source overzichtelijk is opgebouwd. Bovendien forceer je jezelf hiermee om ook alle HTML gestructureerd op te bouwen, in plaats van alles maar als een gek achter elkaar te zetten, of linebreaks in een string te gebruiken, etc.

Output je een stuk HTML met een print of echo, ga dan maar eens overal de tabs met de juiste diepte invoegen Gekkenwerk, bovendien niet overzichtelijk en niet gefaciliteerd door je IDE.

F.West98 schreef op zondag 13 januari 2013 @ 01:49:
Ik doe altijd de bovenste maar dan zo:

PHP:

<? $var = 'foo'; ?>

<div class="container">
  <div class="sub">
     <p> Dit is de eerste regel <?=$var?> en maak er dan maar 3 van <br />
     </p>
  </div>
</div>

Nog sneller

[Gomez12]

HuHu schreef op zondag 13 januari 2013 @ 16:24:
Door de invoer te controleren kun je niet correct de juiste output escaping toepassen, want je weet niet waar je het allemaal voor gaat gebruiken.

Hetzelfde gaat op voor template-output die automatisch escaped wordt.

Ik weet ook niet je zou willen valideren? Je verwacht ergens tekst en het is tekst? Dan is de validatie geslaagd, ondanks de mogelijke inhoud van de tekst.

Tja, als je het zo zegt dan snap je niets van valideren.

Je verwacht niet simpelweg tekst. Je verwacht tekst in een bepaalde encoding en bestaande uit bepaalde tekens. Als bijv normale users geen html mogen posten, maar admins wel dan heb je een probleem met output escaping...

Booster schreef op zondag 13 januari 2013 @ 16:33:
Ik zie hem zo snel niet in dit topic staan, maar een (naar mijn idee) erg groot voordeel van het gebruik maken van de mogelijkheid om even de parser uit te gaan en plain html in te voegen is dat je gebruik kunt maken van normale indentation, zoals F.West98 hieronder in de quota doet.

Je druk maken over indentation vind ik al gekkenwerk
Daar heb ik een post-processor voor die in debug alles zelf kan indenten en comments kan laten staan en in productie alle comments kan strippen en alles kan minifyen.

[jeroenikke]

Gomez12 schreef op zondag 13 januari 2013 @ 16:42:
[...]
Je verwacht niet simpelweg tekst. Je verwacht tekst in een bepaalde encoding en bestaande uit bepaalde tekens. Als bijv normale users geen html mogen posten, maar admins wel dan heb je een probleem met output escaping...

Maar als een user nu html code als comment wilt zetten, (dat niet geparsed moet worden als html), vind ik het zelf ook makkelijker om het als "<b>" in de DB te zetten, en daarna mijn output te escapen. Geëscapete (hoe schrijf je dat?) content in een databank is enorm vervelend als je plots je data in een ander formaat (ik zeg maar iets: json) wilt outputten.

Dus ik geef HuHu gelijk: voor XSS doe ik output escaping, voor SQL injection input escaping.

Uiteraard helpt input validatie ook wel: een voornaam hoeft geen > te bevatten...

[HuHu]

Gomez12 schreef op zondag 13 januari 2013 @ 16:42:
[...]

Hetzelfde gaat op voor template-output die automatisch escaped wordt.

Automatische escaping vind ik dan ook onzin.

[...]

Tja, als je het zo zegt dan snap je niets van valideren.

Je verwacht niet simpelweg tekst. Je verwacht tekst in een bepaalde encoding en bestaande uit bepaalde tekens. Als bijv normale users geen html mogen posten, maar admins wel dan heb je een probleem met output escaping...

PHP:

if ($user->hasHtmlPostingRight()) {
  echo $content;
} else {
  echo htmlspecialchars($content);
}

Dit soort dingen doe je dus juist bij de uitvoer en zeker niet bij de invoer. Wat veel forums doen is een aparte kolom in de database bijhouden met daarin vooraf gegenereerde uitvoer. Dan doe je dat dus wél op het moment invoer, maar dat is een vorm van caching en niet van XSS preventie.

Daarnaast, een user mag best HTML posten, maar dan moet het ge-escaped worden weergegeven. Wil jij het dan al escapen bij de invoer en zo in de database bewaren? Wat dan als een user zijn post wil bewerken? Eerst weer un-escapen en dan tonen, wijziging binnenkrijgen, opnieuw escapen en dan opslaan? Wat nu als iemand admin was, een post maakte, zijn admin rechten verliest en dan die post gaat editten? Dat is erg omslachtig en wellicht onmogelijk. Je slaat ruwe invoer op en escaped op het moment van uitvoer.

[HuHu]

jeroenikke schreef op zondag 13 januari 2013 @ 16:52:
[...]

Uiteraard helpt input validatie ook wel: een voornaam hoeft geen > te bevatten...

Dat is geen validatie, dat is filtering.

[Megamind]

HuHu schreef op zondag 13 januari 2013 @ 16:56:
[...]

Dat is geen validatie, dat is filtering.

Filteren is geen validatie. Als je een input niet accepteerd omdat er een > instaat is het validatie, ga je zelf die > eruit slopen op het moment van toevoegen aan je database is het filteren.

[HuHu]

Megamind schreef op zondag 13 januari 2013 @ 16:57:
[...]

Filteren is geen validatie. Als je een input niet accepteerd omdat er een > instaat is het validatie, ga je zelf die > eruit slopen op het moment van toevoegen aan je database is het filteren.

Ik ging er vanuit dat jeroenikke het laatste bedoelde.

[Gomez12]

HuHu schreef op zondag 13 januari 2013 @ 16:54:
[...]
Automatische escaping vind ik dan ook onzin.

Dan is wmb de discussie afgelopen, dan zijn we het eens. Ik ageer tegen automatisch escapen (en dat dat je tegen XSS zou beschermen) niet dat handmatig escapen naar gelang de gewenste output XSS voorkomt.

Ik zei het denk ik verkeerd...

[Douweegbertje]

NMe schreef op zondag 13 januari 2013 @ 12:45:
In zijn algemeenheid een ander proberen te overtuigen van je eigen gelijk is in deze discussie net zoiets als iemand ervan proberen te overtuigen dat aardbeien en spinazie samen heel lekker zijn.

Ja dat klopt.
Maar je kan wel iemand ervan overtuigen dat een appel fruit is.

Met PHP kun je hele vieze code maken, PHP is totaal niet strict en er zijn ongeveer 100 manieren om 'iets' voor elkaar te krijgen. Ze zullen allemaal werken, maar wellicht zijn er maar 10 fatsoenlijk.
Eigenlijk mijn stukje was meer een tip om fatsoenlijke code te krijgen. Hoe vaak ik wel niet 'scripts' heb gezien van mensen die er totaal niet uitzien.

Mij best als iemand 1000 echo's wilt gebruiken voor elk divje, tabletje of weet ik veel wat, het werkt!
Geeft niet weg dat dit (mijn meing dan hé) ontzettend vieze code is.

[Gomez12]

douweegbertje schreef op zondag 13 januari 2013 @ 17:22:
[...]
Mij best als iemand 1000 echo's wilt gebruiken voor elk divje, tabletje of weet ik veel wat, het werkt!
Geeft niet weg dat dit (mijn meing dan hé) ontzettend vieze code is.

Het omgekeerde is dan weer om smarty aan te raden voor 3 regels (zie TS).

Het wel / niet gebruiken van een template-engine is van veel factoren afhankelijk en het is ook niet altijd de juiste oplossing.

[Booster]

Gomez12 schreef op zondag 13 januari 2013 @ 16:42:
[...]
Je druk maken over indentation vind ik al gekkenwerk
Daar heb ik een post-processor voor die in debug alles zelf kan indenten en comments kan laten staan en in productie alle comments kan strippen en alles kan minifyen.

Dus als jij in PHP code:

code:

print "<ul>
<li>1</li>
<li>2</li>
</ul>";

dan gaat jouw omgeving daar zelf \t's en \r\n's e.d. aan toevoegen om de output van de code overzichtelijk te houden? Dat lijkt me niet

Dus zelfs als je een prachtig aangeklede omgeving gebruikt om in te ontwikkelen, lijkt het me alsnog handig om 'mooie' methodes te gebruiken waar de IDE vast nog iets veel mooiers van kan maken. Zeker voor beginnende coders of hobbyisten: die hebben vaak niet zo'n omgeving. Bovendien denk ik dat daarmee de educatieve waarde van sommige dingen verdwijnt: soms is het beter om eerst een idee te hebben van hoe dingen gaan zonder uitgebreide omgeving, om daarna pas te ontdekken dat het automatisch kan, in plaats van altijd maar aannemen dat het voor je geregeld wordt.

[Gomez12]

Booster schreef op zondag 13 januari 2013 @ 17:56:
[...]

Dus als jij in PHP code:

code:

print "<ul>
<li>1</li>
<li>2</li>
</ul>";

dan gaat jouw omgeving daar zelf \t's en \r\n's e.d. aan toevoegen om de output van de code overzichtelijk te houden? Dat lijkt me niet

Waarom lijkt het je van niet? Post-processor indent gewoon de uiteindelijk geproduceerde html (in debug dan).
Op deze manier heb ik in mijn IDE een indentation die daar logisch in is (imho) en in mijn html een andere indentation die daarin weer logisch is.

Dus zelfs als je een prachtig aangeklede omgeving gebruikt om in te ontwikkelen, lijkt het me alsnog handig om 'mooie' methodes te gebruiken waar de IDE vast nog iets veel mooiers van kan maken.

Het probleem is over het algemeen dat IDE en output niet direct gelinkt zijn (loops / conditional parameters etc) waardoor je anders moet kiezen voor of rottige indentation in IDE of rottige indentation in html.
Ik wil me helemaal niet druk maken om die keuze, ik wil simpelweg dat wat ik voor me heb op dat moment goed geindent is.

[HuHu]

Booster schreef op zondag 13 januari 2013 @ 17:56:
[...]

Dus als jij in PHP code:

code:

print "<ul>
<li>1</li>
<li>2</li>
</ul>";

dan gaat jouw omgeving daar zelf \t's en \r\n's e.d. aan toevoegen om de output van de code overzichtelijk te houden? Dat lijkt me niet

Waarom niet? Als je output buffering aan zet en de uiteindelijke HTML nog even door tidy heen haalt, dan krijg je keurige uitvoer.

[NMe]

En zelfs als je dat niet doet: een fatsoenlijke DOM-viewer (die je uiteindelijk bij het debuggen toch nodig hebt als je ook maar een klein beetje dynamische content hebt) doet zelf zijn indentation ongeacht wat jij in je code doet.

[ Voor 3% gewijzigd door NMe op 13-01-2013 18:31 ]

[Booster]

Gomez12 schreef op zondag 13 januari 2013 @ 18:06:
Waarom lijkt het je van niet? Post-processor indent gewoon de uiteindelijk geproduceerde html (in debug dan).

Ah ok, maar dat is dus pas nadat de output al gegenereerd is. Niet in de code zelf, voor hij gecompileerd of gedraait wordt. Ja, dat kan handig zijn. Ik dacht even dat je bedoelde dat een omgeving echt die PHP-code ging interpreteren, en dat die daar dan letterlijk "\t" e.d. aan toe ging voegen. Zou zelf niet blij zijn met dergelijke oplossingen.

Still: veel mensen hebben niet zo'n omgeving en ik denk dat het ook goed is als men in staat is om te zien hoe het zonder moet/kan.

NMe schreef op zondag 13 januari 2013 @ 18:31:
En zelfs als je dat niet doet: een fatsoenlijke DOM-viewer (die je uiteindelijk bij het debuggen toch nodig hebt als je ook maar een klein beetje dynamische content hebt) doet zelf zijn indentation ongeacht wat jij in je code doet.

True, maar ik moet ook zeggen dat ik de view in een DOM-viewer niet persee in alle gevallen "heel veel overzichtelijker" vind dan even CTRL-U en evt. even scrollen. Soms zijn er gewoon meer muisklikken nodig om hetzelfde te kunnen zien.

[ Voor 29% gewijzigd door Booster op 13-01-2013 18:39 ]

[Gomez12]

NMe schreef op zondag 13 januari 2013 @ 18:31:
En zelfs als je dat niet doet: een fatsoenlijke DOM-viewer (die je uiteindelijk bij het debuggen toch nodig hebt als je ook maar een klein beetje dynamische content hebt) doet zelf zijn indentation ongeacht wat jij in je code doet.

Nadeel van een DOM-viewer is dan weer dat die de DOM toont, niet de gestuurde HTML. Vooral met JS-heavy projecten kan dat nogal wat uitmaken.

In wezen is het verschil :
- Wil je de gestuurde code bekijken = html-viewer
- Wil je de huidige code/DOM bekijken = DOM-viewer

Booster schreef op zondag 13 januari 2013 @ 18:32:
[...]
Ik dacht even dat je bedoelde dat een omgeving echt die PHP-code ging interpreteren, en dat die daar dan letterlijk "\t" e.d. aan toe ging voegen. Zou zelf niet blij zijn met dergelijke oplossingen.

Ach, Eclipse / Visual Studio kunnen dit al doen. Mits juist ingesteld kan dit heel erg makkelijk zijn. Iemand kan iets in zijn stijl naar jou toesturen en jij kan het in jouw stijl bekijken.
Enige probleem is dat het over algemeen zo veel instelwerk is dat ik er niet aan ga beginnen. Dan laat ik Eclipse / VS wel de code cleanen volgens hun standaard definities en lees ik het dan wel.

Still: veel mensen hebben niet zo'n omgeving en ik denk dat het ook goed is als men in staat is om te zien hoe het zonder moet/kan.

Tja, je kan ook met notepad gaan php'en, maar wil je het serieus doen dan heb je simpelweg bepaalde gereedschappen nodig...

[Barryvdh]

Ik ben onlangs ook voor het eerst begonnen met templates in php, maar moet wel zeggen dat het een stuk prettiger werkt.
Heb nu Blade geprobeerd (standaard bij Laravel), en dat compileert ook gewoon naar PHP. Het maakt de code vooral een stuk leesbaarder en makkelijker om je code te scheiden.

Verder werkt <?= $var ?> wel altijd (in tegenstelling tot de <? shorttag), en dat ziet er al een stuk cleaner uit.

Ook zou ik zeggen dat het in je IDE fijner is om de HTML buiten je PHP echo's te hebben, omdat je dan makkelijk kan zien of je eind-tags kloppen en dat je makkelijk je code automatisch kan formatten.

[Grijze Vos]

douweegbertje schreef op zondag 13 januari 2013 @ 17:22:
[...]


Ja dat klopt.
Maar je kan wel iemand ervan overtuigen dat een appel fruit is.

Met PHP kun je hele vieze code maken, PHP is totaal niet strict en er zijn ongeveer 100 manieren om 'iets' voor elkaar te krijgen. Ze zullen allemaal werken, maar wellicht zijn er maar 10 fatsoenlijk.
Eigenlijk mijn stukje was meer een tip om fatsoenlijke code te krijgen. Hoe vaak ik wel niet 'scripts' heb gezien van mensen die er totaal niet uitzien.

Mij best als iemand 1000 echo's wilt gebruiken voor elk divje, tabletje of weet ik veel wat, het werkt!
Geeft niet weg dat dit (mijn meing dan hé) ontzettend vieze code is.

Als je doel is om iemand zinniger gestructureerde code te laten schrijven kun je m.i. beter een framework (Zend, of iets anders) aanraden, dan een template engine. Met alleen php kun je ook gewoon je view templates als losse files definieren, het hoeft helemaal geen prutje te worden. Smarty zal vast voordelen hebben t.o.v. php (alhoewel template inheritance klinkt als een anti-pattern), maar daar ging het voor de TS niet om.

Overigens kun je met alle talen en framework rotzooi creeeren. Ik heb al genoeg troep gezien de afgelopen 10 jaar.

[kwaakvaak_v2]

In principe is een template engine een goed voorbeeld van een DSL en niet eens een heel dom idee omdat voor output te gebruiken. Het dwingt je af om na te denken over wat je in de template logic wilt oplossen,en wat in je pre-processing logic (noem het een view).

Vaak vinden developers die alles doen het onzin om te gebruiken, maar op het moment dat de paden wat meer gescheiden zijn, is het juist wel heel prettig. De frontender die templates maakt weet altijd wat ie kan verwachten, en welke syntax er beschikbaar is.

Grappig overigens dat als je het over een template taal hebt en PHP er altijd een pro/con discussie ontstaat, terwijl hetzelfde principe bij andere talen een minder felle discussie geeft. Goed beschouwd zijn SASS en LESS ook template talen, en kun je die output ook direct in CSS schrijven.

[Cartman!]

kwaakvaak_v2 schreef op maandag 14 januari 2013 @ 11:57:
De frontender die templates maakt weet altijd wat ie kan verwachten, en welke syntax er beschikbaar is.

En of dat nu native PHP is of een afgeleid smaakje daarvan maakt dan vrijwel niet uit is mijn ervaring.

[s.stok]

(alhoewel template inheritance klinkt als een anti-pattern)

Waarom? Template inheritance is de kern van Twig, je maakt een hoofd template met blocks, die template doe je vervolgens weer extenden in een andere template en overschrijft de blocks zodat daar de inhoud komt.

Deze techniek is overigens afkomstig uit Jinja en Django .(Python).

Het is even wennen maar bied een voordeel dat je makkelijk je layout kan veranderen zonder allerlei vreemde hacks en tweaks om een communicatie tussen de twee te krijgen.

XSS was misschien wat kort door de bocht, maar auto escaping bied wel degelijk voordelen.
Als je de gebruiker/editor toestaat gewone platte tekst te gebruiken moet je er van op aan kunnen dat die goed word weergeven, en iemand hoeft dan maar een < of > te gebruiken en je hebt een probleem.

Output escaping is eigenlijk iets wat je zo vaak doet dat het handiger is om bij een uitzondering een |raw toe te voegen dan dat je overal escape achter moet zetten en dan net eentje bent vergeten.

[Gomez12]

s.stok schreef op dinsdag 15 januari 2013 @ 10:48:
[...]
Output escaping is eigenlijk iets wat je zo vaak doet dat het handiger is om bij een uitzondering een |raw toe te voegen dan dat je overal escape achter moet zetten en dan net eentje bent vergeten.

Het hele punt van escaping is juist dat je het context-gerelateerd moet doen en dat het daardoor niet automatisch kan.

Als ik een template voor RSS maak dan moet die anders ge-escaped worden, idem met XML met Cdata mogelijkheden, idem met edi-output, idem met xlsx output, idem met html output, idem met nog 100 andere export mogelijkheden.