[PHP] als template engine - wat doe ik verkeerd?

woensdag 9 februari 2011 16:49

PHP is prima geschikt om templates mee te maken, Smarty is alleen maar nutteloze overhead.

Acties:

Shagura

Reveller schreef op woensdag 09 februari 2011 @ 16:37:
HTML:
1
2
3
<html>
    <b><?php $tpl_vars['foo']; ?></b><br><u><?php $tpl_vars['bar']; ?></u>
</html>

je vergeet de echo

PHP:

1
2
3

<html>
    <b><?php echo $tpl_vars['foo']; ?></b><br><u><?php echo $tpl_vars['bar']; ?></u>
</html>

[ Voor 12% gewijzigd door BtM909 op 10-02-2011 12:17 ]

woensdag 9 februari 2011 16:51

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Php

file_fetch

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 9 februari 2011 16:52

Acties:

Verwijderd

Shagura schreef op woensdag 09 februari 2011 @ 16:49:
[...]

je vergeet de echo
PHP:
1
2
3
<html>
    <b><?php echo $tpl_vars['foo']; ?></b><br><u><?php echo $tpl_vars['bar']; ?></u>
</html>

Of

PHP:

1	<?= $tpl_vars['foo']; ?>

woensdag 9 februari 2011 16:52

Acties:

PaulZ

Zo te zien wordt de tpl-code gewoon als tekst geïmporteerd aangezien de <?php markeringen er ook nog gewoon in staan.

Al een doodgewone include geprobeerd?

code:

1	include (BASE_PATH .'includes/template.tpl');

in plaats van die echo theme_print()?

Vlinders moet je volgen, niet vangen...

woensdag 9 februari 2011 16:56

Acties:

YopY

En dan hebben we mogelijk probleem #3 nog, wat doet de file_fetch functie precies? Als dat een alias is voor include() zou het gewoon moeten werken, maar als het iets is dat een bestand ophaalt en de inhoud gewoon zo teruggeeft zal het de variabelen niet op magische wijze vervangen, omdat het niet als PHP geïnterpreteerd wordt.

woensdag 9 februari 2011 16:56

Acties:

Reveller

Hopla!

Php

Topicstarter

Bedankt voor de reakties, maar het resultaat is hetzelfde. Misschien als ik er even twee bestandjes van maak:

PHP:

<?php

//index.php
function file_fetch($file) {
  $handle = fopen($file, 'rb');
  $output = fread($handle, filesize($file));
  fclose($handle);
  
  return $output;
}

function theme_print() {
  return file_fetch(BASE_PATH .'includes/template.php'); 
}

echo theme_print();

// template.php
<html>
  <body>
    <div class="wrapper">
      <div class="menu"><?php echo 'blaat'; ?></div>
      <div class="body">...</div>
    </div>
  </body>
</html>

Nu gebeurt hetzelfde...wat naar de client gestuurd wordt is dit:

HTML:

<html>
  <body>
    <div class="wrapper">
      <div class="menu"><?php echo 'blaat'; ?></div>
      <div class="body">...</div>
    </div>
  </body>
</html>

En niet:

HTML:

<html>
  <body>
    <div class="wrapper">
      <div class="menu">blaat</div>
      <div class="body">...</div>
    </div>
  </body>
</html>

Met andere woorden, de PHP wordt niet geparsed en ik zie niet waarom niet.

[edit]
@YopY, @PaulZ - onze berichten kruisten elkaar...ik importeer idd als tekst

Ik ging er onterecht vanuit dat dat desondanks als php herkend zou worden

[ Voor 7% gewijzigd door Reveller op 09-02-2011 16:58 ]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."

woensdag 9 februari 2011 16:59

Acties:

PaulZ

Zoals Yopy en ik al aangaven: de code wordt als tekst geïnterpreteerd. Probeer het eens met een include...

[ Voor 200% gewijzigd door PaulZ op 09-02-2011 17:00 . Reden: Gekruiste berichten ]

Vlinders moet je volgen, niet vangen...

woensdag 9 februari 2011 17:00

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Php

Reveller schreef op woensdag 09 februari 2011 @ 16:56:

PHP:

<?php

//index.php
function file_fetch($file) {
  $handle = fopen($file, 'rb');
  $output = fread($handle, filesize($file));
  fclose($handle);
  
  return $output;
}

Booyah! Daar zit je probleem.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 9 februari 2011 17:00

Acties:

posttoast

HuHu schreef op woensdag 09 februari 2011 @ 16:47:
PHP is prima geschikt om templates mee te maken, Smarty is alleen maar nutteloze overhead.

Dat laatste vind ik wel een beetje kort door de bocht.

omniscale.nl

woensdag 9 februari 2011 17:01

Acties:

Reveller

Hopla!

Php

Topicstarter

PaulZ schreef op woensdag 09 februari 2011 @ 16:59:
Zoals Yopy en ik al aangaven: de code wordt als tekst geïnterpreteerd. Probeer het eens met een include...

...bijna niet bij te houden met welke snelheid de berichten hier elkaar opvolgen

Met een include werkt het idd perfect. Bedankt iedereen; dit had ik ook zelf moeten kunnen verzinnen. Ik wijt het aan te lang zitten staren

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."

woensdag 9 februari 2011 17:02

Acties:

Mint

Misschien dat het door de 'echo' komt in

PHP:

1	echo theme_print();

?

woensdag 9 februari 2011 17:14

Acties:

woensdag 9 februari 2011 18:43

posttoast schreef op woensdag 09 februari 2011 @ 17:00:
[...]

Dat laatste vind ik wel een beetje kort door de bocht.

Maar toch is het best wel waar, het blijft een extra laag die je ook simpel af kan zonder extra code. Deze discussie is laatst al eerder gevoerd alleen geloof ik

het belangrijkste argument was naar mijn idee: smarty hanteert een eigen syntax die je boven op php nog weer moet leren en achter de schermen compiled smarty gewoon naar... voel je em aankomen... php!

[ Voor 22% gewijzigd door Cartman! op 09-02-2011 17:15 ]

Acties:

skabouter

Skabouter

[knip][/knip]

HuHu schreef op woensdag 09 februari 2011 @ 16:47:
PHP is prima geschikt om templates mee te maken, Smarty is alleen maar nutteloze overhead.

Verklaar u nader?

[ Voor 63% gewijzigd door skabouter op 09-02-2011 18:46 . Reden: te snel gelezen ]

[ Dislect ]

woensdag 9 februari 2011 19:40

Acties:

woensdag 9 februari 2011 20:18

posttoast schreef op woensdag 09 februari 2011 @ 17:00:
[...]

Dat laatste vind ik wel een beetje kort door de bocht.

skabouter schreef op woensdag 09 februari 2011 @ 18:43:
[knip][/knip]

[...]

Verklaar u nader?

Daar zijn wel vaker discussies over gevoerd, bijvoorbeeld hier: [PHP ZF] Zend Framework en SMarty

Acties:

woensdag 9 februari 2011 21:17

Goed, de oplossing van het probleem was dus het verschil tussen enkel een file lezen en include/eval.

Mocht je trouwens ooit 'file_fetch' nodig hebben: Gebruik gewoon de standaard file_get_contents()

{signature}

Acties:

ameesters

als mensen nu naar: includes/template.tpl, zien ze je php in je broncode staan, dit kan veiligheids risico's met zich mee brengen, als je toegang heb tot de rewrite engine van apache zou ik in je documentroot een .htaccess bestand aanmaken met de volgende code erin:

code:

<Files ~ "\.tpl$">
Order allow,deny
Deny from all
</Files>

Zo kan niemand je .tpl bestanden(en dus de php code) bekijken...

wist u dat, sinds php4. php een compiled programmeer taal is, dus wel even wat meer dan een template engine

[ Voor 0% gewijzigd door BtM909 op 10-02-2011 12:17 ]

woensdag 9 februari 2011 21:20

Acties:

woensdag 9 februari 2011 21:22

Goed punt, alhoewel je ipv blacklisten, ook gewoon die hele reut uit je docroot kan laten.

{signature}

Acties:

woensdag 9 februari 2011 21:27

leipepo schreef op woensdag 09 februari 2011 @ 21:17:
als mensen nu naar: includes/template.tpl, zien ze je php in je broncode staan, dit kan veiligheids risico's met zich mee brengen, als je toegang heb tot de rewrite engine van apache zou ik in je documentroot een .htaccess bestand aanmaken met de volgende code erin:
code:
1
2
3
4
<Files ~ "\.tpl$">
Order allow,deny
Deny from all
</Files>
Zo kan niemand je .tpl bestanden(en dus de php code) bekijken...

In feite hoor je ze ook gewoon buiten de docroot te plaatsen...

wist u dat, sinds php4. php een compiled programmeer taal is, dus wel even wat meer dan een template engine

Dat doet er niks af aan het feit dat php van zichzelf een prachtige template-engine is.

Acties:

Verwijderd

Cartman! schreef op woensdag 09 februari 2011 @ 21:22:

In feite hoor je ze ook gewoon buiten de docroot te plaatsen...

Nee, je hoort te zorgen dat de webserver ze niet serveert. Hoe je dat doet moet je zelf weten.

woensdag 9 februari 2011 21:33

Acties:

ameesters

ik ben tot de conclusie gekomen van een htaccess file omdat de code aangeeft dat het dus niet buiten zijn docroot staat, of hij moet truukjes uithalen in BASE_PATH, dus op deze manier hoeft hij geen code te herschrijven, plus dat sommige virtual host providers je niet toestaan buiten je docroot te komen... Maar ik ben het er wel mee eens dat het buiten je docroot natuurlijk veel beter is!

