Domaci Smarty-Lite za PHP5 !

[ivanhoe]

hm, malkice me ovo podsetilo na Template Toolkit za perl , jel to slucajnost ?

Uzgred, nisi pomenuo vrlo bitnu stvar, jesu li templejti kompajlirani kao smarty ili se evaluiraju svaki put ?

[Berislav Lopac]

Smarty, kao i svi drugi templejting sustavi koji koriste neku svoju sintaksu su totalno bez imalo smisla u PHP-u. Evo zašto: http://www.massassi.com/php/articles/template_engines/

[zira]

Slazem se sa Berislavom, po cijenu da me Smarty zaljubljenici razapnu. Jasne su mi prednosti koje takav sistem daje dizajnerima, ali mislim da je sve to moguce sasvim lijepo uraditi u PHPu samom. Osim u nekim slucajevima, kada se ne smije izvrsavati PHP u templejtu (visekorisnicki CMS npr)

[Peca]

ja koristim EasyTemplate - http://www.onlinetools.org/tools/easytemplate/
Vrlo jednostavan, mali, i brz.
Naravno, nije ni blizu Smarty-ju, ali sve moje potrebe zadovoljava... i sve projekte baziram na njemu.

[_blob_]

hm, zaista nisam nikada cuo za Template Toolkit... provericu i to da vidim ima li tu nekih dobrih ideja...

sto se tice kompajliranja templejta i kesiranja to nisam ubacio ali planiram...
zato sam i pokrenuo ovo da sa nekim podelim teret razvoja i novih ideja...

e sad sto se tice teze da su templejti sa svojom sintaksom: "...totalno bez imalo smisla u PHP-u.." to je vrlo jednostrano glediste na celu stvar (bez uvrede)

znam za clanak o besmislenosti templejtinga za PHP ali ne uzimam ga zdravo za gotovo...
Moj stav je da je taj clanak vrlo ozbiljan u svojim tvrdnjama ali nije univerzalno tacan.

U nekim slucajevima je besmisleno uvoditi template engine u PHP koji je sam po sebi template engine u neku ruku...
(ovo vazi za prostije aplikacije, ili one kod kojih izgled nije previste bitan ni kompleksan. takodje ovo vazi za aplikacije kojima se nece kasnije menjati dizajn itd itd.)

ali ako imate ozbiljniju aplikaciju, koja treba lepo da izgleda, i ima puno razlicitih strana, i pritom dizajneri rade HTML a programeri koriste njihov HTML da bi sklapali aplikaciju...
E tu cela prica o pogresnosti templatinga apsolutno pada u vodu...

recimo ako PHP programer pravi sajt sa 2 HTML dizajnera...
on im objasni kako templating funkcionise i oni naprave izgled celog sajta, svih strana, u cistom HTML-u.
programer ucita HTML templejte u HTML editor, SAMO doda tagove i komentare u HTML da bi povezao logiku prikaza sa PHP skriptom, pritom ne menjajuci HTML.
i sve to sklopi i sve radi...
kasnije ako treba izmeniti izgled svega, dizajneri otvore te HTML templejte u HTML editoru i ne menjajuci skrivene tagove samo izmene izgled i to je to...

u praksi to funkcionise savrseno i nema po meni boljeg nacina...

sustina je u sledecem: templating pristup omogucava da HTML templejt (otvoren u HTML editoru) izgleda BAS onako kako ce izgledati i strana.

a ovi PHP templejti ne izgledaju isto kada se otvore u Dreamweaweru i kada ih konacno prikazete.
A to je blago receno uzas.

ja sam cak kada sam poceo razvijati ovu klasu odlucio da NECE BITI NIKAKVE LOGIKE u samom html-u ali sam posle uvideo da to jednostavno nije efikasan pristup.

primer:

u MySql bazi imate spisak licenci za neki softver, pritom su neke aktivne a neke 'neaktivne'.

zahtevi:
- prikazati sve licence na jednoj HTML strani, pritom na desnoj strani svake licence su opcije za status licence. Kod aktivnih je moguce kliknuti link 'DEAKTIVIRAJ' (link za aktivaciju je samo obican tekst) a one licence koje su neaktivne imaju link AKTIVIRAJ (dok je link deaktiviraj u stvari sam tekst koji se ne moze 'kliknuti')

e sad ako nema mogucnosti ubacivanje logike u templejt, onda je to pakao...
ako ima, proces je lagan:
ucitam sql upitom sve licence, i ispisem ih pomocu moje klase i jednog HTML templejta, a u templejtu imam logiku:

<!-- if ( $active is true ) -->
   <a href="deaktiviraj.php">DEAKTIVIRAJ</a>
<!-- else -->
  DEAKTIVIRAJ
<!-- endif -->

a odmah iza toga:

<!-- if ( $active is false ) -->
   <a href="aktiviraj.php">AKTIVIRAJ</a>
<!-- else -->
  AKTIVIRAJ
<!-- endif -->

e sad prednosti ovoga su sto je lako postici zeljeni rezultat, a pritom HTML templejt u editoru izgleda bas onako kako ce izgledati i sama stranica kada se prikaze u browseru.

a to je nemoguce postici sa pristupom da PHP sam radi templejting.
takav html templejt kada otvoris u editoru NE IZGLEDA isto kao kada ga prikazes na stranici...

ima tu jos problema ali jedno je sigurno:
Templejting ima smisla. NE UVEK! ali ima smisla.
suprotan pristup ignorise praksu.

e sad ako neko misli da gresim, dajte konkretne primere pa mi otvorite oci, bice mi drago da naucim nesto novo...

