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)

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

[zira]

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

[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 :D

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?

[ivanhoe]

^^ word
prezentaciona logika treba da ide u templejt (odnosno view kontroler koji template engine predstavlja)

Ima jos nesto, a to je da je mnogo zgodnije drzati sve delice dizajna strane u jednom fajlu, pa ako je korisnik ulogovan onda mu ne prikazujes login box i slicno... tako je lakse dizajneru da radi, ima jedan html fajl i moze da vidi kako se sta uklapa sa cim...

Sto se tice _blob_ ove klase, po meni je kompajliranje apsolutni preduslov da bi cela stvar bila prakticno upotrebljiva. Uostalom gubi smisao onog Lite u nazivu, ako je samo izvrsavanje sporo i memorijski zahtevno. Tako da ti preporucujem to kao prvi sledeci korak u razvoju..

[Peca]

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

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?
Napravis dva bloka, jedan plavkast, drugi bledo siv, i uz pomoc _samo_ jednog IF-a u PHP skripti odredjujes koji ces blok da insertujes. Ionako ces imati dva bloka, i u slucaju logike u template-u.
Smatram da je bolje zrtvovati jednu liniju u PHP umesto da se koristi template engine-a koji ce da obori perfomanse skripti. To je sve sto pokusavam da kazem.

[Ilija Studen]

Samo recimo da template engine NE BI TREBALO da obara performanse celog sistema, a ti ne bi smeo da praljaš logiku aplikacije. Jednostavno to što preporučuješ drugima nema previše smisla po meni i loš je savet.

Primer sa PHP templateima. Kontroler (logika za obradu korisničkog zahteva po MVC patternu):

class MyController extends PageController {
function list_stories() {
$this->assignToView('stories', Stories::find());
}
}

View:

<h2>Stories:</h2>
<table>
<?php foreach($stories as $story) { ?>
<tr class="<?php echo cycle('odd', 'even') ?>">
<td>#<?php echo $story->getId() ?></td>
<td><?php echo htmlspecialchars($story->getTitle()) ?></td>
</tr>
<?php } ?>
</table>

Da ne zalazim u detalje, nadam se da je ovaj kod logičan. I primeti jednu stvar, čak i vBulletin podršava i pravilno naglašava sintaksu templatea. Zamisli tek šta sve imaš na raspolaganju u specijalizovan PHP IDE-u kao što je Zend Studio na primer :p

Btw, koristim "<?=" umesto "<?php echo". Kad treba da objavim kod jednostavno pokrenem jednu build skripticu koja se postara o svim pratećim detaljima ;)

[_blob_]

Kao prvo: Ljudi Sretna Vam Nova Godina!

e sad, drago mi je da se ovde zakuvalo na topiku... to je i bio jedan od ciljeva...
ima tu jos nedorecenih argumenata...

vidim da ljudi pricaju o stvarima o kojima znaju, i svako ima svoje argumente.

dosta se tu polazi i od licnih preferencija... ima to veze i sa mazohizmom :)
meni je mucenje kada imam PHP kod u HTML-u...
uvek mi je to smetalo, od prvog dana rada sa PHP-om...
jednostavno mi se cinilo da to nije ispravno...

ali verujem da nekima od vas to 'lezi'...

da pojasnim:
ja sam prvo sve 'trpao' u php fajl... (verovatno svi tako pocnu...)
pa mi je to smetalo.
pa sam presao na neke bezvezne, kompikovane template engine...
pa mi to nije bilo dovoljno dobro...
pa sam presao na Smarty... to mi se jako svidelo...
ali sam mu ubrzo nasao puno mana... (da ne nabrajam sad, svi ih znamo...)
znam da ga pola PHP svemira koristi, ali mene nervira i tacka...

onda sam krenuo sa svojom klasom, i mislio sam da je super...
(kada sad pogledam taj prvobitni kod, ne znam da li da se smejem ili da placem) :(
sada sam razvio skroz drugacije resenje i opet mislim da je super :)
(do sutra, verovatno...)