en helemaal beter zou zijn gewoon een php extensie aan de bestanden te geven, aangeien alle templates toch in een template folder staan lijkt het mij wel duidelijk dat het om een template gaat ondanks dat het een php extensie heeft, .tpl.php kan ook een uikomst zijn

[ Voor 32% gewijzigd door ameesters op 09-02-2011 21:36 ]

donderdag 10 februari 2011 09:03

Acties:

donderdag 10 februari 2011 09:16

Verwijderd schreef op woensdag 09 februari 2011 @ 21:27:
[...]

Nee, je hoort te zorgen dat de webserver ze niet serveert. Hoe je dat doet moet je zelf weten.

Eens, maar door het buiten de docroot te plaatsen voorkom je evt. fokops van je hostingpartij als ze per ongeluk een update hebben gedraaid of als er met modules is geknoeid, ik noem maar iets. Gewoon zo min mogelijk risico nemen.

leipepo schreef op woensdag 09 februari 2011 @ 21:33:
plus dat sommige virtual host providers je niet toestaan buiten je docroot te komen...

Dan is het je eigen schuld dat je bij een prutshoster zit, een beetje webhost-pakket ondersteunt dat gewoon.

[ Voor 25% gewijzigd door Cartman! op 10-02-2011 09:04 ]

Acties:

jbdeiman

leipepo schreef op woensdag 09 februari 2011 @ 21:33:
ik ben tot de conclusie gekomen van een htaccess file omdat de code aangeeft dat het dus niet buiten zijn docroot staat, of hij moet truukjes uithalen in BASE_PATH, dus op deze manier hoeft hij geen code te herschrijven, plus dat sommige virtual host providers je niet toestaan buiten je docroot te komen... Maar ik ben het er wel mee eens dat het buiten je docroot natuurlijk veel beter is!

en helemaal beter zou zijn gewoon een php extensie aan de bestanden te geven, aangeien alle templates toch in een template folder staan lijkt het mij wel duidelijk dat het om een template gaat ondanks dat het een php extensie heeft, .tpl.php kan ook een uikomst zijn

Waarom die extensie veranderen? Je kan via Htaccess files ook aangeven dat de server .txt, .tpl of wat dan ook als PHP moet verwerken.

Dat is natuurlijk nog mooier!

donderdag 10 februari 2011 09:21

Acties:

Verwijderd

Hoewel de oplossing voor het probleem al gevonden is, raad ik je toch aan om je code te reviseren naar een OOP oplossing, hiermee voorkom je het gebruik van globals en is het makkelijker later je template engine uit te breiden.

een vrij simpel begin zou zijn

PHP:

class TemplateEngine
{
  protected $_aVars = array();
  protected $_sFile;

  public function __construct($sTemplateFile)
  {
        if(!file_exists($sTemplateFile))
        {
            die('template does not exist');
        }
        $this->_sFile = $sTemplateFile;
  }

  public function setVar($sVar, $sVal)
  {
    $this->_aVars[$sVar] = $sVal;
  }

  function __toString()
  {
    return $this->render();
  }

  function render()
  {
    /*
         * extract zorgt ervoor dat alle vars uit de array local beschikbaar worden ...
         * dus als ->setVar('name', 'iemand) had gedaan ... dan zou je in je template gewoon $name kunnen gebruiken.
        */
    extract($this->_aVars, EXTR_SKIP);

    ob_start();
    include($this->_sFile);
    $sContent = ob_get_clean();
    return $sContent;
  }

}

De [code]-tag kan ook talen bevatten zoals HTML, JS, CSS, etc.

[ Voor 3% gewijzigd door BtM909 op 10-02-2011 12:17 ]

donderdag 10 februari 2011 09:27

Acties:

Ventieldopje

I'm not your pal, mate!

Als het zo simpel was als alleen maar str_replace in een bestandje dan hadden template engines als Smarty geen bestaan

Je vergeet dat in de tpl code ook nog een hele hoop gebeurt, wat doe je bijvoorbeeld met arrays/lijsten enzo?

Leuk om zelf te schrijven voor een school opdracht ofzo maar er komt veel bij kijken!

Waarom die extensie veranderen? Je kan via Htaccess files ook aangeven dat de server .txt, .tpl of wat dan ook als PHP moet verwerken. Dat is natuurlijk nog mooier!

Daar wordt je ook niet vrolijk van denk ik, hernoem ze dan naar mainpage.tpl.php

[ Voor 29% gewijzigd door Ventieldopje op 10-02-2011 09:34 ]

donderdag 10 februari 2011 09:39

Acties:

Verwijderd

@Phas0r ... Door PHP als template taal te gebruiken kun je juist ook arrays meegeven aan je template om hier vervolgens met een foreach loop doorheen te lopen.

In weze compiled Smarty zijn templates ook naar PHP code dus ik zie het nut er niet zo van in om er nog een laag tussen te hebben, vooral niet omdat:

- Een foreach in PHP net zo makkelijk/moeilijk is als een loop in Smarty, volgens mij is het meest gebruikte argument voor Smarty dat designers geen PHP snappen ...

- Een error in Smarty net zo fatal is als een PHP error, als deze op een graceful manier afgehandeld zouden worden zou er nog wat voor te zeggen zijn.

- Als je toch veel logica in een View/Template wil hebben, waarom dan niet een native manier om die logica te definieren ?

donderdag 10 februari 2011 09:54

Acties:

Woy

Moderator Devschuur®

Is er eigenlijk ook een manier om de scope en rights van je template te beperken? Ik kan me voorstellen dat je een Template niet altijd toegang tot alle rechten en variabelen wil geven. Als je bijvoorbeeld templates toe wil staan die van een derde komen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

donderdag 10 februari 2011 10:02

Acties:

zwippie

Electrons at work

Woy schreef op donderdag 10 februari 2011 @ 09:54:
Is er eigenlijk ook een manier om de scope en rights van je template te beperken? Ik kan me voorstellen dat je een Template niet altijd toegang tot alle rechten en variabelen wil geven. Als je bijvoorbeeld templates toe wil staan die van een derde komen.

Ik gebruik op het moment Twig om gebruikers zelf PDF templates te laten schrijven, waarbij ik de volledige controle heb over de lijst met te gebruiken variabelen. Via de sandbox extension kun je van elke klasse ook nog eens limiteren welke methoden en variabelen er mogen worden aangeroepen.

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.

donderdag 10 februari 2011 10:04

Acties:

Verwijderd

@Woy ... In mijn voorbeeld heb je in principe alleen toegang tot de variables die je in de property $_aVars gedefineerd hebt, zo creeer je dus een soort sandbox.

Wel is het nog steeds mogelijk om globals en variables als $_POST en $_GET aan te spreken.

donderdag 10 februari 2011 10:08

Acties:

zwippie

Electrons at work

Verwijderd schreef op donderdag 10 februari 2011 @ 10:04:
@Woy ... In mijn voorbeeld heb je in principe alleen toegang tot de variables die je in de property $_aVars gedefineerd hebt, zo creeer je dus een soort sandbox.

Wel is het nog steeds mogelijk om globals en variables als $_POST en $_GET aan te spreken.

Maar als jij een object meegeeft als template variabele, dan kunnen gebruikers standaard álle methodes aanroepen op dat object. Als je dus een DB object meegeeft kan men zo de delete() methode aanroepen...

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.

donderdag 10 februari 2011 10:08

Acties:

donderdag 10 februari 2011 10:11

En je kan allemaal enge functies aanroepen (exec(), eval(), filesystem calls, db calls, reflection, etc etc).

Als je een derde partij wilt beperken in wat deze met templates kan verneukenuitspoken, kan je hem geen full blown PHP aanbieden.

{signature}

Acties:

donderdag 10 februari 2011 10:22

PHP als template-engine kan zoiets gewoon zijn:

index.php:

PHP:

1
2
3

$name = 'foo';
$someNumbers = array(1, 2, 3);
require_once 'templates/home.php';

templates/home.php :

PHP:

<p>Hallo <?php echo ucfirst($name) ?></p>
<ul>
<?php foreach($someNumbers as $number) { ?>
    <li><?php echo $number ?></li>
<?php } ?>
</ul>

Als je short-tags aan hebt staan dan kan t natuurlijk nog korter en de foreach kun je ook korter schrijven. Maar wat is hier nu moeilijker aan dan een template-engine? De extra laag met overbodige syntax ben je kwijt en je kan zonder problemen logica voor je opmaak kwijt (iets wat niet in je controller thuishoort).

edit: in shorthand zou t zoiets kunnen zijn:

PHP:

<p>Hallo <?= ucfirst($name) ?></p>
<ul>
<?php foreach($someNumbers as $number): ?>
    <li><?= $number ?></li>
<?php endforeach; ?>
</ul>

[ Voor 15% gewijzigd door Cartman! op 10-02-2011 10:14 ]

Acties:

X-Lars

Just GoT it.

Voegt niet meer zoveel toe, maar dit was voor mij het "definitive" document (uit 2003): http://www.massassi.com/php/articles/template_engines/

donderdag 10 februari 2011 10:30

Acties:

Verwijderd

@Zwippy & Voutloos,

True ... maar ja ... wie geeft er nu een Db object mee aan een template ? dan mis je heel het idee van het scheiden van logica/weergave/data handling. Maar okay .. het zou natuurlijk voor kunnen komen.

Ik moet wel zeggen dat er zelden objecten meegegeven worden aan mijn templates, en dat deze templates ook niet door derden gemaakt worden, dus moet zeggen dat ik deze sandboxing ook niet echt nodig heb. In het geval dat er wel derden in het spel zouden zijn is het natuurlijk wel een goed idee om dit wel mee te nemen.

Op het moment maakt bij framework gebruik van een PHP based template engine en die geeft me vooral veel vrijheid om te doen/maken wat ik wil en de mogelijkheid om Widgets en helpers in te schakelen voor complexe display logica.