pritom vas molim da ovo ne bude novi flame-war...
samo konstuktivno...

pozdravlja vas
UncleBlob

[Ilija Studen]

Slažem se da templatei imaju smisla u izvesnim situacijama, ali te situacije su stvarno retke i uglavnom se svode na slučajeve kada želiš da ograničiš kontrolu krajnjim korisnicima (templatei koji se edituju iz administracionog panela i tome slično). Primer za takav pristup su templatei unutar Textpatterna.

Tvrdnja da stranica izgleda istovetno kada se gleda njen template i kada se parsira i popuni podacima pije vodu SAMO u retkim slučajevima kada se radi prost output i kada nema puno logike na stranici. Na primer, tvoj kod sa Aktiviraj linkom će outputovati jedan link i jedan prost tekst kada ga otvoriš u Dreamweaveru (ili drugom alatu po izboru) ili ti poduplaće sadržaj

Ne znam za tvoja iskustva, ali templatei sa kojima radim su uglavnom puni prezentacione logike i jednostavno ih je nemoguće uređivati u nekom vizuelnom alatu. Čak i ako se odlučiš da koristiš naprednije mogućnosti template enginea (blokovi, modifikatori, funkcije itd) to Dreameweaver neće umeti da prikaže i na mestu recimo User profile bloka će stajati prazan prostor.

Znači, cela priča o tome da se templatei isto vide u vizuelnom alatu kao što stranica treba da izgleda pada u vodu u 95% slučajeva.

Dalje, kolaboracija između dizajnera i developera je overrated argument pošto jer je nivo kompleksnosti prostih PHP fajlova (ako su uljudno formatirani) tek nešto veći od kompleksnosti template engine sintakse. Primer da dizajneri nisu glupe ovce i da se znaju snaći i sa PHP templateima su ti WordPress teme. Ima ih tone i sve su PHP fajlovi. Dalje, nije redak slučaj da dizajner sredi markup i CSS pa da ga programer onda ušnira u kod ili taj posao odrade zajedno. Npr, u zadnjih par projekata gde sam imao dizajnera dobijao sam gotov HTML ili čak samo PSD (na sopstveni zahtev). Dalje je sve bilo na meni...

Uh, mnogo teksta. Uglavnom, template enginei imaju smisla u relativno retkim situacijama. Fleksibilnost koju ti daje PHP je ogromna, ne kravi se editor (jeah, radi code completion i code proposal, editorovi templatei itd), znatno je brže i jednostavnije od template enginea i ako se fino povuče granica između aplikacije i template (rešio problem sa ~50 linija primitivnog koda) nema zime.

Btw, takođe razumem da neki iz navike koriste template engine čak i tamo gde im ne treba. Blagi pad performansi i uvećanje kompleksnosti često nije opravdanje da se odrekneš nečega sa čim se osećaš komforno i kao kod kuće.

[bluesman]

O čemu vi sada pričate? Da li pričate o klasi koju je ovaj čovek napravio i tražio feedback ili ćete opet da krenete u neki advocacy "templates (ne)maju smisla"?

Interesantno je da su najveći protivnici templates oni koji ih nisu nikada ozbiljno koristili, ako su ih uopšte i probali ili su samo pročitali neki tekst negde, pa se "slažu" odnosno veruju na reč.

Dakle, ja predlažem da ovde pričamo o ovome što je čovek započeo, a ako ćete da iznosite svoje optužbe pred porotu - milim vas, počnite novu temu.

[zira]

Ajde Gorane, malo flejma nije zgoreg, bilo je u vezi teme

Blobe, koliko vidim iz koda, ne podrzava include jednog templejta u drugi templejt? I nema kompajliranja?

[Peca]

Meni samo nije jasno zasto bi template trebao da ima logiku?

Primer sa AKTIVIRAJ/DEAKTIVIRAJ bi mogao da se resi bez logike u template-u, i to na dva nacina:

<a href="%%link%%">%%natpis%%</a>

pa u PHP-u odredis vrednost 'link' i 'natpis' promenljivi.

ili

<--- start:aktiviraj --->
<a href="aktiviraj.php">Aktiviraj</a>
<--- end:aktiviraj --->
<--- start:deaktiviraj --->
<a href="deaktiviraj.php">Deaktiviraj</a>
<--- end:deaktiviraj --->

Ovaj drugi primer je isti kao onaj gde imas logiku, isto imas dva bloka, dakle u HTML editoru ce isto izgledati.
Samo sto si logiku prebacio u PHP skriptu, gde joj je, po meni, i mesto.
Osnovni cilj template-eva je da odvoji dizajn od PHP-a, i to je i postignuto. Logika u template-u nije uopste prvobitna ideja template-a, kada su prvi template-evi napravljeni.

Logika je posao za programere. Samo bespotrebno usporavate template engine stavljanjem logike u template.

[Ilija Studen]

Sorry za offtopic, ovo je sad više edukativnog karaktera

Razgraniči logiku aplikacije i prezentacionu logiku. Nema nikakvog smisla mešati kod koji određuje da li je red tabele paran ili ne sa kodom aplikacije. Npr, kako ti napraviš da ti se izlistaju redovi izvučeni iz baze unutar jedne tabele gde su svi parni redovi plavkasti, a svi neparni bledo sivi?

Treba ti loop + mogućnost da odredišt parnost trenutne iteracije i na osnovu toga odrediš koju ćeš boju koristiti. Nemoj mi reći da to mešaš sa aplikacijom?