Template-motor i PHP?
 

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

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?

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

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.

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.

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 ;) ).

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).

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

Kimpaa, du har ju ett "eget" framework ("Kimpaas Framework" typ...), det är inte samma sak som att inte använda ett framework. :-)

Det finns givetvis sunkiga framework, men generellt är det bra att "återanvända" redan skriven och testad kod. Det kan göras på flera olika sätt.

Ett är att använda ett Framework, ett annat är att använda färdiga komponenter som man kan köpa för en billigare peng än att utveckla eget helt från grunden. Det finns alltid en tröskel både för ett Framework och komponenter, samma principer är giltiga oavsett programspråk.

Men jag har en pragmatisk inställning till detta. Man måste göra en bedömning från fall till fall vad som är optimalt mellan att använda:

- Inköpta Framework
- Inköpta komponenter
- Egenutvecklade Framework
- Egenutvecklade Komponenter
- Helt egenutvecklad kod
- Helt outsourcad kod

I verkliga projekt brukar man behöva kunna kombinera dessa delar i olika proportioner, alldeles oavsett vilket programspråk, eller plattform man jobbar med.

Vart tog punkten "OSS-ramverk/bibliotek"?

De sorterar under Inköpta dito, men jag skulle kanske ha valt begrepet 3:e parts i stället för det var det jag menade, dvs sånt man inte gjort själv.

Jag använder Blade mest eftersom det är inbyggt i Laravel. Dock frångått det nästan helt på senare tid till fördel för Angular.

Föredrar oxå templates för att på något sätt komma bort från just att köra ren PHP i view-filer. Det känns lite bakvänt. Då är det bättre med en template-motor, som visserligen kör ett ett språk, men det separerar just övrig kod från view-koden.

Körde förr ren PHP i view-filer, men ack vad rörigt det blir till slut och man fuskar lätt genom att fortsätta köra PHP i view-filer. Nu så i 90% (ärligt) av fallen så sätts alla värden före dom ska finnas tillgängliga i view-filen.

PHP som Clarence säger är knappast ett template-språk, men det kan göras som en motor till ett template-språk, twig, blade, smarty mfl...

Hej,

Kan hålla med om en del saker Clarence skriver men det mesta låter tyvärr som slarv.

Hur PHP-kod ser ut (lång/kort) spelar ingen roll för mig så länge allt är tydligt och fint strukturerat.

När det gäller escape queries och säkerhet så är det de första man implementerar om man arbetar med ett projekt som läser/skriver från en databas. Om man har en anställd, eller om man själv gör en "test-koppling" för att "fixa den senare" så har man inte planerat speciellt bra.

Jag har inte heller något problem med större webbplatser då det finns PHP dokumentation och möjligheten att programmera i objekt-stil vilket gör att jag kan återanvända min kod, hur enkelt som helst. Programmerar ungefär som Java när jag programmerar PHP, men med egna klasser (då jag vill ha total kontroll över all kod).

Front-end utvecklare hade jag inte anställt om de inte kan något annat förutom HTML/CSS/JavaScript. Jag förväntar mig att någon som är intresserad av webbutveckling, även har baskunskaperna inom HTML/CSS/PHP/JavaScript (gärna kunskaper inom Photoshop eller liknande program också).

Men det mesta går att göra med PHP. Det viktigaste är att planera.

Har du en massa fel och säkerhetsrisker på din webbplats så är det dålig planering.

Men jag förstår varför Clarence advocerar för "template motor".

Alla har sitt eget sätt att göra saker på och jag klagar inte. Antingen lyckas ni bättre än mig, eller så blir det tvärtom. Jag anser i alla fall att man bör ha bra kunskaper inom de flesta områden om man jobbar med webbutveckling. Det går självklart att outsourca allt, men du tappar man kontrollen över sitt egna projekt.

Men jag byggde min första hemsida när jag var 9-10 år. Det var i Dreamweaver (som jag aldrig använt igen efter första hemsidan, då den lägger till onödig kod). Så jag kanske har haft ett kontrollbehov av att göra allt "mitt eget" från barndomen. Vem vet. Det fungerar iaf för mig.

Ett par kommentarer;

Slarv finns alltid. Alla slarvar. Programmerare är människor.

Angående säkerheten hade jag två punkter. Ingen gällde "queries". Det var istället data som du skriver ut som kan komma från olika håll. Enda vettiga stället att formatera data för output är där du skriver ut den. Har du inget lager framför din output är den en säkerhetsrisk. Om man kan få security by default är det mycket mycket värt. XSS-sårbarheter är extremt! vanligt just för att man i de flesta system måste säkra detta manuellt.