kao sto rekoh sve je to subjektivno...
i linija je tanka... nekad je bolje ovo, a nekad ono...

ali niko mi nije odgovorio na ovaj argument za moju klasu:

- BANDED REPORTS - header, footer, detail, detail_empty band-ovi, racunanje suma, proseka, i brojanje redova...
to nema ni jedna meni poznata templating klasa sem ove na kojoj radim....
(ja sam to licno naucio u Delphi-ju sa ReportBuilder komponentom... i uvek mi se to cinilo kao prirodni nacin za ispisivanje izvestaja bilo kog tipa...)

takodje moja klasa podrzava i sledeci slucaj (podvrsta banded report-a):

imam header, detail i footer za neki izvestaj (moze biti bilo sta, recimo spisak potrosnje megabajta korisnika nekog ISP-a)
u headeru je broj i ime korisnika, u detail-u je kolicina potrosnje za pojedinu sesiju, u footeru je zbir za korisnika, a na kraju ide zbir za sve korisnike...

ja prosledim klasi templejt, i spisak korisnika sa potrosnjama iz MySql baze, sortirano po korisnicima, i kazem klasi da je break kolona ID_KORISNIKA.
a u footeru za izvestaj dodam polje (%sum.potrosnja%)
i tu je kraj sto se mog rada tice.
klasa ispisuje sledece:

korisnik br.1: Ime Prezime
dan 1: 100mb
dan 2: 20mb
Ukupno: 120mb

korisnik br.2: Ime Prezime
dan 1: 100mb
dan 2: 30mb
Ukupno: 10mb
...

i tako za svakog korisnika... klasa sama prekida podizvestaj kada se promeni ID_KORISNIKA, ispise footer i zbir potrosnje...

na kraju izvestaja : UKUPNO SVI KORISNICI (%global.sum.potrosnja%)

e sad, nije to nuklearna fizika, znam, ali to nisam na drugim mestima video...
a cesto mi treba u web aplikacijama koje radim za klijente...

a ako ne koristite templating, tu onda ima dosta koda da se doda na svaku stranicu...
a kod mene je sve to 'out-of the box'...

voleo bih da cujem vase misljenje o tome...

..

sto se tice logike aplikacije i prezentacione logike to stvarno nije jedno isto i tu se 100% slazem sa Studen Ilijom.

Jednostavno mora postojati i logika prezentacije, baz zbog tog bojenja parnih i neparnih redova u tabeli (trivijalan primer, ali ako nema mogucnosti da se implementira prezentaciona logika u templejt, onda ta logika mora u logiku aplikacije, a tamo joj nikako nije mesto: BABE I ZABE !!!)

...

e da jos nesto: jedan od osnovnih kriterijuma zasto me nervira Smarty je zato sto previse toga moze da se uradi u templejtu pa onda ljudi tu trpaju i ono sto tu ne treba biti.

hocu da koncipiram svoju klasu tako, da u templejte NE MOGU da se ubace stvari koje tamo ne spadaju, vec samo prezentaciona logika i HTML (eventualno jScript).

tu mi treba pomoc i sugestije...

i molim vas da se okanete price "a, to ti nece valjati, to ne ide..." itd itd.
taj pristup me totalno nervira... ako nemas predlog kako nesto popraviti nemoj ni da kritikujes, to je moj moto.
hajde da vidimo sta ne valja, pa da popravimo...

u svakom slucaju hvala na feedbacku stvarno je korisno...

krecem sa proucavanjem mogucnosti kompajliranja i kesiranja u klasi...
svi predlozi i smernice su dobrodosle... :)

kesiranje znam kako cu, to je lako, ali kompajliranje tu sam vec malo zatecen...
videcemo...

ajd poz,
UncleBlob

[bNasty]

Srecna Nova!

I sorry unapred za skretanje sa teme...
ali, nakon XSLT-a lichno ne vidim potrebu za yet-another-template-engine-om. Ne mislim na ovaj konkretno, vec uopshteno. Mozhda je functional programming preveliki stepenik, i mozhda je XML na loshem glasu kod web developera, ali i nakon najbolje volje da koristim neki od popularnih template engine-a opet sam se vratio xslt-u.