Binnen veel andere niet full blown PHP templates engines als Smarty is het trouwens ook mogelijk direct PHP code aan te roepen ... weet niet zeker of alle methods/functies dan ook beschikbaar zijn.

Sowiezo is het altijd al een heftige discussie geweest of een View enige controle moet hebben richting een Controller of andere applicatie code.

[ Voor 11% gewijzigd door Verwijderd op 10-02-2011 10:32 ]

donderdag 10 februari 2011 10:30

Acties:

donderdag 10 februari 2011 11:02

X-Lars schreef op donderdag 10 februari 2011 @ 10:22:
Voegt niet meer zoveel toe, maar dit was voor mij het "definitive" document (uit 2003): http://www.massassi.com/php/articles/template_engines/

En wat wil je met dat document zeggen? Dat je native code wil gebruiken maar toch een tussenlaag wilt hebben omdat het dan beter zou werken ?

[ Voor 47% gewijzigd door Cartman! op 10-02-2011 10:31 ]

Acties:

donderdag 10 februari 2011 11:03

Verwijderd schreef op donderdag 10 februari 2011 @ 10:30:
@Zwippy & Voutloos,

True ... maar ja ... wie geeft er nu een Db object mee aan een template ?

Ik niet, maar dankzij dingen als global keyword kan je er altijd wel bij komen.

{signature}

Acties:

Verwijderd

Als je toch enigzins wilt 'encapsulaten' kun je je templates ook includen binnen de scope van een klasse. De templates hebben dan dezelfde scope, en je hoeft geen gebruik meer te maken van globals.

View.php:

PHP:

<?
class View
{
    public function render($tpl)
    {
        include($tpl);
    }
    
    // Je wilt waarschijnlijk nog een magic __get en __setter om handiger
    // properties te kunnen zetten
}

template.tpl

PHP:

1 2	<h1><?=$this->title?></h1> <p><?=$this->content?></p>

index.php

PHP:

<?
$view = new View();
$view->title = "Titel";
$view->content = "Hallo";
$view->render("template.tpl");

donderdag 10 februari 2011 11:11

Acties:

zwippie

Electrons at work

Verwijderd schreef op donderdag 10 februari 2011 @ 10:30:
@Zwippy & Voutloos,

True ... maar ja ... wie geeft er nu een Db object mee aan een template ? dan mis je heel het idee van het scheiden van logica/weergave/data handling. Maar okay .. het zou natuurlijk voor kunnen komen.

Ik bedoel met DB objecten niet je DB Manager oid, maar resultsets en record objects die je krijgt na het uitvoeren van een query. Ik werk met Doctrine ORM en dan kun je alles wel omzetten naar een array, maar er zitten in de record objects vaak getters/methodes die net wat anders teruggeven dan een plain column value, vandaar.

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.

donderdag 10 februari 2011 11:18

Acties:

Verwijderd

Voutloos schreef op donderdag 10 februari 2011 @ 11:02:
[...]
Ik niet, maar dankzij dingen als global keyword kan je er altijd wel bij komen.

Daarom wordt het gebruik van globals ook al evil beschouwd

Al moet ik dan toegeven dat ik zelf gebruik maak van een static die mijn DbConnection instances bijhoudt... en dit is dus eigenlijk ook als een soort van global aan te roepen ... is ook wel redelijk 'Viiiieees Patrick' , of in ieder geval te misbruiken.

Ik denk dat het een afweging is tussen iets compleet dichttimmeren voor het geval derden ooit met je systeem/framework gaan werken of het hebben van een flexibele oplossing waarbij ik voor de laatste optie gekozen heb sinds er weinig derden mee werken.

@zwippy ... heb je ook gelijk in .. .ik gebruik zelf ook een soort van ORM structuur en dan is het inderdaad mogelijk om die objecten aan te spreken en er allerlei smerige dingen mee te doen. Maar alles casten naar arrays is inderdaad ook niet altijd handig zoals je zelf al aangeeft.

gelukkig heb ik een flexibele opzet gemaakt die het toelaat om verschillende render engines te implementeren dus zou het vrij makkelijk zijn om over te stappen van een full PHP naar een iets wat minder 'riskant' is.

[ Voor 24% gewijzigd door Verwijderd op 10-02-2011 11:22 ]

donderdag 10 februari 2011 11:30

Acties:

donderdag 10 februari 2011 11:31

X-Lars schreef op donderdag 10 februari 2011 @ 10:22:
Voegt niet meer zoveel toe, maar dit was voor mij het "definitive" document (uit 2003): http://www.massassi.com/php/articles/template_engines/

Tja, maar zijn belangrijkste argument ertegen:

Sure, it's a few characters shorter, but if you can get used to it, you get all the power of PHP without all the overhead of parsing a template file.

Dit is simpelweg een verkeerd gebruik van template engines. Je wil juist niet "all the power of PHP", je wil een systeem wat nog net alle logica kan afhandelen die je in een view nodig hebt en niets meer dan dat. Als je complexe dingen wilt doen in je templates (zoals SQL queries draaien - ik heb het gezien) is je hele scheiding weg en kun je inderdaad net zo goed geen template engines gebruiken, dan is het onzin om iets als Smarty te implementeren.

Die overhead is trouwens nihil bij Smarty, het parsen van een template gebeurt daarmee namelijk maar 1 keer, dus van dat argument blijft weinig over. Maargoed, jaren geleden schreef ik daar al iets over, het is een beetje zinloze discussie aan het worden

[ Site ] [ twitch ] [ jijbuis ]

Acties:

Woy

Moderator Devschuur®

Verwijderd schreef op donderdag 10 februari 2011 @ 10:30:
@Zwippy & Voutloos,

True ... maar ja ... wie geeft er nu een Db object mee aan een template ? dan mis je heel het idee van het scheiden van logica/weergave/data handling. Maar okay .. het zou natuurlijk voor kunnen komen.

Natuurlijk is het inderdaad niet handig om meteen een Db object mee te geven. Ik was alleen benieuwd of PHP code echt in een soort sandbox te draaien is. Het feit dat er niet direct toegang is tot externe variabelen, maakt het niet dat er opeens minder stuk gemaakt kan worden in de template.

In .NET zou ik een plugin bijvoorbeeld in een apparte application domain laten draaien die maar beperkte privileges heeft. Ik was benieuwd of er op de een of andere manier ook iets dergelijks mogelijk is in PHP.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

donderdag 10 februari 2011 11:47

Acties:

Verwijderd

Persoonlijk ben tegen dit soort "template engines", inclusief Smarty... Waarom? Omdat je nog steeds met PHP loopt te klooien in je template bestanden.

De template engine die ik gebruik (zelf geschreven) heeft template bestanden die z.g.a. valideren in elke test (omdat er namelijk alleen in index.tpl de header en footer staan).

Hier een simpel voorbeeld voor een nieuws pagina:

HTML:

<div id="news">
   <!-- ARTICLE -->
   <div id="article-{id}">
      <h3>{title}</h3>
      {content}
      <!-- ARTICLE_MORE -->
         <p><a href="/news/article/{id}">read more</a></p>
      <!-- /ARTICLE_MORE -->
   </div>
   <!-- /ARTICLE -->
</div>

Met PHP (in de controller) haal verwerk ik alle artikelen en parse ze naar de template. En door de blokken structuur kan ik exact aangeven welk blok (bv ARTICLE) moet worden gerendeerd.

Op deze manier kan iedereen, zelfs zonder PHP kennis toch een template bouwen, mits er bekend is welke variabelen er beschikbaar zijn.

donderdag 10 februari 2011 11:49

Acties:

Verwijderd

@Woy ... In PHP is helaas veel mogelijk ... alleen het afschermen/sandboxen van variables en dergelijken is een stuk lastiger helaas. Bij talen als .NET en Java is dit een stuk makkelijker te realiseren inderdaad.

@FragFrog ... queries running in een template is natuurlijk uit den boze en ik denk dat alleen een n00b dit echt zou doen ... En het zou inderdaad goed zijn om niet 'all the power of PHP' toe te laten in een template , maar het zou wel een hele goede zijn om 'Some of the power' te hebben.

Voor beide argumenten is natuurlijk wat te zeggen, sommige mensen moeten nu eenmaal beschermd worden tegen zichzelf, beetje de reden waarom er in amerika in de handleiding van een magnetron staat dat je er geen levende wezens in moet stoppen

Maar zo even uit de losse bol zou het best een mooie optie zijn om een pseudocode voor function/methods te hebben in een template en de mogelijkheid om aan de templateengine een mapping mee te geven van pseudocode naar echte PHP methods.

in pseudocode zou je bijvoorbeeld hebben {{createTable|$rows}} waarbij je vooraf aangeeft in je template engine :

$oView->mapMethod('createTable', 'TableCreator::createTable');

zo kan er wel gebruik gemaakt worden van bepaalde methods/functies ... maar dan alleen degene die vooral gedefinieerd zijn.

donderdag 10 februari 2011 11:55

Acties:

donderdag 10 februari 2011 11:56

Verwijderd schreef op donderdag 10 februari 2011 @ 11:49:
@FragFrog ... queries running in een template is natuurlijk uit den boze en ik denk dat alleen een n00b dit echt zou doen ...

Wie het geschreven heeft weet ik niet, maar ik kwam het onder andere tegen in (relatief oude) code van een aardig groot bedrijf

Gebruikten trouwens ook een zelfgeschreven template engine op basis van XML, dus de boel valideerde leuk, dat wel. Was wel een vrij typisch voorbeeld van wanneer het (nagenoeg) geen nut heeft een template engine te gebruiken.

[ Voor 10% gewijzigd door FragFrog op 10-02-2011 11:56 ]

