[tartareandesire]

Denna fråga riktar sig endast till de som arbetar med PHP. Frågan är vilken template-motor ni använder mest och varför?

Jag själv har tidigare använt Dwoo en hel del men nu är det Twig som gäller när jag kör Symfony.

Kan passa på att tipsa om Fabien Potenciers rätt gamla men utmärkta blogginlägg på temat:

http://fabien.potencier.org/article/...engines-in-php

[Kimppa]

Jag kör utan någon sånt. Bara egen kod (nyskriven eller återanvänd).

Känns som att man har mer kontroll på det sättet istället för att jobba i Zend eller liknande.

[linusoleander]

Ursprungligen postat av Kimppa

Jag kör utan någon sånt. Bara egen kod (nyskriven eller återanvänd).

Känns som att man har mer kontroll på det sättet istället för att jobba i Zend eller liknande.

Det är inget ramverk TS pratar om utan ett templatespråk. Sedan så får du gärna förklara kontrollpåstpendet. Borde inte ett ramverk ge motsatt effekt då mindre kod skrivs vilket man skulle argumentera för är enklare att underhålla/testa/dokumentera?

[Kimppa]

Ursprungligen postat av linusoleander

Det är inget ramverk TS pratar om utan ett templatespråk. Sedan så får du gärna förklara kontrollpåstpendet. Borde inte ett ramverk ge motsatt effekt då mindre kod skrivs vilket man skulle argumentera för är enklare att underhålla/testa/dokumentera?

Hej!

Okej, är inte insatt i ramverk eller templates för PHP i så fall.

I början ger det självklart en motsatt effekt, men när man väl har klasser etc. så går det ju snabbt att implementera de i nya projekt (och då har man även 100% kontroll över den kod som finns då man själv skrivit allt).

Jag tycker att det är "lite fusk" att använda sig av färdiga CMS, TS, templates, etc. (Ungefär som att installera WordPress för att få en hemsida istället för att koda en egen). Men alla kanske inte har kunskaperna eller tid för att göra allt från grunden så förstår ju varför folk använder dessa verktyg också.

Nu ska jag läsa på om "template motor"

Mvh,
Kim

[HenrikAI]

Största sajten, och den jag jobbar överlägset mest med, använder Smarty3. Det är ett 4-5 år gammalt val och jag minns inte exakt varför det blev Smarty.

Jag har en hel del äldre sajter också som inte använder någon template-motor, men i nyare projekt använder jag Twig, främst på grund av att de byggts på Symfony eller Silex. Jag överväger att prova Blade i ett kommande projekt.

Så.. jag använder ett par olika, men mest tid blir det med Smarty3.

Kimpaa: Det går utmärkt att använda en template-motor utan att använda ett helt ramverk. Man skriver egen kod dessutom, men med ett annat syntax.

[Clarence]

Ursprungligen postat av Kimppa

Jag tycker att det är "lite fusk" att använda sig av färdiga CMS, TS, templates, etc. (Ungefär som att installera WordPress för att få en hemsida istället för att koda en egen). Men alla kanske inte har kunskaperna eller tid för att göra allt från grunden så förstår ju varför folk använder dessa verktyg också.

Nu ska jag läsa på om "template motor"

Mvh,
Kim

Med den argumentationen borde det bästa vara att bygga dina webbtjänster direkt istället för att använda ett färdigt OS, webbserver och högnivåspråk.

Ramverk handlar om att få en bra struktur som har arbetats mer med av kompetenta människor än vad du någonsin kommer sitta med någon sajt totalt. Vet du inte vad en template motor är ännu så kan jag dock förstå om du finner ramverk väldigt begränsande och jobbiga till en början då det nog måste betyda att du inte har ett presentationslager i dina sajter. Men om du lär dig bygga sajter i ett bra MVC-ramverk (t ex Symfony2 eller Laravel) så förändrar du nog din syn på det med tiden.