[Peca]

Samo recimo da template engine NE BI TREBALO da obara performanse celog sistema, a ti ne bi smeo da praljaš logiku aplikacije. Jednostavno to što preporučuješ drugima nema previše smisla po meni i loš je savet.
Samo mali offtopic, da ne bih bio pogresno shvacen.
Nikom ja nista ne preporucujem, samo sam govorio kako ja resavam problem bez logike u template-u.
Kada razvijam neki softver, uvek imam na umu da cu delove tog sotvera moci da iskoristim i u buducim projektima. Svoje buduce projekte ne znam, i ne znam hocu li praviti web softver koji treba da se izvrsava po 10-50 puta u sekundi [za sajtove koji imaju po milion hits dnevno]. Zato uvek biram resenje koje ce moci da radi i pod svim uslovima.
Sta cu, oduvek sam voleo optimizovan i brz kod. Navikao sam da uzimam brza resenja, koja pak nisu toliko low-level, vec daju komfornost, a sa druge strane ne uticu bitno na perfomanse. Znaci logika 'uzimaj samo onoliko koliko ti je potrebno'.
Template vidim kao podelu posla izmedju programiranja i dizajna, i to i u praksi tako biva kod mene - dobijem gotov HTML od dizajnera [ponekad mi dizajner sam ubaci template tag-ove, ako sam mu objasnio sta i kako], i ja samo uradim PHP skriptu... a one nikad ne predju ni 20 linija, i uglavnom iskopiram kod iz prethodnih projekta. Ceo sajt odradim za 1 sat.
Dakle, sta sam dobio ovim:
- dizajner je svoj posao odradio rutinski, bez ikakvih konsultacija samnom [uhodani smo, on zna osnove template-a]
- dizajn moze da se menja uvek, ne zavisi od mene programera
- ja svoj deo posla odradim isto rutinski, softver se ne mesa sa dizajnom
- ceo posao je gotov za najkrace moguce vreme.
To je tako u praksi kod mene. Takva je podela posla.
Zasto bih ovde menjao ista, kada sve funkcionise besprekorno?
Ja cak i ne bi zeleo da zamaram dizajnera logikom template-a. Njegov posao je da uradi dizajn. Moj posao je da napravim 'mozak aplikacije', i voleo bih da ta logika bude na jednom mestu - u mojoj skripti.

Sta bi bilo da hocu logiku u template-u?
1) morao bih dizajnera da ucim sta je to, kako radi, kako da napravi [cak i da ja preuzmem posao na sebe da odradim logiku u template-u, desice se da dizajner treba da izmeni dizajn, i onda cu opet morati da objasnjavam sta i kako] [p.s. a sa druge strane - osnova template-a se objasni dizajneru za 5 min :)]
2) imao bi pad perfomanski aplikacije, a ja ne volim to, jer uvek po navici pisem softver koji ce da izdrzi i veliki hits :)

Zasto bih sebi to radio, samo da bi prezentaciona logika [koja se uglavnom svodi na liniju-dve u php kodu] bila u template-u...
Ja kreiram logiku, i sta vise, voleo bih da je sva logika na jednom mestu - u skripti :)
Uostalom, logika pripada programiranju... programiranje je logika. A da je razdvajam - iskreno cu vam reci - ne vidim potrebe. Ja je radim u oba slucaja... pa bih sta vise voleo da sva logika bude na jednom mestu - na mojoj teritoriji odgovornosti - u skripti. A do sada nisam video da nesto ne moze da se napravi upotrebom obicnih blokova i promenljivi, i linijom-dve PHP-a.

I opet cu napomenuti, ovo je samo ono kako ja radim, a objasnio sam i zasto. Jednostavno - takva mi je podela posla. Dizajner dizajnira, i ne radi posao koji je programerske prirode.
Ne savetujem nikoga, samo pricam o mom iskustvu, koje je takvo kakvo je zbog mnogih faktora.