[ Site ] [ twitch ] [ jijbuis ]

Acties:

donderdag 10 februari 2011 12:09

Verwijderd schreef op donderdag 10 februari 2011 @ 11:47:
Persoonlijk ben tegen dit soort "template engines", inclusief Smarty... Waarom? Omdat je nog steeds met PHP loopt te klooien in je template bestanden.

De template engine die ik gebruik (zelf geschreven) heeft template bestanden die z.g.a. valideren in elke test (omdat er namelijk alleen in index.tpl de header en footer staan).

Hier een simpel voorbeeld voor een nieuws pagina:
HTML:
1
2
3
4
5
6
7
8
9
10
11
<div id="news">
   
   <div id="article-{id}">
      <h3>{title}</h3>
      {content}
      
         <p><a href="/news/article/{id}">read more</a></p>
      
   </div>
   
</div>
Met PHP (in de controller) haal verwerk ik alle artikelen en parse ze naar de template. En door de blokken structuur kan ik exact aangeven welk blok (bv ARTICLE) moet worden gerendeerd.

Op deze manier kan iedereen, zelfs zonder PHP kennis toch een template bouwen, mits er bekend is welke variabelen er beschikbaar zijn.

En wat is jouw systeem nu anders dan Smarty dan? Je zit nog steeds een alternatieve syntax te maken voor iets wat PHP allang kan. En wat doe jij als je bijv. de titel van je artikel in uppercase wil hebben nu?

Het argument dat iemand templates kan maken zonder verstand te hebben van PHP vind ik nog steeds apart. Of je iemand nu moet leren dat ie {id} gebruikt of <?= $id ?> is minimaal natuurlijk.

Acties:

Verwijderd

@FragFrog ... ik heb ook heel wat crappy shit gezien ... van het querien van data midden in een php/html include ... inline dus. Tot het compleet op zijn kop zetten van het MVC model en juist de view gebruiken om de controller/core aan te spreken, dus eigenlijk een template laag maken die bepaalt wat er in de core aangeroepen gaat worden.

In principe is het zelfs in Zend Framework mogelijk om queries in een view te doen, common sense zou dat tegen moeten gaan

donderdag 10 februari 2011 14:23

Acties:

YopY

quote: Thioz
Tot het compleet op zijn kop zetten van het MVC model en juist de view gebruiken om de controller/core aan te spreken, dus eigenlijk een template laag maken die bepaalt wat er in de core aangeroepen gaat worden.

Dat is overigens een paradigma op zichzelf (naam ben ik vergeten), gelijksoortig aan het MVC paradigma, waar ipv een router die een controler aanspreekt die data aan een view doorgeeft, een view aangesproken wordt die verschillende controllers aanspreekt die data teruggeven. Voor een modulair opgebouwde pagina lijkt me dat best wel handig. Alhoewel je datzelfde kunt doen dmv SSI's die op hun beurt de URL aanroepen die de juiste controller triggert, is het wel verdedigbaar om het op die manier te doen.

iig, het is voor zover ik weet niet mogelijk om een PHP-based templatebestand helemaal dicht te timmeren zonder je eigen PHP interpreter te schrijven die de functionaliteit limiteert tot het echo-en van variabelen en/of het beperken van de aan te roepen functies. Wat je wel kunt doen is statische analysetools erop loslaten die controleert op verboden zaken in een template (maar dan moet je dat eerst vaststellen), of gewoon discipline hebben of loslaten op degenen die de templates schrijven - gij zult geen non-view logica in uw views doen.

donderdag 10 februari 2011 14:23

Acties:

Verwijderd

Cartman! schreef op donderdag 10 februari 2011 @ 11:56:
[...]

En wat is jouw systeem nu anders dan Smarty dan? Je zit nog steeds een alternatieve syntax te maken voor iets wat PHP allang kan. En wat doe jij als je bijv. de titel van je artikel in uppercase wil hebben nu?

Het argument dat iemand templates kan maken zonder verstand te hebben van PHP vind ik nog steeds apart. Of je iemand nu moet leren dat ie {id} gebruikt of <?= $id ?> is minimaal natuurlijk.

Om antwoord te geven op de vraag "wat doe jij als je bijv. de titel van je artikel in uppercase wil hebben", dat doe ik met CSS, en niet met PHP. Dat zou iedereen moeten doen/weten...

Maar wat als ik 10 artikelen wil tonen?
Dan zou ik, met bijvoorbeeld Smarty, een for-loop, een foreach-loop of een while-loop in m'n template moeten zetten, wat het dus ingewikkeld maakt voor bv designers (zonder PHP kennis).
Nu wordt alles door de controller + template engine geregeld, en blijven mijn templates schoon.

donderdag 10 februari 2011 15:22

Acties:

vrijdag 11 februari 2011 07:59

Verwijderd schreef op donderdag 10 februari 2011 @ 14:23:
[...]
Om antwoord te geven op de vraag "wat doe jij als je bijv. de titel van je artikel in uppercase wil hebben", dat doe ik met CSS, en niet met PHP. Dat zou iedereen moeten doen/weten...

Je gaat er nu vanuit dat je CSS beschikbaar hebt, wat zou je doen in RSS of plaintext output?

Of ander voorbeeld: wat zou je doen als je van dat woord alleen de eerste 10 karakters nodig hebt (maw: iets waar je een serverside-taal voor nodig hebt).

Maar wat als ik 10 artikelen wil tonen?
Dan zou ik, met bijvoorbeeld Smarty, een for-loop, een foreach-loop of een while-loop in m'n template moeten zetten, wat het dus ingewikkeld maakt voor bv designers (zonder PHP kennis).
Nu wordt alles door de controller + template engine geregeld, en blijven mijn templates schoon.

Dat is in principe niet de taak van de controller, die haalt alleen data op en stopt het in je view. In je view kun je bepalen wat je er weer mee doet (dus loopen om alles te tonen bijv.).

Trouwens, een designer moet designen en geen templates bouwen of zit ik in zo'n extreem luxe bedrijf dat we losse designers, frontenders en backenders hebben?

[ Voor 8% gewijzigd door Cartman! op 10-02-2011 15:37 ]

Acties:

Patriot

Fulltime #whatpulsert

Ik snap het veronderstelde voordeel van Smarty niet hoor. Je hebt een syntax die nagenoeg gelijk is aan PHP, waarom gebruik je dan niet gewoon PHP? De overhead van de Smarty-library is vast niet erg groot, maar waarom kies je er bewust voor om overhead te hebben (hoe klein ook)?

Trouwens, een designer moet designen en geen templates bouwen of zit ik in zo'n extreem luxe bedrijf dat we losse designers, frontenders en backenders hebben?

Mja, dat snap ik dus ook nooit. Het enige waar ik zie dat designers ook met HTML (en meer) in de weer gaan, is bij freelancende mensen die kleine websitjes maken. Verder zie ik wel eens backenders die ook frontender zijn, maar daar is wat mij betreft an sich niet zoveel op tegen.

vrijdag 11 februari 2011 11:41

Acties:

Verwijderd

De v.l.n.r. pipe-symbool syntax vind ik al veel leesbaarder dan bijvoorbeeld geneste calls van nl2br, htmlentities, strolower en ucfirst.

code:

1	{$data\|strtolower\|ucfirst\|htmlentities\|nl2br}

Dat is leesbaarder dan:

PHP:

1	<?php echo nl2br(htmlentities(ucfirst(strtolower($data)))); ?>

Zeker als je meer argumenten toe gaat voegen.
En uiteindelijk wordt er gewoon PHP-code van gemaakt, dus verlies je bijna niets aan performance.

Je kunt een parser vanaf scratch schrijven, je kunt ook een parsergenerator gebruiken. Als je smarty code gewoon ziet als een input-file die nog moet worden omgezet naar een native formaat dan is er toch niet zoveel aan de hand?

Of mag je bijvoorbeeld ook geen autoconf, automake, flex en bison meer gebruiken?

vrijdag 11 februari 2011 11:48

Acties:

TJHeuvel

Verwijderd schreef op vrijdag 11 februari 2011 @ 11:41:
De v.l.n.r. pipe-symbool syntax vind ik al veel leesbaarder dan bijvoorbeeld geneste calls van nl2br, htmlentities, strolower en ucfirst.
code:
1
{$data|strtolower|ucfirst|htmlentities|nl2br}
Dat is leesbaarder dan:
PHP:
1
<?php echo nl2br(htmlentities(ucfirst(strtolower($data)))); ?>
Zeker als je meer argumenten toe gaat voegen.
En uiteindelijk wordt er gewoon PHP-code van gemaakt, dus verlies je bijna niets aan performance.

Het is juist het interpeteren en naar PHP omzetten wat veel overhead veroorzaakt. Bovendien zal ik in jouw voorbeeld gewoon een nieuwe functie maken welke elk van die functies aanroept.
Hoe schoon iets eruit ziet heb je veelal zelf in de hand.

Freelance Unity3D developer

vrijdag 11 februari 2011 12:03

Acties:

Verwijderd

CyCloneNL schreef op vrijdag 11 februari 2011 @ 11:48:

Het is juist het interpeteren en naar PHP omzetten wat veel overhead veroorzaakt.

Hoe vaak gebeurt dat dan?

Bovendien zal ik in jouw voorbeeld gewoon een nieuwe functie maken welke elk van die functies aanroept.

En dat is een betere oplossing, want?

vrijdag 11 februari 2011 14:00

Acties:

vrijdag 11 februari 2011 14:14

Geef mij de PHP-code maar, vind ik leesbaarder omdat m'n IDE dat gewoon begrijpt.

Acties:

dev10

Cartman! schreef op vrijdag 11 februari 2011 @ 14:00:
Geef mij de PHP-code maar, vind ik leesbaarder omdat m'n IDE dat gewoon begrijpt.

