16 svar · 825 visningar · startad av Peeer
Hej!
Jag har börjat tröttna lite på de brister som finns i det templatesystem (hemmabygge) som jag använder i dagsläget, och tänkte därför kolla på andra system. Men det finns ju så fruktansvärt många olika varianter (alla gör visst sina egna), så vilket ska jag välja?
De krav jag har:
* Kunna separera htmlkoden från php-koden på ett smidigt sätt.
* Kosta gratis!
Någon som har något tips?
Den koden påminner väldigt mycket om min kod. Kanske skulle ta och modifiera den och köra vidare på den. Den vet jag ju hur den fungerar i alla fall. :)
Det tycker jag. Du ska nog använda ett så tunt template-system som möjligt för att undvika overhead. Kollade du även hans länk till bTemplate?
http://www.massassi.com/bTemplate/
Jag använder sällan templates då jag tycker att följande variant i PHP utan templates:
<?php foreach($users as $user): ?>
<tr>
<td bgcolor="#FFFFFF" align="center"><?=$user['id'];?></td>
<td bgcolor="#FFFFFF"><?=$user['name'];?></td>
<td bgcolor="#FFFFFF"><a href="mailto:<?=$user['email'];?>"><?=$user['email'];?></a></td>
<td bgcolor="#FFFFFF" align="center"><?=($user['banned'] ? 'X' : ' ');?></td>
</tr>
<?php endforeach; ?>
är minst lika ren och läsbar som template-systemens motsvarigheter. Loop med Smarty:
<ul>
{foreach from=$myArray key=k item=v}
<li>{$k}: {$v}</li>
{/foreach}
</ul>
Vad är det du ser för fördelar med templates?
Man uppfinner hjulet på nytt med templates tycker jag.
Peeer skrev:
De krav jag har:
* Kunna separera htmlkoden från php-koden på ett smidigt sätt.
* Kosta gratis!Någon som har något tips?
Enklast är att använda PHP rätt upp och ner som visats i andra inlägg. Syntaxen med "kolon + slutord" är lämplig, då den ger större tydlighet än måsvingar.
Nackdelen är att du har tillgång till just allt som PHP kan och dessutom alla globala variabler. Ingen fara i sig om man är disciplinerad och jobbar ensam.
Den största fördelen med tungviktaren Smarty är inte syntaxen, även om jag gillar "foreachelse" och tycker att det borde finnas i PHP på riktigt, utan att man får en "sandlåda" för mallen, där man kan begränsa funktionaliteten. I en större organisation där olika personer jobbar med olika delar är detta en stor fördel.
Smarty, och ett par andra mallsystem, har dessutom inbyggda funktioner för hel- eller delvis cachning av sidorna, som ger en smidighet i cachningen. Cachning är mycket bra när man börjar få flera sidvisningar i sekunden, om de sidor du bygger inte har en rimlig chans att bli så trafikerade kan du dock vänta med den aspekten.
Compusa skrev:
Vad är det du ser för fördelar med templates?
Det blir så fruktansvärt grötigt med htmlkoden inpetad bland all phpkod. En massa kontextswitchar här och echo:s där.
Men frågan är om våra definitioner på templates skiljer sig lite. Koden i ditt foreach-user-exempel skulle mycket väl kunna vara en template enligt mig (precis som smarty-varianten). Om du däremot tar med koden för att fylla $users-variabeln med data från en databas så är det inte en template längre.
itpastorn > Flera sidvisningar i sekunden lär aldrig den aktuella siten få, så det behöver jag inte oroa mig för.
Peeer skrev:
Om du däremot tar med koden för att fylla $users-variabeln med data från en databas så är det inte en template längre.
Håller inte med. För att fylla arrayen brukar jag gör så här:
<?php foreach (getUsers() as $user): ?>
<tr>
<td bgcolor="#FFFFFF" align="center"><?=$user['id'];?></td>
<td bgcolor="#FFFFFF"><?=$user['name'];?></td>
<td bgcolor="#FFFFFF"><a href="mailto:<?=$user['email'];?>"><?=$user['email'];?></a></td>
<td bgcolor="#FFFFFF" align="center"><?=($user['banned'] ? 'X' : ' ');?></td>
</tr>
<?php endforeach; ?>
Funktionen ligger i en annan fil som inkluderas överst på php-sidan som står för presentationen. Den fil kan kan liknas med en code-behind fil i ASP.net. Innan jag upptäckte att man kunde göra så här så trodde jag att templates var enda utvägen för att få ett rent presentationslager.
Peeer skrev:
Men frågan är om våra definitioner på templates skiljer sig lite. Koden i ditt foreach-user-exempel skulle mycket väl kunna vara en template enligt mig (precis som smarty-varianten).
Koden ovan är ren PHP-kod utan templates. Visst kan man "se" detta som ett template, men du behöver inga externa bibliotek/klasser.
Peeer skrev:
Det blir så fruktansvärt grötigt med htmlkoden inpetad bland all phpkod. En massa kontextswitchar här och echo:s där.
Håller inte med här heller! ;)
Hur kan du tycka att...
<ul>
<?php foreach(getUsers() as $user): ?>
<li><?=$user; ?></li>
<?php endforeach; ?>
</ul>
är så mycket grötigare än:
<ul>
{foreach from=$users item=user}
<li>{$user}</li>
{/foreach}
</ul>
Skillnaden är att "<?" ersätts med "{" och "?>" ersätts med "}". Sedan så blir det lika många kontext-switchar med template-varianten. Jag respekterar din åsikt men vill ha bättre argument :)
Peeer skrev:
En massa kontextswitchar här och echo:s där.
PHP-switchen är ju två tecken, som de flesta system.
Sen använder man inte echo, det är lite av själva idén med att separera koden från outputen.
Visst, ett argument är att många designers inte kan PHP eller programmering alls, och då är det bättre med ett enkelt templatesystem istället.
Men då säger jag: lär er PHP! Det tar några veckor att komma igång och då får man ju nyttig kunskap.
Att konstruera ett nytt "språk" bara för templates, som sedan tolkas av PHP på nytt innebär ännu ett lager av kod, vilket alltid innebär prestandaförlust.
Nejnejnej, ni missförstår mig.
Compusa > Ditt getUsers()-exempel är helt ok enligt mig. Du anropar en funktion, du har inte själva funktionen i presentationslagret. Det är det som är det viktiga för mig, separera presentation från logiken bakom.
Troxy > Om short_open_tags är avstängt så måste man väl använda sig av echo för att skriva ut saker? <?php=$user ?> fungerar väl inte?
När jag frågade efter en templatemotor så var jag inte ute efter ett system med "egentillverkad" syntax, utan bara ett smidigt sätt att separera logiken från presentationslagret så mycket det går. Att viss phpkod finns med i presentationslagret gör mig inget, men jag vill separera phpkoden från htmlkoden så mycket som möjligt (utan att överdriva med en "eget" kodspråk). Dvs jag tror ni försöker övertyga mig att göra som jag redan gör. :)
Troxy skrev:
Visst, ett argument är att många designers inte kan PHP eller programmering alls, och då är det bättre med ett enkelt templatesystem istället.
Men då säger jag: lär er PHP! Det tar några veckor att komma igång och då får man ju nyttig kunskap.
Men man kanske inte vill att formgivarna ska få tillgång till php-miljön...
Troxy skrev:
Att konstruera ett nytt "språk" bara för templates, som sedan tolkas av PHP på nytt innebär ännu ett lager av kod, vilket alltid innebär prestandaförlust.
Inte nödvändigtvis. En extra lagerabstraktion ger också möjlighet till optimering, t.ex. i form av cachning.
Petiga kommentarer
Peeer skrev:
När jag frågade efter en templatemotor så var jag inte ute efter ett system med "egentillverkad" syntax, utan bara ett smidigt sätt att separera logiken från presentationslagret så mycket det går. Att viss phpkod finns med i presentationslagret gör mig inget, men jag vill separera phpkoden från htmlkoden så mycket som möjligt (utan att överdriva med en "eget" kodspråk). Dvs jag tror ni försöker övertyga mig att göra som jag redan gör. :)
Återigen dags att bli petig, men rätt språkbruk leder oftare till enklare diskussion.
Poängen med mallar är i grunden inte att separera html från logik, utan att separera presentationslogik från affärslogik. Det är alltså helt OK med logik i sina mallar, men inte datainhämtande eller bearbetande dito.
Nästa vinst med mallarna är - som jag sagt tidigare och som sekunderats av andra - att mallen lämpligen körs i en skyddad miljö, fjärran från exempelvis globala variabler och liknande. Ett exempel på detta är Zend_View: http://framework.zend.com/manual/en/zend.view.html
This is a PHP script like any other, with one exception: it executes inside the scope of the Zend_View instance, which means that references to $this point to the Zend_View instance properties and methods.
Den tredje vinsten är att man kan skapa "utility"-metoder och lägga ett lager av abstraktion för att påskynda sin kodning. Mallsystem har ofta stöd för delvis cachning av sidor, vilket är guld värt på en högtrafiksida, som har typ 90 % identiskt innehåll per visning, men 10 % unikt per dito.
Den fjärde aspekten, som jag ser det, är att somliga mallsystem tillhandahåller en alternativ syntax. Om mallsystemet är "kompilerande" som Smarty, eller PHP har inbyggt stöd för syntaxen, d.v.s. om man använder XSLT, så är prestandanedsättningen försumbar. Själv har jag använt just Smarty, och kan se både för- och nackdelar med dess syntax. Viktigaste fördelen är att koden ofta blir mer läsbar och mer naturligt anpassad till sin miljö - att vara en mall. Viktigaste nackdelen är just att det blir YALTL ("yet another language to learn") En annan nackdel är att "ren" PHP ofta stöds av de program som designers gillar, typ Dreamweaver, medan inget sådant program stödjer - mig veterligen - alternativa syntaxer.
itpastorn skrev:
Poängen med mallar är i grunden inte att separera html från logik, utan att separera presentationslogik från affärslogik. Det är alltså helt OK med logik i sina mallar, men inte datainhämtande eller bearbetande dito.
Första meningen instämmer jag i, men den andra meningen är bara halva sanningen mig veterligen. sk. "datainhämtande" (pull ist. för push) är helt okej i View(Template)-lagret, där av saker såsom ViewHelpers och liknande existerar. Vad man föredrar av Push(ge data till view:n) eller Pull(view:n tar den data den behöver) är en smaksak bara.
itpastorn skrev:
Nästa vinst med mallarna är - som jag sagt tidigare och som sekunderats av andra - att mallen lämpligen körs i en skyddad miljö, fjärran från exempelvis globala variabler och liknande. Ett exempel på detta är Zend_View: http://framework.zend.com/manual/en/zend.view.html
Mig veterligen så har man full tillgång till globala variabler i Zend_View, för de icke-php mallar som t.ex. Smarty så stämmer ju detta men verkligen inte för Zend_View.
itpastorn skrev:
Själv har jag använt just Smarty, och kan se både för- och nackdelar med dess syntax. Viktigaste fördelen är att koden ofta blir mer läsbar och mer naturligt anpassad till sin miljö - att vara en mall.
Det låter snyggt när du säger "naturligt anpassad till sin miljö", I'll give you that. Men det är ju så mycket smaksak som det bara går - jag har väldigt svårt för hela foreach/loop-logiken i mallar överhuvudtaget, jag skulle säga att Smarty är så långt ifrån "naturligt" (om vi nu ska nyttja det ordet) man kan komma - konstig "hemmasnickrad" syntax, ingen standardisering, etc.
thr skrev:
Mig veterligen så har man full tillgång till globala variabler i Zend_View, för de icke-php mallar som t.ex. Smarty så stämmer ju detta men verkligen inte för Zend_View.
Nja, i viss mån. Så länge man bara använder $this-variabler, så "skyddet" är baserat mer på konvention än teknik.
thr skrev:
jag har väldigt svårt för hela foreach/loop-logiken i mallar överhuvudtaget
Att använda PHP rakt upp och ner tar ju knappast bort möjligheten. Jag tror att man bör noga tänka över alternativa lösningar till en loop, men för somliga saker är de svåra att lösa utan att det blir konstigt. Om du har sökresultat, eller Allsvenska tabellen :-), så vill åtmoinstone jag ha listans/tabellens gestaltning i mallen.
itpastorn skrev:
fjärran från exempelvis globala variabler och liknande.
itpastorn skrev:
Nja, i viss mån. Så länge man bara använder $this-variabler, så "skyddet" är baserat mer på konvention än teknik.
$this-> konventionen skyddar inte de globala variablerna vad jag vet. Och en konvention är aldrig ett skydd, bara ett antagande.
itpastorn skrev:
Att använda PHP rakt upp och ner tar ju knappast bort
Har aldrig sagt att man ska använda PHP rakt upp och ner, fast det kanske var ett svar till någon annans inlägg.
thr skrev:
$this-> konventionen skyddar inte de globala variablerna vad jag vet. Och en konvention är aldrig ett skydd, bara ett antagande.
Ett skydd baserad på en lättförståelig disciplin. Sämre än äkta skydd, bättre än svårförståelig disciplin. ;-)
thr skrev:
Har aldrig sagt att man ska använda PHP rakt upp och ner, fast det kanske var ett svar till någon annans inlägg.
Ja, det var det. Ursäkta otydligheten.