Kontexten för frontendare blir fortfarande inte rätt oavsett om du väljer att anställa någon som kan PHP istället för den som är bäst på det den faktiskt ska/borde jobba med. Template-orienterad kod underlättar och snabbar på flödet och förbättrar resultatet.

Jag förstår mycket väl din vilja att göra allt själv. Jag har också haft det och har det fortfarande till viss grad. Men denna argumentation handlar väl egentligen inte om det. Det handlar väl mer om huruvida en template-motor har tillräckligt med fördelar över php-templates för att använda en ... oavsett om du sedan väljer att skriva den själv.

Twig + Symfony 2 + FOSRestBundle all the way när det gäller all typ av templating och utveckling.

Att sitta med rå php 2014 känns väldigt 2004... Jag känner också igen mig i Clarence tidslinje, det var en tid där man förespråkade "ren" php och tyckte ramverk och template motorer var onödigt och överflödigt.

När man sen får lite mer erfarenhet och tar steget att lära sig ett fully stacked ramverk så undrar man bara hur mycket tid man kunde ha sparat, hur mycket mer pengar man kunde ha tjänat och hur mycket huvudvärk man kunde ha sluppit om man bara tagit det steget tidigare.

Tiden som man satt med ren PHP ser jag på som sin novisträning, lite som om du börjar på en av världens bästa sushiställens så får du klämma svinheta handdukar åt gästerna i 3 år innan de låter dig röra fisken(Jiro sushi ^^).

Haha velat skriva detta inlägget i ett par dagar, men inte kunnat formulera mig. Klockrent!

+1 på det där. Så sant.

När man gör sitt eget ramverk lär man sig också väldigt mycket och inser varför MVC är awesome.




Ont:

Blade, pga Laravel.

Alla template motorer verkar vara väldigt lika varandra? Typ bara syntax som skiljer dem åt?
Skulle vara bättre om en template motor slog igenom och blev dominant inom PHP och Javascript.

Jag har ett eget mindre bloatat PHP-ramverk också som jag använder i en del egna projekt. Däremot skulle jag aldrig använda det i mitt dagliga jobb. I större verksamheter lämpar det sig inte helt enkelt utan där vill man köra välkända ramverk som de flesta utvecklare har koll på. Alla vettiga ramverk tillåter ju dock att man implementerar den template-motor man önskar, liksom mitt eget :) Template-motorer är så pass simpla syntaxmässigt att det inte spelar någon större roll vad gäller inlärning men det finns ändå de som är bättre än andra. Bra struktur för arv och så lite krångel som möjligt för plugins och variabler är exempelvis önskvärda funktioner.

Nu går jag lite off-topic som vissa andra här angående deras ramverk.

Jag kör även också ett eget litet ramverk jag byggt upp från grunden.

Främst för att jag tyckt det vart roligare att det kändes lite mer eget. Men det är ju min egna åsikt. Tycker att utvecklingen som jag gör ska vara rolig bland annat och en liten utmaning för mig själv.

Dock skulle jag inte släppa det som ett ramverk likt Symphony eller Laravel.

Det fungerar utmärkt för mitt syfte, men skulle någon vilja bygga upp något snabbt och så skulle jag i stället rekommendera t.ex. Laravel.

Har aldrig sett syftet med att baka in logik i en view fil. Att använda en template engine som escapear output ser jag som ett stort plus som ni tidigare nämnt. Även om man är van och tror att man har koll på allt så är det så lätt hänt att man på ett litet ställe (utan att tänka sig för) är sårbart för eventuella XSS attacker.

Dock vill jag nämna att av erfarenhet från tidigare arbetsplatser så säger de att deras kod vart objektorienterat bara för att de använt sig av ett ramverk.

och pratade man om arv, dependency injection eller simpla design patterns för att lösa problem så stod de som frågetecken och hade inte ens hörttalas om det tidigare.

Vad jag försöker säga är att när man väl använder sig av ett ramverk så kan det vara fördelaktigt att i alla fall sätta sig in i hur koden bakom fungerar på ett ungefär än att bara slänga in det och tro att man hänger med i utvecklingen.

Har följt denna tråd med stort intresse. Länge tittat på "Twig + Symfony 2" eller i alla fall Symfony2.

En liten fråga för er som utvecklar med Symfony2 - kör ni egna servrar/vps eller vanliga webbhotell? Finns det några problem idag att köra på ett vanligt svenskt webbhotell?