NetBeans en PhpStorm kunnen in ieder geval ook overweg met Smarty templates.

vrijdag 11 februari 2011 14:30

Acties:

vrijdag 11 februari 2011 19:00

Nooit geprobeerd (NetBeans hier) omdat ik een alternatieve syntax erg onpraktisch vind dus.

Dat is leesbaarder dan:

Je bedoelt te zeggen dat jij het leesbaarder vindt dus

edit: dat zei je erboven inderdaad... my bad.

[ Voor 47% gewijzigd door Cartman! op 11-02-2011 20:13 ]

Acties:

Verwijderd

Cartman! schreef op vrijdag 11 februari 2011 @ 14:30:

Je bedoelt te zeggen dat jij het leesbaarder vindt dus

Een beetje flauw om daar op te focussen omdat het er een paar regels hoger wel goed staat... maar goed.

Iedereen leest hier van links naar rechts. Dat zit erin gebakken en is dus natuurlijker. Ik zou er maar geen studie naar gaan doen want daaruit zal blijken dat ik gelijk heb

vrijdag 11 februari 2011 19:05

Acties:

vrijdag 11 februari 2011 19:34

Als je dus veel outsourced naar het Midden Oosten kan je dus het beste PHP houden.

{signature}

Acties:

vrijdag 11 februari 2011 20:16

Voutloos schreef op vrijdag 11 februari 2011 @ 19:05:
Als je dus veel outsourced naar het Midden Oosten kan je dus het beste PHP houden.

Dan nog is het veel makkelijker een haakje te missen (zeker als je er 5, 6 nest), wat je met de Smarty syntax niet hebt. Ik vind het er overigens ook een stuk leesbaarder uitzien, maar dat is inderdaad persoonlijke voorkeur

[ Site ] [ twitch ] [ jijbuis ]

Acties:

vrijdag 11 februari 2011 21:55

Verwijderd schreef op vrijdag 11 februari 2011 @ 19:00:
[...]
Een beetje flauw om daar op te focussen omdat het er een paar regels hoger wel goed staat... maar goed.

My bad, je hebt gelijk maar je volgende opmerking geeft toch aan dat je je mening wilt forceren.

Iedereen leest hier van links naar rechts. Dat zit erin gebakken en is dus natuurlijker. Ik zou er maar geen studie naar gaan doen want daaruit zal blijken dat ik gelijk heb

Dat gaat niet helemaal op imo, syntactisch gezien werk je vanaf je variabele en dat heb ik zo aangeleerd en daarom vind ik het logisch op deze manier. Blijft een kwestie van smaak dus.

edit: trouwens, hoe geef je aan htmlentities nu het argument mee dat je utf8 als input gebruikt bijv in je voorbeeld:

PHP:

1	{$data\|strtolower\|ucfirst\|htmlentities\|nl2br}

En is dit nu echt makkelijker:

code:

1	{include file='header.tpl'}

dan

PHP:

1	<?php include 'header.tpl' ?>

?

[ Voor 19% gewijzigd door Cartman! op 11-02-2011 21:01 ]

Acties:

ZpAz

<?php
{$data|strtolower|ucfirst|htmlentities|nl2br}
?>

Die strtolower kan er weg, ucfirst zet het immers al goed.

En ach is dat no zoveel duidelijker als:

code:

1	<?= ucfirst(htmlentities($data)) ?>

Maar ja, het is een kwestie van smaak.

Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF

vrijdag 11 februari 2011 22:02

Acties:

vrijdag 11 februari 2011 22:03

In Smarty misschien... in de normale php-functie doet ucfirst wat je zou verwachten, het eerste karakter uppercasen en de rest laten zoals t is.

Overigens ben ik dus benieuwd hoe je dit in smarty doet dus:

PHP:

1	echo ucfirst(strtolower(htmlentities($data, ENT_QUOTES, 'utf-8')));

Acties:

orf

ZpAz schreef op vrijdag 11 februari 2011 @ 21:55:
Die strtolower kan er weg, ucfirst zet het immers al goed.

Die kan niet weg want dat geeft andere resultaten:

PHP:

<?php

echo ucfirst('AAABBBCCC');
// output: AAABBBCCC
?>

Edit: net iets later dan Cartman!
@Cartman!: Daarvoor gebruik je escape in Smarty. Je kunt ook gewoon argumenten opgeven, maar dat is niet nodig voor UTF-8 omdat dit gelukkig veelal default is in Smarty

[ Voor 25% gewijzigd door orf op 11-02-2011 22:06 ]

zaterdag 12 februari 2011 08:43

Acties:

zaterdag 12 februari 2011 09:05

Vergeet de dinosaurus genaamt Smarty en kijk eens naar twig (twig-project.org)

Behalve dat dit de defacto template taal van symfony2 is, heeft twig als voordeel dat de syntax precies hetzelfde is als die van django. Dus ide's als netbeans, eclipse etc kunnen hier perfect mee omgaan. En twig heeft geen overhead met caching van static html wat smarty wel heeft, en goede post optimalisatie slagen
Kortom,volledig volgens de linux gedachte is het gemaakt om een ding zo goed mogelijk te doen. Omzetten van leesbare HTML template code naar super geoptimaliseerde PHP code.

Tuurlijk kun je dat laatste ook zelf, maar je kunt zelf ook assembler code schrijven. En toch kiezen veel
mensen voor een hogere taal. Waarom? Omdat het leesbaarder is. Waarom moet dat dan in webland een vies gebruik zijn?

Driving a cadillac in a fool's parade.

Acties:

zaterdag 12 februari 2011 15:34

orf schreef op vrijdag 11 februari 2011 @ 22:03:
[...]
Edit: net iets later dan Cartman!
@Cartman!: Daarvoor gebruik je escape in Smarty. Je kunt ook gewoon argumenten opgeven, maar dat is niet nodig voor UTF-8 omdat dit gelukkig veelal default is in Smarty

Ja...en een ander voorbeeld waarbij je argumenten wil opgeven? Ik noem maar iets... number_format oid?

Acties:

zaterdag 12 februari 2011 15:52

f0pc0dert

Php

Imho slaan heel veel reacties voor én tegen een (andere) templatetaal de plank mis.

Het belangrijkste is, m.i., dat een taal als smarty of twig gefocust is op het implementeren van templates. PHP is dat niet. Dat betekent simpelweg dat de taal (in syntax) en de engine (in tools) middelen bieden die het eenvoudiger maken om templates te implementeren. Syntax en tools die PHP niet (zonder meer) heeft.

Met een template engine heb je dus allerlei tools tot je beschikking die je niet zelf hoeft te bedenken of te schrijven als je templates gaat implementeren, wat weer tot gevolg heeft dat je als gebruiker van die tools je kan focussen op de taak die voor je ligt, namelijk het implementeren van templates, i.p.v. het bouwen van tools voor het implementeren van templates. (De topicstart is hier een bijzonder goed voorbeeld van).

Of een taal dan vervolgens een andere syntax heeft of niet is een kwestie van smaak. Ik vind Python een mooie taal. Niet per se vanwege de syntax, maar vanwege het feit dat het goede tools biedt om tot een eindresultaat te komen. Dat het een prettige syntax heeft is mooi meegenomen. Hetzelfde geldt voor templatetalen.

Om het cirkeltje even rond te maken naar de topicstart: Als je een template engine gebruikt, hoef je over het renderen van je templates niet na te denken. Dat maakt namelijk gewoon onderdeel uit van de engine. Dat betekent dus ook dat je na kan denken over datgene waar je eigenlijk over na moet denken, en dat is waar je ook alweer de titel neer moest zetten, en wat ook alweer de classname was voor het spannetje dat om de datum heenmoet.

Welke engine je dan vervolgens kiest, is van heel veel factoren afhankelijk. In de eerste plaats waarschijnlijk performance. In de tweede plaats de tools die ze bieden. In de derde plaats gemak en smaak.

Ronde 1: Performance is voor een fatsoenlijke engine geen issue. Eenmalige compilatie van templates naar PHP is verwaarloosbaar. Eigenlijk zou dat ook onderdeel moeten zijn van je deployment strategie, dus dan is het helemaal een non-issue. 1 - 1, gelijkspel.

Ronde 2: Hier geldt dat je sowieso niet alleen PHP nodig hebt. Je hebt meer nodig, al is het alleen al een functie die je consequent aan kan roepen om je templates te renderen. Laten we Zend_View als voorbeeld nemen. Een laag bovenop PHP om op eenduidige manier al je waardes te laten voorzien van HTML. Feitelijk ook een template engine, maar dan gebaseerd op PHP template files. Als een eerlijke vergelijking doet op dit punt, maakt het niet uit of je voor de één of de ander kiest, het is gewoon een toolset om je te laten focussen op je taak. Laten we er in ieder geval over eens zijn dat "alleen PHP" niet voldoende is voor een eerlijke vergelijking. 2 - 2, gelijkspel

Ronde 3: gemak en smaak. Dit is natuurlijk aan jezelf, maar als ik Zend_View of Drupal templates vergelijk met Smarty en Twig templates dan moet ik toch de voorkeur geven aan de laatste. De syntax is cleaner, het is minder typwerk, je hebt minder overhead aan code om eenvoudige taken uit te voeren en het is minder foutgevoelig.

Feitelijk kun je eenzelfde soort discussie voeren over configuratie-bestanden. Waarom zou je INI, XML, YML, JSON of whatever gebruiken om je applicaties te configureren als het ook in PHP kan? Simpel: het is makkelijker en minder foutgevoelig, maar vooral: het focust op de taak en verantwoordelijkheid van dat onderdeel van je applicatie.

