Domaci Smarty-Lite za PHP5 !

[_blob_]

Pozdrav svima,
evo tek sam otkrio vas forum pa da se ukljucim...

vec jedno vreme razvijam i koristim klasu za Templejting pa me interesuje vase misljenje. To je tip klase koja treba svakom PHP programeru.
Pitanje je samo kakve covek zahteve pred kod postavlja...

evo sta moja klasa trenutno moze:

(requirements: >= php 5.0)

features:

- vise Reporta u jednom template file-u, kao i slanje dodatnih parametara Report-u

  <!-- report name="radnik" params(break="id" a="1" b="2") begin -->
   ...html...
  <!-- report name="radnik" end -->

- Banded Reports: (Header, Detail, Detail_Empty, Footer...)
- prosledjivanje vrednosti tokena u klasu funkcijom assign() koja podrzava i nizove (koji se onda ispisuju u Detail bandu)
(Ponavljanje redova ako postoje vise stavki za isti podatak pomocu Detail i Detail_Empty band-ova)
- IF THEN ELSE uslovi, u kojima se mogu koristiti promenjive koje prosledite template-u
(podrzane operacije: ==, ===, !=, is true, is false, is odd, is even itd itd)

<!-- detail begin -->
<!-- if ( $id is odd ) -->
   <font color="#ff0000">
<!-- else -->
  <font color="#0000ff">
<!-- endif -->
    (%id%) :: Rbr: (%nr%)  Vreme Ulaska: (%datum%) Kolicina: (%kol%) <br>
</font>
<!-- detail end -->

- podrzani su filteri ze tokene: (kao u Smarty-ju)
Code:
(%imetokena:raw%) (%imetokena:upper%) (%imetokena:lower%) (%imetokena:ucwords%)
ili recimo nohtmlentities() za vrednost tokena: (%imetokena:nohtml%)

- Klasa sama racuna zbirove i proseke za polja koje korisnik odredi i te vrednosti se mogu ispisivati, u Detail i u Footer Bandovima:

  (%count.id%) 
  (%sum.kol%)
  (%avg.kol%)

klasa podrzava i jos mnogo toga, proverite sami ako vas zanima...
mogla bi se lako prevesti u PHP4 ali to ostavljam nekome drugome.
u zip arhivi imate klasu, kao i primer upotrebe sa jedim templejt fajlom.

p.s.
od nove godine krecem sa Open Source razvojem ove klase, razbicemo smarty
ako imate predlog za ime klase, javite!!!
razmisljam o Intuition Template Engine ili nesto tako...

ajde da cujem neka misljenja (pozitivna ili negativna) samo da pomera...

sretni praznici!
pozdravlja vas UncleBlob

[Ilija Studen]

Koje su prednosti? Konkretno u odnosu na Smarty, a onda i u odnosu na klasične PHP fajlove omotane template klasom?

Btw, ne bih se zanosio sa "razbijanjem" - Smarty postoji jako dugo, veliki broj developera ga koristi aktivno, a još veći ga je ili ranije koristio ili tačno zna o čemu se radi. Dokumentacija je dosutpna i razrađena itd itd itd. Da ne smaram sa detaljima. Malo sam skeptičan

[_blob_]

hm, prvo pozdrav i hvala na feedback-u!

sto se tice prednosti moje klase ima ih puno:

0. lightweight! klasa je jedan fajl <=20k koda (a Smarti je ipak puno 'tezi')
1. intuitivno i krajnje prosto za koristiti
2. ima sve sto vecina ljudi koristi kod Smarty-ja...
3. (nema sve ono sto smarti ima ali ionako niko ne koristi)
4. podrzava ono sto Smarty nema: banded reports pristup (nije obavezno ali podrzava) pogledaj primer uz klasu za demonstraciju tog pristupa...
ako je neko koristio QuickReport, ReportBuilder ili CrystalReports zna o cemu
pricam, vrlo bitno za sve 'poslovne' aplikacije tj. za izvestaje...
Smarty ima ovo ali je totalni hack, komplikovano za podesiti a jos i ne radi..
5. klasa se jos uvek razvija i mozemo je srediti tako da ispravi sve mane koje drugi template sistemi imaju
6. lako je moguce je reci klasi da na kraju obrise sve neparsove templejte (ovo ima i Smarty ali je komplikovano za postici)
6. nasa je (i nije svetska)

itd itd...
da sad ne smaram previse... a i subjektivan sam....

moja ideja je da cimnem ljude odavde i da zajedno poguramo projekat i napravimo templating engine vredan hvale...

ali ne mogu sam...

ako je neko zainteresovan neka se javi...

do tada skinite primer i klasu i probajte i pitajte sta vas zanima...
ako neko ima feature request samo recite...

..

a ono o razbijanju Smarty-ja je bila cista shala... to mi uopste nije namera... hocu da napravimo nesto sto je mocno kao Smarty a opet je mnogo prostije i lakse za upotrebu...

ok, ajd da vas cujem sad...
poz
Uncle Blob

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

[_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.

[zira]

Originalno napisao _blob_

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

Rekoh vec, templejt engine ima smisla u odredjenim situacijama. Ali gornji navod ne pije vodu. Izgled web aplikacije generalno ne zavisi od toga da li ima templejt, a pogotovo ne od toga koji templejt engine.
Moja osnovna zamjerka ostaje da mi se ne dopada, u opstem slucaju, izmisljanje novog jezika za templejt, kada vec postoji PHP. Naciti PHP u mjeri koja je potrebna u templejtu nije nista slozenije od ucenja templejt sintakse, a ima univerzalniju vrijednost.
Druga zamjerka je brzina, pogotovo u "ozbiljnijim" aplikacijama. Stoga, nisam za upotrebu ne-PHP templejta, ukoliko zaista nije potrebno. Time stedis sat vremena dizajneru, a potom na milione puta procesiras te templejtove i dodajes cesto nepotrebnu slozenost.
Naravno, ovo je moj licni stav, mozda ja nisam mjerodavan, posto od alata uglavnom koristim samo tekst editor