En bild jag tror stämmer, både utifrån egna erfarenheter men också genom att ha läst och hört ungefär detsamma många gånger:
- Först bygger man sajter utan ramverk för att man tror att man gör allt minst lika bra som ramverken och inte vill ha massa extra bloat.
- Sen börjar man använda ett ramverk och ser vilka smidiga funktioner man faktiskt saknat i sin egen kod.
- Efter lite irritation med ramverket och dess brister skriver man istället ett eget ramverk för sina applikationer och gör vissa saker på sätt man tycker är mycket bättre än ramverk X. Här får vissa hybris och släpper sitt ramverk om det hetaste och bästa nu. 999 av 1000 blir inte bekräftade av communityn för att det inte stämmer. Alternativ till detta steg är att börja använda enbart micro-frameworks till precis allt och ofta aldrig komma till nästa steg.
- Som sista steg går man tillbaka till att mestadels använda fullstack ramverk igen. Men är väl medveten om att det finns tillfällen då man vill ha ett micro-framework eller jobba helt utan.

Och on-topic:
Twig.

[Kimppa]

Med den argumentationen borde det bästa vara att bygga dina webbtjänster direkt istället för att använda ett färdigt OS, webbserver och högnivåspråk.

Nu behöver man ju inte överdriva.

Förstår inte varför folk blir så upprörda över att jag väljer att göra saker själv.

Jag har bra självförtroende när det gäller webbutveckling och vet att jag gör bra webbplatser, så har ingen användning av ett framework eller något annat som "förenklar" min utvecklingsprocess. Tycker PHP's syntax är bra som den är och tycker det är kul att programmera.

Jag har åtminstone börjat använda mig av IDE istället för att skriva allt i Notepad (liten förbättring).

Sen lyckas man ju inte alltid med sina projekt bara för att man tar samma väg som alla andra (kanske en dum mening eftersom många lyckas genom att göra samma sak som många andra ).

[Vebut]

Jag skulle säga att man bör skippa en template-motor, blir sjukt mycket overhead jämfört med PHP som faktiskt i sig är ett template-språk. Varför ska man flytta script'ningen till ytterligare ett lager?

Skulle jag välja någon motor skulle den vara xml eller html baserad så man tar del av DOM, vilket PHP har stöd för i standardutförande.

Många gillar twig och liknande som gör samma jobb som PHP om du bygger funktioner för det. Tänk på att parsing är dyrt.

[Clarence]

Ursprungligen postat av Vebut

Jag skulle säga att man bör skippa en template-motor, blir sjukt mycket overhead jämfört med PHP som faktiskt i sig är ett template-språk. Varför ska man flytta script'ningen till ytterligare ett lager?

Skulle jag välja någon motor skulle den vara xml eller html baserad så man tar del av DOM, vilket PHP har stöd för i standardutförande.

Många gillar twig och liknande som gör samma jobb som PHP om du bygger funktioner för det. Tänk på att parsing är dyrt.

Ett par anledningar för att man enligt mig verkligen inte bör använda PHP som ett template-språk:

- Det är verbose ... <?php htmlspecialchars($object->attribute, ENT_QUOTES, 'UTF-8') ?> vs {{ object.attribute }} (Visst du kan ersätta <?php echo med <?= och förlora kompatibilitet eller så kan du skriva ett kortare funktions-namn utan parametrar ...)
- Det är inte säkert by default. Du har ingen output escaping om du inte själv lägger på den. Glöm den på fel ställe och du är sårbar för XSS. (Precis samma situation som att använda manuell sql escaping). Vanligaste sårbarheterna i större websiter beror på enkla misstag för att man antog det omöjliga - att man alltid gör rätt och aldrig är slarvig.
- Återigen säkerheten. Du har ingen sandboxing i PHP och att låta användare som inte har 100% koll ändra i templates är därmed mycket farligare.
- Dåliga programmerare tenderar att flytta logik till templates eftersom det "funkar lika bra där". Även bättre programmerare har en tendens att först "testa" i templaten och slarv leder lätt till att det blir kvar där. Separation of concerns är ytterst viktigt vid större projekt.
- Frontend-programmerare och designers måste lära sig PHP. Ett template-språk är mer begränsat och framförallt template-orienterat. Du får per default en logik som passar ett presentationslager och därmed är mer lätttillgängligt för de som jobbar med presentation.
- Arv är både krångligt och blir ofta ostabilt om man inte lägger mycket tid på det. Kräver fortfarande egen parsing för att fungera på ett enkelt och logiskt sätt om man tänker på att man är i ett presentationslager. Template-arv är för mig ett måste för allt annat än en väldigt enkel sajt.

Bygger du en lite mer komplicerad sajt med fokus på prestanda är det tvärtom svårt och mycket kod för att vara effektiv. Släng dit lite ESI-controllers, template-arv och asynkron content så har du en slö PHP-röra eller så har du spenderat alldeles för många timmar på att bygga det som redan finns.

Att "parsning" tar resurser för att man använder en template-motor är också ett ytterst tveksamt påstående. Alla vettiga template-system cachar en "kompilerad" PHP-version som sedan bytecode cachas som all övrig kod. Fokuserar man på prestanda bör man ha trafik för det vilket betyder att kompileringen sker på ytterst liten del av requesten oavsett om man bryr sig om att förkompilera dom (vilket man bör göra). Det som sedan är kvar av overheaden är mestadels säkerhetsaspekten och eventuell data-kompatibilitet (t ex variable.field för både attribut och array-access eller automatisk output escaping).

[linusoleander]

Ursprungligen postat av Clarence

Ett par anledningar för att man enligt mig verkligen inte bör använda PHP som ett template-språk:

- Det är verbose ... <?php htmlspecialchars($object->attribute, ENT_QUOTES, 'UTF-8') ?> vs {{ object.attribute }} (Visst du kan ersätta <?php echo med <?= och förlora kompatibilitet eller så kan du skriva ett kortare funktions-namn utan parametrar ...)
- Det är inte säkert by default. Du har ingen output escaping om du inte själv lägger på den. Glöm den på fel ställe och du är sårbar för XSS. (Precis samma situation som att använda manuell sql escaping). Vanligaste sårbarheterna i större websiter beror på enkla misstag för att man antog det omöjliga - att man alltid gör rätt och aldrig är slarvig.
- Återigen säkerheten. Du har ingen sandboxing i PHP och att låta användare som inte har 100% koll ändra i templates är därmed mycket farligare.
- Dåliga programmerare tenderar att flytta logik till templates eftersom det "funkar lika bra där". Även bättre programmerare har en tendens att först "testa" i templaten och slarv leder lätt till att det blir kvar där. Separation of concerns är ytterst viktigt vid större projekt.
- Frontend-programmerare och designers måste lära sig PHP. Ett template-språk är mer begränsat och framförallt template-orienterat. Du får per default en logik som passar ett presentationslager och därmed är mer lätttillgängligt för de som jobbar med presentation.
- Arv är både krångligt och blir ofta ostabilt om man inte lägger mycket tid på det. Kräver fortfarande egen parsing för att fungera på ett enkelt och logiskt sätt om man tänker på att man är i ett presentationslager. Template-arv är för mig ett måste för allt annat än en väldigt enkel sajt.

Bygger du en lite mer komplicerad sajt med fokus på prestanda är det tvärtom svårt och mycket kod för att vara effektiv. Släng dit lite ESI-controllers, template-arv och asynkron content så har du en slö PHP-röra eller så har du spenderat alldeles för många timmar på att bygga det som redan finns.

Att "parsning" tar resurser för att man använder en template-motor är också ett ytterst tveksamt påstående. Alla vettiga template-system cachar en "kompilerad" PHP-version som sedan bytecode cachas som all övrig kod. Fokuserar man på prestanda bör man ha trafik för det vilket betyder att kompileringen sker på ytterst liten del av requesten oavsett om man bryr sig om att förkompilera dom (vilket man bör göra). Det som sedan är kvar av overheaden är mestadels säkerhetsaspekten och eventuell data-kompatibilitet (t ex variable.field för både attribut och array-access eller automatisk output escaping).

Mycket bra sammanfattning! Ska blir intressant och se vad Vebut och Kimppa kontrar med.