Nogmaals: performance en overhead zijn, zoals de amerikanen dat zo mooi zeggen, "moot". Doet er niet toe, want dat is "taken care of". Overhead is betrekkelijk: je hebt net zo goed een lap code nodig om met PHP op hetzelfde tool-niveau te komen als een andere template engine (zoals je kunt zien aan Zend_View). Daarnaast zijn we natuurlijk allemaal bekend met de uitspraak over premature optimization. Performance is verder, zoals gezegd, een non issue.

Uiteindelijk is dus de vraag: wat vind je prettiger, en wat is beter task-oriented?

Ik durf wel te stellen dat iedereen die eerst een maand templates moet implementeren met plain PHP en daarna een maand met een template taal, na die twee maanden nooit meer omkijkt naar PHP. Niet alleen vanwege de syntax (want die is zoals gezegd ondergeschikt) maar ook vanwege het werk wat je uit handen wordt genomen. Daar kun je het mee oneens zijn, maar ik denk dat je dan gewoon te weinig templates getypt hebt in je leven.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

chielsen

Verwijderd schreef op donderdag 10 februari 2011 @ 12:09:
@FragFrog ... ik heb ook heel wat crappy shit gezien ... van het querien van data midden in een php/html include ... inline dus. Tot het compleet op zijn kop zetten van het MVC model en juist de view gebruiken om de controller/core aan te spreken, dus eigenlijk een template laag maken die bepaalt wat er in de core aangeroepen gaat worden.

In principe is het zelfs in Zend Framework mogelijk om queries in een view te doen, common sense zou dat tegen moeten gaan

Ik heb ook lopen harken met zo'n gebeund project, je wordt er niet goed van. Het gebruikt smarty die vanuit de templates alle logica gaat aanroepen

zaterdag 12 februari 2011 15:59

Acties:

zaterdag 12 februari 2011 17:07

@drm

Ronde 1: overhead zit hem niet alleen in performace, maar ook in het aanleren van een nieuwe syntax. Als je PHP al kent, waarom jezelf pijnigen om een nieuwe syntax te leren (Smarty) die niets toevoegt? Dus geen gelijkspel, maar 0-1 tegen Smarty.

Ronde 2: Zend_View is volledig PHP, dus "alleen PHP" is wel voldoende. Je schrijft je templates in PHP, je geeft ze aan Zend_View (ook PHP) en alles gaat goed. Dus geen gelijkspel, maar 0-2 tegen Smarty

Ronde 3: dat de syntax cleaner is, minder typwerk, minder overhead en minder foutgevoelig is ook een kwestie van smaak, dus geen goed punt vóór Smarty.

Acties:

zaterdag 12 februari 2011 17:19

f0pc0dert

Php

HuHu:
Ronde 1: overhead zit hem niet alleen in performace, maar ook in het aanleren van een nieuwe syntax. Als je PHP al kent, waarom jezelf pijnigen om een nieuwe syntax te leren (Smarty) die niets toevoegt? Dus geen gelijkspel, maar 0-1 tegen Smarty.

De syntax voegt misschien niet zo veel toe, maar dat is niet alles wat Smarty toevoegt. Het leren van een nieuwe syntax kan inderdaad wel als een nadeel gezien worden. Je kan het natuurlijk ook als een gelegenheid zien om weer eens wat bij te leren. Met Zend_View heb je trouwens net zo goed een hoop bij te leren. Dus dat is niet echt een argument.

Ronde 2: Zend_View is volledig PHP, dus "alleen PHP" is wel voldoende. Je schrijft je templates in PHP, je geeft ze aan Zend_View (ook PHP) en alles gaat goed. Dus geen gelijkspel, maar 0-2 tegen Smarty

Zend_View is wel PHP, maar niet alle PHP is Zend_View. Je mist dus mijn punt.

Ronde 3: dat de syntax cleaner is, minder typwerk, minder overhead en minder foutgevoelig is ook een kwestie van smaak, dus geen goed punt vóór Smarty.

Is misschien wel een kwestie van smaak, maar imho ook van ervaring.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

zaterdag 12 februari 2011 18:01

drm schreef op zaterdag 12 februari 2011 @ 17:07:
[...]
De syntax voegt misschien niet zo veel toe, maar dat is niet alles wat Smarty toevoegt. Het leren van een nieuwe syntax kan inderdaad wel als een nadeel gezien worden. Je kan het natuurlijk ook als een gelegenheid zien om weer eens wat bij te leren. Met Zend_View heb je trouwens net zo goed een hoop bij te leren. Dus dat is niet echt een argument.

Ik leer liever wat nuttigs bij, zoals een volledig nieuwe programmeertaal, dan een alternatieve syntax voor een bestaande taal. Want dat is Smarty tenslotte.

Bij Zend_View hoef je alleen het concept te leren, bij Smarty leer je het concept en een syntax.

[...]
Zend_View is wel PHP, maar niet alle PHP is Zend_View. Je mist dus mijn punt.

Ik mis je punt zeker, want ik begrijp deze zin niet. Laten we je vorige opmerking even ontleden:

Hier geldt dat je sowieso niet alleen PHP PHP is een taal, maar jij zegt dat je méér nodig hebt dan die taal nodig hebt. Je hebt meer nodig, al is het alleen al een functie een functie is onderdeel van de taal, dus nog steeds PHP die je consequent aan kan roepen om je templates te renderen. Laten we Zend_View als voorbeeld nemen. Een laag bovenop niet bovenop, het is gewoon een klasse in PHP, niet "erbovenop". Smarty ligt er bovenop, omdat je het daarna moet hercompileren naar PHP en de syntax anders is. PHP om op eenduidige manier al je waardes te laten voorzien van HTML. Feitelijk ook een template engine correct, maar dan gebaseerd op PHP template files ook correct. Als een eerlijke vergelijking doet op dit punt, maakt het niet uit of je voor de één of de ander kiest niet correct, Zend_View is in PHP, dus dezelfde syntax. Smarty heeft z'n eigen syntax en is dus geen PHP, het is gewoon een toolset om je te laten focussen op je taak. Laten we er in ieder geval over eens zijn dat "alleen PHP" niet voldoende incorrect, Zend_View is alleen PHP is voor een eerlijke vergelijking. 2 - 2, gelijkspel

Opmerkingen van mij staan in bold. Waar mis ik je punt? Volgens mij doe jij foute aannames.

[...]
Is misschien wel een kwestie van smaak, maar imho ook van ervaring.

Ik zou niet het woord "ervaring" gebruiken, maar meer "gewenning". Iemand die geen Smarty kent zou er niet aan moeten beginnen. Zit je er al in, tsja...

Acties:

Verwijderd

HuHu schreef op zaterdag 12 februari 2011 @ 17:19:

Ik leer liever wat nuttigs bij, zoals een volledig nieuwe programmeertaal, dan een alternatieve syntax voor een bestaande taal. Want dat is Smarty tenslotte.

Smarty is geen alternatieve syntax, en in theorie kun je templates ook andere code laten genereren.

Ik wil nogmaals de vergelijking maken met code generators zoals Flex en Bison.

De output van die tools is een parser in C code die je zelf ook had kunnen schrijven. De invoerbestanden hebben een eigen syntax, maar je kunt wel C code schrijven die (bijna) 1 op 1 wordt overgenomen in de uiteindelijke C code.

Als je voor een kleinschalig project een simpele parser moet maken is het inderdaad de vraag of je code generators moet gebruiken. Die zijn soms best ingewikkeld en een het kan een bitch zijn om ermee te leren werken. Als je eenvoudige input moet analyseren zou je best wat handmatig in C kunnen schrijven. Bij ingewikkelde input wil je dat echt niet.

HuHu schreef op zaterdag 12 februari 2011 @ 17:19:
Iemand die geen Smarty kent zou er niet aan moeten beginnen. Zit je er al in, tsja...

Nou, vertel dan eens. Heb je ooit gewerkt met Smarty in een project van enige omvang?

Ik heb een paar uur besteed aan het leren van de syntax (want die is toch wel zo ingewikkeld joh!), een aantal uren aan het integreren in een framework, een aantal uren aan het schrijven van wat eigen modifiers, en ik heb honderden uren bespaard.

Hoe ik weet dat ik honderden uren heb bespaard? Dat weet je vanzelf als je een uur of tienduizend als webdeveloper werkt. Want ja, inderdaad, het gaat alleen tijd besparen als je er veel mee doet.

zaterdag 12 februari 2011 18:19

Acties:

zaterdag 12 februari 2011 20:59

Verwijderd schreef op zaterdag 12 februari 2011 @ 18:01:
[...]

Smarty is geen alternatieve syntax, en in theorie kun je templates ook andere code laten genereren.

Smarty presenteert zichzelf op de eigen website wel als syntax. Uiteraard zou je in theorie Smarty templates ook kunnen gebruiken om Java, ASP, enz... code te laten genereren. Maar dat kan ook met PHP templates.

Ik wil nogmaals de vergelijking maken met code generators zoals Flex en Bison.

De output van die tools is een parser in C code die je zelf ook had kunnen schrijven. De invoerbestanden hebben een eigen syntax, maar je kunt wel C code schrijven die (bijna) 1 op 1 wordt overgenomen in de uiteindelijke C code.

Als je voor een kleinschalig project een simpele parser moet maken is het inderdaad de vraag of je code generators moet gebruiken. Die zijn soms best ingewikkeld en een het kan een bitch zijn om ermee te leren werken. Als je eenvoudige input moet analyseren zou je best wat handmatig in C kunnen schrijven. Bij ingewikkelde input wil je dat echt niet.

[...]

Nou, vertel dan eens. Heb je ooit gewerkt met Smarty in een project van enige omvang?

