Monte Ohrt - is PHP template language?
 

Upravo sam dobio jedan mail od Monte Ohrt, čoveka koji je napravio Smarty, gde komentariše "večitu dilemu" da li je PHP template language. Pročitajte šta kaže, ja mogu samo da se složim:

paaa, i jeste i nije... smarty i php (sa skracenom sintaxom) se zapravo jako malo razlikuju, da li pises {foreach ...} ili <? foreach(...): ?> ili recimo {$bla} ili <?=$bla?>. U par navrata sam pretvarao php u smarty templejte, i to moze relativno brzo i lako da se uradi, cak sa obicnim search and replace se zameni veliki deo koda...

Hocu da kazem nije to bas tako drasticna razlika, mada smarty sintaxa je svakako citljivija od "izvorne". Monte je u sustini je pretvorio php u kvazi basic (izbacio zagrade, dodao tacku umesto []) i ima dosta unapred gotovih f-ja koje su zgodne, ali ne bih bas nazvao to chainsaw vs. bread knife... ja koristim smarty godinama vec, ali nije bas da sam hteo da se ubijem kad sam morao da radim direktno u php-u, recimo za Wordpress teme kad radim..

Mislim da nisi shvatio taj deo chainsaw vs bread knife koji se odnosi na to da je PHP (postao) daleko više od template language. To je odgovor onima koji tvrde da je PHP običan template lang i ništa više od toga. Ako je "bread knifre" jedan pravi template language kao što je Smarty, koji i ne pretenduje na više od toga (šta više, u smarty3 su po defaultu izbacili {php} tag) - PHP je chainsaw u odnosu na to.

ok, ako je to pisac hteo da kaze, onda se slazem :)

Ja sam od Smarty presao na PHP kao templejt jezik. Elem, blues, deder mi reci sta radis kad ti zatreba bilo kakvo racunanje u okviru templejta (posto je {php} tag izbacen) ?

Na primer kakvo računanje? a + b * c? To sve možeš u smarty da uradiš. Ili treći koren iz cosinus arkus tanhgensa ? :)

mada smarty sintaxa je svakako citljivija od "izvorne"

Meni nije. :D Ne znam kako je ljudima koji samo znaju html/css. Ne verujem ni da njima olaksava posao.

Vec 6-7 godina radim sa smarty-ijem (ako me pamcenje dobro sluzi) i svim html/css implementatorima sa kojima sam radio (a bilo ih je dosta) je bilo lakse da zapamte smarty sintaxu nego php. A cak i kad sam ja pravio templejtove a oni samo ubacivali html/css, daleko manje gresaka su pravili kad rade sa smarty templejtovima nego sa PHP
Ovo je moje licno iskustvo, i ne kazem da je sa svakim tako

Btw smarty ne treba da radi nikakvu app logiku tj. logiku koja nije vezana za templatove, pa cenim da to racunanje u smarty-u i nema previse smisla (iako je moguce stosta). :)

taj dasa definivno ima kliker. sa recimo mozes iz text base izvuci sve kao recimo iz twitter timelinea.

to ti bas nije sjajna ideja, mozes sa truncate lako da preseces html link na pola i da dobijes nevalidan html....

Cini mi se da je cijela rasprava krivo postavljena (ne ova na devprotalk nego opcenito 'php - template jezik ili ne'). Jer, i c++ moze bit template jezik. Poanta je, kako mi se cini, u tome kako se shvaca svrha koristenja PHPa (ili bilo kojeg drugog jezika). Ako je svrha npr. aplikacija koja ima svoj skup funkcija, a rezultati kojih se u nekakvom prikazu posalju korisniku onda ne znam o kakvom template jeziku mozemo govorit?
Ako se pak server side logika koristi da bi se radila fadeIn-Out skripta slika na klijentu (vidio sam taj slucaj u praksi :D ) onda mozemo o PHPu govorit i kao client-side skriptnom jeziku.

U tom svjetlu, ostaje vidjet zasto PHP postoji i za sto je sve sposoban. Praksa nas uci da se, kao i svaki jezik, moze koristit i za manipulacije HTMLom. Medjutim, isto tako nas praksa uci da je svodjenje PHPa na to prije izraz nepoznavanja njegovih mogucnosti nego stvarni opis njegove svrhe.

Batalio sam Smarty pre nekoliko godina u korist PHP-a kao jezika za pisanje šablona, odnosno za pisanje skripta pogleda (engl. view script). Osnovna namera bila mi je da očistim kontroler (u MVC) od svog suvišnog koda. Kontroler upravlja prijemom zahteva i definiše različite callbackove koji spuste pozive u model aplikacije.

U kodu pogleda sada mogu da definišem sav PHP kod za lepljenje na callback-ove kontrolera i da slobodno koristim PHP za upravljanje izlazom i podacima iz kontrolera (bilo da odgovor na zahtev pravi HTML, CSS ili PDF). Ovim imam bolju razdvojenost slojeva aplikacije ali gubim mogućnost da "dizajner menja šablon". Ne znam da li iko pušta dizajnere da menjaju šablon, pitanje da li i HTML valjan umeju da pišu. Veb dizajner u timu pak razumeće i to malo PHP koda. Ako prihvatimo rad sa komponentama (za RIA) onda se slaganje forme prikaza obavlja u PHP kodu, a ovim to lepo stoji u skripti pogleda, gde i treba.

Smarty mi se u jednom trenutku učinio nepotreban bloat i ograničenje. Ipak i dalje bih preporučio programerima da ga koriste kada im odgovara. Ako govorimo isključivo o veb stranama, sintaksa šablona je lepša u Smarty-ju nego kada se piše u PHP-u. Ja bih se ipak odlučio za eksterni pretprocesor, ali ne znam kako bi se u nekim timovima drugi sa tim uklopili. Smarty ima dokumentovanu sintaksu, široko je poznat, i to je značajna prednost.


Nasleđivanje šablona je odličan pristup koji već neko vreme koristim. Okačio sam izvučen mali kodić iz veće biblioteke kao primer kako se to može ubaciti bez Smartyja.

Osobine:
1) Pogled se izvršava u imenskom prostoru metode render klase fw_ViewRenderer
2) Promenljive prenete kao niz se ubacuju u imenski prostor i tako su dostupne iz šablona. Iz pogleda moguće je pristupiti renderer objektu preko $this
4) Renderer dozvoljava šablonu da odredi šablon koji će da nasledi i definiše blokove koje se prenose nasleđenom šablonu. Blokovi se koriste kao izmenjivi delovi roditeljskog šablona, a mogu biti definisani sa begin..end ili mogu biti učitani preko spoljnog šablona (kao što smo radili sa include)
5) Pri izvršavanju pogleda izvršava se prvo šablon-dete, a potom rekurzivno svi roditeljski šabloni kojima se sada blokovi prenose uz šablonske promenljive (omogućeno prepisivanje)
6) Postoji pretprocesor koji ulepšava i validira sintaksu šablona, ali nije neophodan (ovde je čist PHP kod)
7) Preko male touple-like klase pogled može da definiše i skup HTTP zaglavlja. Pogled nije ograničen na HTML, mada sa nasleđivanjem u binarnim šablonima treba paziti sa proredima oko begin..end.

Pogledajte na: http://gitorious.org/grakic-sandbox/...r/trees/master

tmpl/_base.html je apstraktni šablon koji ima prazan blok central_page. U realnom primeru imali bismo header, footer, left_column,... Osnovna razlika u odnosu na include je da base šablon ne povlači ove delove, on samo definiše njihov raspored i okolni statički HTML kod. Tek šablon koji nasledi base će da odredi sadržaj ovih blokova.

Samo nasleđivanje u kontroleru uopšte ne vidimo, tamo se poziva tmpl/index.html a kako on dalje radi nas ne zanima. Index šablon će definisati sadržaj central_page bloka, a mogli smo i da na tom mestu povučemo include (preko set_block(filename, vars); ).

Ja licno ne volim ovakav pristup. Nazigled je super kad se sve radi negde u pozadini, automatski i "nevidljivo", ali onda kad ti u ruke upadne takav projekat koji je neko drugi pisao, pa treba da pohvatas sta, gde, zasto, ko koga poziva, gde se sta nasledjuje... thanx, but no thanx

Ne znam šta je nevidljivo, sve piše u kodu.

Misliš li na nasleđivanje šablona? Meni je to toliko superiorno u odnosu na include da se nikada nazad ne bih vratio. Nasleđivanje ti omogućava da prirodno razmišljaš o šablonima, imaš stranicu za baštenske proizvode koja je kao proizvodi samo ima "..." što nije isto kao i stranica za baštenske proizvode se sastoji od zaglavlja, menija, leve kolone, podnožja, i ovoga između.

Jedino što sam naglasio kao "nevidljivo" jeste što u oba slučaja (bilo nasleđivanje, bilo include) ti imaš isti kod u kontroleru koji traži taj i taj šablon, a definicija kako on izgleda je u samom šablonu. To je standardan princip enkapsulacije, ne mislim da protiv toga imaš nešto protiv.

ne mislim nuzno na tvoj kod, jer ga nisam bas pazljivo pogledao, nego generalno, na previse iskomplikovanu arhitekturu.. jedan od osnovnih prednosti MVC po meni je sto bi trebalo da je lakse naci kako da promenis peti link sa leva, bez da provedes 2 nedelje kopajuci po kodu..

nisam puno radio sa nasledjivanjem templejta, ali ono sto jesam (jedan veliki sajt pisan u kohani) bilo mi je jako konfuzno dok nisam naucio gde je sta, za sta su mi trebale nedelje... opet, mozda je to do tog koda, a ne do koncepta, kad budem malo vise radio sa tim (kad izadje novi Smarty recimo), mozda promenim misljenje

Pa kad pišeš kod, gledaš da tebi bude što zgodnije, a ne nekom drugom, zar ne? :) BTW, pretpostavljam da bi ti trebalo mnogo manje vremena da je taj prethodnik ostavio neku kratku dokumentaciju ili odvojio dan-dva da ti objasni arhitekturu...

Meni se template inheritance čini sasvim ok, logičan i ekonomičan koncept. Ali cenim da si u pravu da je debagiranje otežano, jer nikad nisi na prvi pogled siguran iz kog tačno fajla dolazi HTML koji vidiš na stranici, pa moraš da se "penješ" kroz hijerarhiju dok ga ne nađeš.

Na kraju krajeva, sve je mnogo bolje od kopi-pejsta.

Pomagao mi je on, nije to problem, nego upravo ovo sto navodis, tesko je naci deo koda koji ti treba jer moras da trazis po stablu nasledjivanja gde se generise taj komad. Covek je suvise fakultetski iseckao arhitekturu, sa milion klasa koje nasledjuju jedna drugu i dodaju po jednu-dve metode svaka, i onda kontroler ima 10-tak "predaka" u hijerahiji, templejti isto tako, masa stvari se radi "automatski", tako da kad pogledas krajnji fajl nemas pojma odakle se neki komad koda stvorio, i zasto tako radi. I sto je najgore on je imao i logiku automatskog nasledjivanja templejta po imenu i folderima, sto na prvi pogled deluje jako elegantno, ali onda iz konkretnog templejta koji si otvorio ne mozes nikako da vidis odakle on nasledjuje sadrzaj, nego moras da znas logiku po kojoj se templejti ulancavaju. Ova varijanta gde to explicitno pise u templejtu je svakako bolja.

Nebitno, verovatno se samo radi o mind-setupu, meni je logicnije da templejte posmatram kao stranu koja dalje ima boxove u sebi, nego obrnuto kao box koji ima wrappere oko sebe. Pretpostavljam da je to samo stvar navike.