I voleo bih da vidim primenu tih komplikovanijih template klasa na sajtovima gde je veliki hits.

P.S. Izvinjavam se za offtopic. Ako je prevelik - splitujte temu :(

P.P.S. Takodje svima srecna nova godina ;)

[dee]

Ilija, mozes li ovaj primjer izdvojit u poseban topic, da covjeku ne umlacujemo ovdje, i malo ga detaljnije objasnit? sta tu sta i kako radi?

[Ilija Studen]

I voleo bih da vidim primenu tih komplikovanijih template klasa na sajtovima gde je veliki hits.

Koliko znam, Flickr koristi Smarty i to ga koriste baš do daske - skoro sve napredne mogućnosti, ne koriste ga kao prosto insertovanje vrednosti promenljivih u HTML kod. Domaći primer je Romance-Cafe, takođe Smarty. Hit na performanse koji template engine unosi je često neznačajan - manji od greške u logici gde imaš koji query viška ili pak loše rešene indekse na tabelama koje često koristiš.

Pad performansi postoji, ali on je smešan. Par desetina (stotina?) puta je manji nego recimo odluka da ne koristiš opcode cache.

[ivanhoe]

zapravo ako se koristi Smarty cache, onda perfomanse mogu da se solidno poboljsaju za vecinu stranica, jer se sluze prakticno staticne strane (zavisi naravno koliko delova strane je namesteno da se ne keshira..).

[Berislav Lopac]

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

Dušo draga, moje iskustvo je upravo obratno. Osobno sam istražio desetke template enginea, osobno sam napisao dva-tri, dok nisam shvatio da nijedan od njih nema smisla.

Da se razumijemo -- nemoj molim te miješati raspravu o tome trebaju li templatei uopće s raspravom o tome trebaju li templatei imati svoju vlastitu sintaksu ili pak koristiti PHP.

Stvar je vrlo jednostavna:

a) templatei su odlična stvar i treba ih apsolutno koristiti
b) nijedna sintaksa templatea osim samog PHP-a nema smisla

Dalje diskusije više nema. Ionako ćete svi kad-tad doći do istog zaključka.

[_blob_]

Dušo draga, moje iskustvo je upravo obratno. Osobno sam istražio desetke template enginea, osobno sam napisao dva-tri, dok nisam shvatio da nijedan od njih nema smisla.

Da se razumijemo -- nemoj molim te miješati raspravu o tome trebaju li templatei uopće s raspravom o tome trebaju li templatei imati svoju vlastitu sintaksu ili pak koristiti PHP.

Stvar je vrlo jednostavna:

a) templatei su odlična stvar i treba ih apsolutno koristiti
b) nijedna sintaksa templatea osim samog PHP-a nema smisla

Dalje diskusije više nema. Ionako ćete svi kad-tad doći do istog zaključka.
Ok, sve je to lepo,
ali niko mi jos nije odgovorio na to kako bez templejta elegantno resiti
banded reports (sa header, footer i detail bandovima, sumama, prosecima, brojanjem) itd itd..

jedna dobra templating klasa to resava sa par linija koda i prostim templejtom,
a ako se samo koristi html templejt sa php kodom u sebi umesto templating klase onda tu ima dosta da se kodira...

zar nije sustina OOP u encapsulation i code-reusability ?


poz
UncleBlob

[Ilija Studen]

ali niko mi jos nije odgovorio na to kako bez templejta elegantno resiti
banded reports (sa header, footer i detail bandovima, sumama, prosecima, brojanjem) itd itd..

Ne sećam se kada sam imao taj problem, a da ga nije bilo moguće rešiti pomoću par elementarnih funkcija i naredbi.

Report alati po meni nemaju previše smisla za webdev zbog dinamike jezika i prirode browsera. Osoba koja intenzivno radi na generisanju izveštaja može napisati par funkcija, eventualno klasu za baratanje izveštajima, ali ne vidim zašto bi tako nešto bilo sastavni deo template enginea.

Neke stvari iz desktop development sveta jednostavno gube smisao na webu (kao i obrnuto).

[Aleksandar.Ilic]

b) nijedna sintaksa templatea osim samog PHP-a nema smisla
Dalje diskusije više nema. Ionako ćete svi kad-tad doći do istog zaključka.

to isto tvrde religiozni propovednici: postoji samo jedna istina, i to ona moja

I aj objasni nama neukima koji jos nismo progledali, na osnovu cega mozes tako nesto da tvrdis. PHP jeste bio "template" jezik, ali vise nije. Njegova sintaxa nije savrsena, i iskreno, jeste komplikovana, jer ga ima mnogo: stotine funkcija i ostalih gluposti.

Na primer, meni za moje projekte, savrseno odgovara sto templete engine (smarty) nema istu sintaksu kao php, i to sto mogu da kontrolisem sta implementator dizajna ima na raspolaganju.

Mislim da je bluesman to pomenuo, ali sta kad ja zelim da omogucim krajnim korisnicima da menjaju templejte (npr. kroz admin panel)? I zamisli reguje se nekako neki zlonamerni korisnik. Sve ce da ti pobrise...
Ako ti je odgovor da napravim parser sa explicitno dozvoljenim F-ijama i slicno, onda bi mi bilo bolje da uzmem template engine koji nema php sintaxu. I onda tvoja izjava prestaje da vazi...

[_blob_]

ma da, sve su to vrlo pompezne tvrdnje tipa :
"ja znam da sam u pravu, a vi, ko vam je kriv kad niste... shvaticete jednog dana..."

ja uopste ne tvrdim da sam u pravu, samo tvrdim da je po meni templating ipak potreban, zato sto ja zelim da klasa sve radi za mene... kada je jednom napisem necu nista vise da programiram.

to je deklarativno programiranje: kazes klasi STA DA RADI, ne i KAKO DA RADI.

to je mozda malo preuvelicavanje, ali ima smisla... ja necu da u templejtu programiram u PHP-u.
tu samo spucam LOGIKU i podatke a templating klasa napise PHP kod.

po meni je to dodatni nivo apstrakcije koji malo uspori stvari ali olaksa meni zivot. (danasnja serverska snaga sve to moze lepo da proguta...)

kome to ne odgovara.. postujem i razumem.
meni je tako lakse...
ali ako sutra shvatim da nisam bio u pravu, odmah prihvatam ono sto je bolje... nema tu sujete... covek (programer) mora uvek da uci i da ispravlja greske koje je juce pravio...

ali govoriti "vi svi nemate pojma, ja sam upravu..." to je stvarno prepotentno...

..
a sto se tice toga da dizajneri moraju da uce templating sintaxu, to po meni nije potrebno...
oni samo dizajniraju HTML, a programer ubacuje template logiku u templejt...
(dodaje skrivene tagove, tokene, petlje itd)
to je po meni pravi pristup... to nikako ne treba da radi dizajner...
..

uglavnom, ja nastavljam svojim zacrtanim putem: ubacicu caching u svoju templating klasu kao i jos neke stvari.
podici cu sajt sa nekim sarenim lepim primerima da demonstriram mogucnosti klase...

ako neko hoce da se ukljuci u razvoj neka se javi...

siguran sam da ce klasa koristiti svima nama koji su jos u pecinskom dobu i koriste templating engine... :1042:

ne zelim da to bude konkurencija Smarty-ju vec alternativa...

sto se tice ovog topika:
moram da priznam da je ovaj forum vrlo ozbiljan i da je diskusija konstruktivna bez vredjanja i nepotrebnog prepucavanja...
svaka cast ljudi!
mislim da cu da oladim EliteSecurity do daljnjeg (bar sto se tice PHP-a)...

zasto za ovaj forum nisam pre saznao.? apelujem na moderatore da popularizuju forum kod domacih developera (i iz regiona) na ovaj ili onaj nacin...

poz :)
Uncle Blob