Ik heb een paar uur besteed aan het leren van de syntax (want die is toch wel zo ingewikkeld joh!), een aantal uren aan het integreren in een framework, een aantal uren aan het schrijven van wat eigen modifiers, en ik heb honderden uren bespaard.

Hoe ik weet dat ik honderden uren heb bespaard? Dat weet je vanzelf als je een uur of tienduizend als webdeveloper werkt. Want ja, inderdaad, het gaat alleen tijd besparen als je er veel mee doet.

Ik ben Development Admin geweest bij FOK! (http://www.fok.nl/), daar gebruik(t)en ze Smarty. Mag ik dat als "project van enige omvang" opvoeren?

Verder is een uur of tienduizend ongeveer 6 jaar fulltime Smarty-werk. Aangezien Smarty pas sinds 2002 bestaat ben je dus een redelijke "early adopter", als ik dat zo mag noemen. Heb je in al die uren dat je 100% aan Smarty besteedde ooit gekeken naar andere template-engines, zoals Zend_View? Toevallig heb ik daar ook ervaring mee en dat werkt veel beter dan Smarty.

Volgens mij bespaar je tijd door met een template-engine te werken, dingen als MVC te implementeren, enz... Niet door Smarty te gebruiken. Zeggen dat je alleen tijd bespaart door Smarty en niet door, bijvoorbeeld, Zend_View is een beetje kortzichtig.

Acties:

zaterdag 12 februari 2011 21:05

f0pc0dert

Php

offtopic:
Ik begrijp niet waarom ik me toch weer laat verleiden deze discussie te voeren...

HuHu:
Volgens mij doe jij foute aannames.

Ik zou niet weten waar je dat op baseert. Ik doe helemaal geen aannames, want ik weet namelijk best wel waar ik het over heb.

HuHu:
Opmerkingen van mij staan in bold. Waar mis ik je punt?

Je komt elke keer terug op de syntax. En daarin begrijp je me dus verkeerd. De syntax is in de vergelijking tussen Zend_View en Smarty van ondergeschikt belang. De tools zijn van dezelfde orde, namelijk dat ze je een set hulpmiddelen bieden om templates mee te bouwen. De één gebruikt PHP, de ander een eigen taal. Maar het feit dát ze verschillende talen gebruiken, is geen reden om te zeggen dat één van de twee in zijn geheel onzin is om te gebruiken. Zend_View is daar het levende bewijs van, want als je, naast een kale PHP installatie, niks nodig had gehad, waarom bestaat Zend_View dan? Het feit dat Smarty een taal biedt binnen de toolset vind ik een groot voordeel, maar dat is een kwestie van smaak. Ik weet niet hoe ik het beter uit moet leggen, volgens mij is het kraakheldere logica... De verwarring zit 'm steeds in het feit dat men denkt dat als je een template engine verdedigt, je puur het gebruik van een andere taal voor je templates verdedigt. Ik probeer duidelijk te maken dat een template engine sowieso al meer is dan een taal, Zend_View is daar een goed voorbeeld van. Het is dus onterecht om te zeggen dat PHP een goed alternatief is voor iets als Smarty, want dat zou betekenen dat PHP ook een goed alternatief zou zijn voor Zend_View. Namelijk, als dat niet klopt, dat heeft Zend_View geen bestaansrecht. Dat bedoel ik met de opmerking dat Zend_View PHP is, maar niet alle PHP is Zend_View. M.a.w., als je Zend_View gebruikt, gebruik je wel PHP voor je templates, maar als je PHP gebruikt voor je templates, kan iets als Zend_View je nog wel een hele hoop werk uit handen nemen. Net als elke andere template engine.

HuHu:
Ik zou niet het woord "ervaring" gebruiken, maar meer "gewenning". Iemand die geen Smarty kent zou er niet aan moeten beginnen. Zit je er al in, tsja...

Ik bedoel simpelweg ervaring in implementatie van templates. Ik geloof wel dat ik mag zeggen daar wat ervaring mee te hebben. Templates in PHP bouwen is gewoon een rotwerk, in een handige templatetaal veel beter te verteren. Toegegeven, dat is mijn ervaring, maar ik daag iedere voorstander van PHP templates uit het een serieuze kans te geven, en het niet op voorhand met drogredenen af te wijzen.

En doe het dan met Twig, en niet met Smarty, Twig zit namelijk een stuk beter in elkaar

edit:

Volgens mij bespaar je tijd door met een template-engine te werken, dingen als MVC te implementeren, enz... Niet door Smarty te gebruiken.

Lees dit nog eens terug, want je spreekt hier jezelf direct tegen.

Zeggen dat je alleen tijd bespaart door Smarty en niet door, bijvoorbeeld, Zend_View is een beetje kortzichtig.

Dat zeg ik dus ook niet.

[ Voor 7% gewijzigd door drm op 12-02-2011 21:01 ]

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

zaterdag 12 februari 2011 21:40

drm schreef op zaterdag 12 februari 2011 @ 20:59:
Templates in PHP bouwen is gewoon een rotwerk, in een handige templatetaal veel beter te verteren.

Geef dan eens een goed voorbeeld waarom? In mijn ogen is er geen verschil behalve een alternatieve syntax door een tussenlaag toe te voegen. Een template in PHP is niks anders dan html met je presentatie-logica (loopen door je records, escaping etc) en of je dat in native PHP doet of in Smarty-syntax is toch vrijwel hetzelfde (behalve dat je voor PHP geen alternative syntax en een nieuwe laag cache nodig hebt).

Acties:

zaterdag 12 februari 2011 21:53

f0pc0dert

Php

Cartman!:
Geef dan eens een goed voorbeeld waarom?

Ik twijfel aan mijn eigen capaciteit om iemand ervan te kunnen overtuigen zonder dat de persoon in kwestie bereidwillig zou zijn om het een serieuze kans te geven. Ik geloof namelijk niet dat voorbeelden kunnen overtuigen, daarvoor heb ik dit soort discussies al te vaak gezien.

Het enige voorbeeld dat ik je kan geven is: open een texteditor en typ twintig keer achter elkaar {{ var }} en twintig keer <?=$var?>. Ik ben benieuwd wat je prettiger vindt. Los van alle implicaties en eventuele vooroordelen.

edit:
En doe hetzelfde voor {{ var.property }} en <?=$var['property']?>

[ Voor 6% gewijzigd door drm op 12-02-2011 22:03 ]

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

CH4OS

It's a kind of magic

Verwijderd schreef op woensdag 09 februari 2011 @ 16:52:
Of
PHP:
1
<?= $tpl_vars['foo']; ?>

Als short-tags aanstaan wel ja, anders niet.

zaterdag 12 februari 2011 22:45

Acties:

RetroTycoon

Maar hoe wil je in zo'n engine herhalende code vermijden? Want sommige delen zullen toch vaker moeten worden geparsed... Of maak ik een fundamentele denkfout...

zaterdag 12 februari 2011 23:01

Acties:

zaterdag 12 februari 2011 23:17

RetroTycoon schreef op zaterdag 12 februari 2011 @ 22:45:
Maar hoe wil je in zo'n engine herhalende code vermijden? Want sommige delen zullen toch vaker moeten worden geparsed... Of maak ik een fundamentele denkfout...

In Smarty een kwestie van de herhaalde blokken in aparte template files zetten. Vervolgens roep je die aan met {include file="filename.tpl"}. Vrij simpel dus. Als je het complexer wilt maken kun je ook variabelen toewijzen aan die include en op die manier bijvoorbeeld ook recursieve elementen gebruiken.

[ Site ] [ twitch ] [ jijbuis ]

Acties:

zondag 13 februari 2011 11:17

RetroTycoon schreef op zaterdag 12 februari 2011 @ 22:45:
Maar hoe wil je in zo'n engine herhalende code vermijden? Want sommige delen zullen toch vaker moeten worden geparsed... Of maak ik een fundamentele denkfout...

Als je bedoelt dat je veel code logic in een template aan het schrijven bent, dan is juist die template taal je eye opener dat je teveel logica op de verkeerde plek in je systeem aan
het maken bent en je dat dus op een ander nivo moet of kunt oplossen.

Voor het geval dat je veel herhalende stukken hebt in de vorm van menu's etc. Daar heb je includes en of macro's voor.

Driving a cadillac in a fool's parade.

Acties:

zondag 13 februari 2011 14:13

drm schreef op zaterdag 12 februari 2011 @ 20:59:

[...]
Lees dit nog eens terug, want je spreekt hier jezelf direct tegen.

Ik spreek mezelf niet tegen. Ik ben vóór template engines, vóór MVC, maar ik vind Smarty niet de juiste tool.

Het probleem is dat heel veel mensen denken dat als je template engines wil gebruiken, je Smarty moet gebruiken, "want dat is een template engine". Dat slaat nergens op, Smarty is nutteloze overhead, zoals ik in mijn eerste post al zei. Je kunt prima templates maken in PHP, of een hulpmiddel als Zend_View gebruiken.

Het gaat erom dat je het concept moet implementeren en niet de tool. En daar gaat het mis bij velen, want die denken dat als ze ergens Smarty gebruiken ze meteen goed op weg zijn om templates te implementeren.

En als dan in de eerste post van een topic over het concept van een template engine meteen wordt geroepen dat je Smarty moet gebruiken, dan verdien je niets anders dan een gigantisch lading aan back-fire.

Acties:

zondag 13 februari 2011 15:13

f0pc0dert

Php

HuHu:
Ik spreek mezelf niet tegen. Ik ben vóór template engines, vóór MVC, maar ik vind Smarty niet de juiste tool.

Het probleem is dat heel veel mensen denken dat als je template engines wil gebruiken, je Smarty moet gebruiken, "want dat is een template engine". Dat slaat nergens op, Smarty is nutteloze overhead, zoals ik in mijn eerste post al zei. Je kunt prima templates maken in PHP, of een hulpmiddel als Zend_View gebruiken.

Het gaat erom dat je het concept moet implementeren en niet de tool. En daar gaat het mis bij velen, want die denken dat als ze ergens Smarty gebruiken ze meteen goed op weg zijn om templates te implementeren.

En als dan in de eerste post van een topic over het concept van een template engine meteen wordt geroepen dat je Smarty moet gebruiken, dan verdien je niets anders dan een gigantisch lading aan back-fire.

OK, dan zijn we het misschien meer eens dan je op het eerste gezicht zou zeggen. De twee punten gedistilleerd waar we het (volgens mij) over oneens zijn:

(...) Dat slaat nergens op, Smarty is nutteloze overhead, zoals ik in mijn eerste post al zei. (...)

Dan toch de vraag: Waar zit die overhead dan, volgens jou? Want dat argument blijft maar terugkomen, maar het is zo vaag. Leg eens uit wat je daar precies mee bedoelt.

Je kunt prima templates maken in PHP, of een hulpmiddel als Zend_View gebruiken.

"Prima" ben ik het niet mee eens. Het kán, ja. Het is ook niet per se een verkeerde keuze. Maar of het ook prima kan... Nah. Als je liever kramp in je rechterhand krijgt met het typen van PHP delimiters, be my guest

Ik pas daar voor. Maar ik geloof wel dat we daar niet uitkomen, in dat opzicht wat mij betreft agreed to disagree.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

ZpAz

Het enige verschil wat Smarty bied ten opzichte van Zend View is het verschil in syntax, vind je dat prettiger, dan gebruik je Smarty. Maar je hoeft niet persee een 'Smarty like' systeem te gebruiken om het idee achter templates toe te passen.

Zelf ben ik trouwens een Zend View gebruiker. Het is mogelijk om Smarty in combinatie met Zend View te gebruiken, heb ik zelf ook in één project gedaan, maar ik vond het te weinig meerwaarde bieden. Alleen Zend View is voor mij genoeg. (Ik gebruikte namelijk eerst smarty met een eigen framework en ben later overgestapt op Zend)

[ Voor 8% gewijzigd door ZpAz op 13-02-2011 15:14 ]

Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF

zondag 13 februari 2011 15:39

Acties:

maandag 14 februari 2011 09:29

drm schreef op zondag 13 februari 2011 @ 14:13:
[...]
OK, dan zijn we het misschien meer eens dan je op het eerste gezicht zou zeggen. De twee punten gedistilleerd waar we het (volgens mij) over oneens zijn:

[...]
Dan toch de vraag: Waar zit die overhead dan, volgens jou? Want dat argument blijft maar terugkomen, maar het is zo vaag. Leg eens uit wat je daar precies mee bedoelt.

HuHu schreef op zaterdag 12 februari 2011 @ 15:59:
@drm

Ronde 1: overhead zit hem niet alleen in performace, maar ook in het aanleren van een nieuwe syntax. Als je PHP al kent, waarom jezelf pijnigen om een nieuwe syntax te leren (Smarty) die niets toevoegt?

Je moet een nieuwe tool leren, nieuwe syntax leren, het heeft z'n eigen tekortkomingen en beperkingen, enz... Dat is overhead die je niet wil hebben als het niet hoeft. Het gebruik van templates is nuttig, maar het gebruik van templates in een speciaal daarvoor ontworpen syntax die in feite niets toevoegt aan de taal is niet nuttig. Het enige wat het toevoegt zijn beperkingen, waar je met veel moeite ook weer omheen kunt.

[...]
"Prima" ben ik het niet mee eens. Het kán, ja. Het is ook niet per se een verkeerde keuze. Maar of het ook prima kan... Nah. Als je liever kramp in je rechterhand krijgt met het typen van PHP delimiters, be my guest Ik pas daar voor. Maar ik geloof wel dat we daar niet uitkomen, in dat opzicht wat mij betreft agreed to disagree.

Ach, of je nu steeds { of <?= moet typen, dat maakt ook niet zo heel veel uit. Een goede editor kan je daar zelfs bij helpen, zodat het helemaal niets meer uit maakt.

Acties:

maandag 14 februari 2011 14:10

ff kijken hoor, voor een { kan ik twee toetsen tegelijkertijd in drukken zonder rare vinger bewegingen. voor een <?= moet ik shift indrukken, toets aan slaan, shift los laten, hand verplaatsen, andere toets aan slaan. Dan weer de shift indrukken. Dus nee, doe mij dan maar die { syntax.

(om maar te zwijgen van het feit dat short-tags niet overal aan staan, en het een 'gevaarlijke' aanname kan zijn)

Buiten omdat zijn het vooral theoritische tekort komingen die je hebt, want als je daadwerkelijk een tekort koming hebt een taal waar je prima foreach loops, if's en echo dingen doet, moet je je afvragen wat ik hierboven ook al aangaf. Stop je niet teveel logica in je template's zelf

Driving a cadillac in a fool's parade.

Acties:

ZpAz

kwaakvaak_v2 schreef op maandag 14 februari 2011 @ 09:29:

(om maar te zwijgen van het feit dat short-tags niet overal aan staan, en het een 'gevaarlijke' aanname kan zijn)

Volgens mij werken short-tags ook in Zend View als deze niet aan staan, dat hij het dan zelf parsed oid, maar dat weet ik niet zeker. Maar heb nog nooit het probleem gehad dat short-tags niet aanstaan.

Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF

maandag 14 februari 2011 14:41

Acties:

maandag 14 februari 2011 20:58

kwaakvaak_v2 schreef op maandag 14 februari 2011 @ 09:29:
ff kijken hoor, voor een { kan ik twee toetsen tegelijkertijd in drukken zonder rare vinger bewegingen. voor een <?= moet ik shift indrukken, toets aan slaan, shift los laten, hand verplaatsen, andere toets aan slaan. Dan weer de shift indrukken. Dus nee, doe mij dan maar die { syntax.

(om maar te zwijgen van het feit dat short-tags niet overal aan staan, en het een 'gevaarlijke' aanname kan zijn)

Buiten omdat zijn het vooral theoritische tekort komingen die je hebt, want als je daadwerkelijk een tekort koming hebt een taal waar je prima foreach loops, if's en echo dingen doet, moet je je afvragen wat ik hierboven ook al aangaf. Stop je niet teveel logica in je template's zelf

<?= doe je door shift in te drukken, vervolgens de <? te typen, shift loslaten en daarna de =. Maar zoals ik al zei, een goede editor of IDE helpt je daarbij. Als je in, bijvoorbeeld, Zend Studio de < of <? typt, wordt de rest automatisch aangevuld. Daarnaast kun je dat soort short-cuts allemaal configureren. Desnoods stel je in dat {$var} automatisch wordt vervangen door <?=$var?> en je bent helemaal klaar.

Oftewel, met de juiste tools verminder je het aantal toetsaanslagen. En de juiste tool is een goede editor en niet Smarty.

Acties:

ameesters

kwaakvaak_v2 schreef op maandag 14 februari 2011 @ 09:29:
ff kijken hoor, voor een { kan ik twee toetsen tegelijkertijd in drukken zonder rare vinger bewegingen. voor een <?= moet ik shift indrukken, toets aan slaan, shift los laten, hand verplaatsen, andere toets aan slaan. Dan weer de shift indrukken. Dus nee, doe mij dan maar die { syntax.

(om maar te zwijgen van het feit dat short-tags niet overal aan staan, en het een 'gevaarlijke' aanname kan zijn)

Buiten omdat zijn het vooral theoritische tekort komingen die je hebt, want als je daadwerkelijk een tekort koming hebt een taal waar je prima foreach loops, if's en echo dingen doet, moet je je afvragen wat ik hierboven ook al aangaf. Stop je niet teveel logica in je template's zelf

Het gaat er ook niet om of jij meer of minder toetsen moet indrukken, het gaat erom of je de overhead van een template engine kan rechtvaardigen tegenover je eindgebruikers. dat jij minder typt interesseren ze namelijk niets, als hun langer moeten wachten door een luie programmeur, dat merken ze wel!

Dat het vanuit een designers perspectief enige waarde zou toevoegen is ook een non-argument, ze zullen toch een opgeknipte template afleveren waar wij programeurs mee aan de slag moeten, in de praktijk hebben ze er dus niks aan. Daarom kan je beter gewoon php gebruiken zonder tussenlaag, en als je jezelf dwingt juist gebruik te maken van een goede design pattern, zal het kwa functies niet veel verschillen van een template engine, behalfe die paar tekens meer die je moet typen.

Ook short tags is geen probleem als je controle heb op je omgeving, voor een hostile omgeving zou je natuurlijk kunnen kijken of het aanstaat, en zo niet, het in run-time aanzetten, wat de betere hosting-boeren wel aan hebben staan, aangezien er talloze applicaties van de short tags gebruik maakt.

dus gebruik van een template engine niet doen, er bestaat namelijk geen argument die het noodzakelijk maakt, want uiteindelijk blijft het logica in de template, je presenteert het alleen anders...

maandag 14 februari 2011 21:50

Acties:

maandag 14 februari 2011 22:07

leipepo schreef op maandag 14 februari 2011 @ 20:58:
[...]
Dat het vanuit een designers perspectief enige waarde zou toevoegen is ook een non-argument, ze zullen toch een opgeknipte template afleveren waar wij programeurs mee aan de slag moeten, in de praktijk hebben ze er dus niks aan.

Neehee, een designer hoort te designen en een frontender knipt het op waarna een backender de boel verwerkt met server-side code. Wat voor bedrijven werkt iedereen hier zeg dat designers ook code tikken. Dat een frontender ook backend doet of andersom is nog te begrijpen dan maar verder...

Acties: