DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Domaci Smarty-Lite za PHP5 ! (http://www.devprotalk.com/showthread.php?t=2150)

bluesman 31. 12. 2006. 14:06

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 31. 12. 2006. 14:56

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 31. 12. 2006. 15:01

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:
Kôd:

<a href="%%link%%">%%natpis%%</a>
pa u PHP-u odredis vrednost 'link' i 'natpis' promenljivi.

ili

Kôd:

<--- 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 31. 12. 2006. 15:17

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 31. 12. 2006. 16:54

^^ 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 31. 12. 2006. 19:11

Citat:

Originalno napisao 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?

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 31. 12. 2006. 19:54

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

PHP kôd:

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


View:

PHP kôd:

<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_ 01. 01. 2007. 01:55

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 01. 01. 2007. 03:24

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 01. 01. 2007. 06:10

Citat:

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

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


Vreme je GMT +2. Trenutno vreme je 18:36.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.