|
Zašto Smarty?
Evo jednog čudnog pitanja:
Zašto koristite Smarty? U dva projekta na kojima trenutno radim ga ne koristim i nije mi zafalio ni jednog jedinog trenutka. Svoj "template engine" sam napsao za pola sata i teži celih 10kb naspram 200kb+ koliko ima sam Smarty, a radi sve stvari za koje sam inače koristio Smarty. Template su pregledni, u njima radi code completion, mogu da koristim sve što inače imam na raspolaganju i van template (tu je zamka, ako ne pazite možete preterano uneti aplikaciju u template)... |
Da, u pravu si. Razmisljao sam bas o toj temi. Da napravim template koji bi sluzio svrsi jer ne koristim sve funkcije smarty-ja. Medjutim kako sam okupiran poslovima i ispitima taj deo je ostao na cekanju.
Jednom na tvom blogu je bilo reci o mesanju php-a i html-a pa bi se na taj nacin u mnogome olaksala izgradnja web-aplikacija. |
Nakon sto sam ukapirao da mix html + php nikud ne vodi i da na kraju dobijem brljotinu u kojoj nema sanse da se snadjem ni ja koji sam to pisao, "prebacio" sam se na smarty, al' sam se zaebo i gomilu stvari "programirao" u smarty-ju. Jeste da ima gomilu korisnih (i vecini nas nepotrebnih) feature-a, ali opet treba biti jako oprezan pa, kako Ilija napomenu, ne pretjerati i praviti aplikaciju u smarty-ju.
Sreca pa je (nadam se) na vrijeme CakePHP malo pripomogao :) em sto sam zaplovio u oop punim jedrima, em sto konacno postoji prilicno jasna granica izmedju aplikacije i fasade :) |
jel imash neki primer aplikacije radjene u cake-u? ja sam taman poceo da se igram sa njim kad su mi poceli ispiti, tako da bih voleo da vidim shta sve moze
iako neke stvari izgledaju lagane, imam utisak da se malo komplikuju stvari za ozbiljnije aplikacije. za obicnu akciju treba da editujesh gomilu fajlova, da koristish neke njihove opcije koje nisu dokumentovane i tako to. ako neko ima volje da me razuveri samo napred :) |
mali OT, ali valjda nam shefovi nece zamjeriti :)
ja sam tek 5-6 dana u vezi s Cake-om, tako da je moje poznavanje istog poprilicno skromno :) uz malo strpljenja i mozganja lako ces se snaci, sve sto trebas je da "pohvatas" konvencije kojih treba da se pridrzavas. nemam nista gotovo, ali radim sajt (jos uvijek samo na localhostu), kad zavrsim okacicu link. iako sam newbie i pravim poprilicno gluposti dok ne ukapiram kako stvarno nesto treba da se izvede, mogu sasvim sigurno reci da je kod u velikoj mjeri pregledan i jasan (za razliku od onog sto sam prije pisao, razlika je kao nebo i zemlja), znas uvijek gdje ti je sta - jer da nije tamo onda ne bi radilo :) za obicnu akciju ti ne treba gomila fajlova - uglavnom mozes sve stavljati u controller, a ako ponesto smjestis u helper - isto ti dodje :) site-wide akcije drzis u app_controller-u, itd itd. prati njihovu google grupu (http://groups.google.com/group/cake-php), gomilu stvari sam skontao tek tamo. Dokumentacija im jeste mizerna, ali nije im uzeti za zlo jer je Cake jos uvijek "beba" sto se tice "ozbiljnijih" aplikacija, mislim da ce 0.10 verzija (aka 0.9.2 trenutno) biti skroz ok (dok ne izadje final 0.10, ja se drzim 0.9.1 jer mi zasad radi posao, i to dobro) |
Sve mi se čini da ću i ja Cake uposliti u jednom skorijem projektu. Jednostavno ne postoji finiji open source PHP4 framework (bar ne koliko ja znam), a pošto već dobrano poznajem način na koji Rails radi trebalo bi da se osećam kao kod kuće.
BTW: Mogao bi jedan mali split ovog i gornjeg posta u novu temu pošto su oba o Cakeu i ne spominje se Smarty uopšte... |
izvinjenje na nekromansiji, ali tek sam sad procitao ovaj thread, a ovo oko smartija mi je zanimljivo, pogotovo sto cenim Ilijino iskustvo (shliht, shliht :cool: )
Elem, zanima me oko tog homemade template endzina sto si pravio, jel on isto kompajlira templejte? Posto, bar kako sam ja to shvatio, osnovna prednost Smartija u odnosu na konkurenciju su sto se templati ne parsiraju iz php-a, nego se pretvore u php kod, pa sam php parser radi sav prljav posao, sto je ultra brze. A pored toga ima i prilicno ok reseno kesiranje outputa, i par zgodnih forica ugradjenih koje ustede neko vreme... meni se doduse najvise dopao jer je dovoljno slican TemplateToolkitu na perlu na koji sam se vec navikao (i koji je odlican btw) sad cu da pogledam taj Cake o kome pricate, jel ga i dalje koristitie? btw, mesanje HTML i PHP-a je jos podnosljivo u malim fajlovima sa dobrim editorom, ali ako se nadje i javascript funkcija u kodu onda nastane totalni haos..:) |
Klasa koju koristim uopšte ne kompajlira ništa ili bilo šta slično tome. Template je najobičniji PHP fajl koji se includeuje (njegov output se hvata u string), a ta klasa implementira neke funkcije koje sam često koristio kod smartyja: assign, display, fetch i sl.
Dobra stvar je što se jedna ogromna klasa (Smarty) izbegava i zamenjuje jednom prostom klasom. Plus, nema kompajliranja templatea (ne moraš imati write dozvole) itd. Generalno, sve je manje i jednostavnije za korišćenje, a postižeš isto. PS: Posle par meseci Smarty mi uopšte ne nedostaje ;) |
Sorry, gledam ovu temu danima i uopste ne razumem ovo što si nabrojao.
Koje su tu u stvari prednosti? To što je klasa manja? Kakve to veze ima, ne učitava se klasa u browser. To što se ne kompajlira? Pa šta da kompajliraš kad i nemaš template nego php sa include? To što ti ne treba write permission? Od kada je write permission problem osim na onim free hostingzima. To što je jednostavnije? Možda, ali smarty se pokazao kao izuzetno jednostavan, i komplikovanost nikada nije bio problem smarty, ljudi (čak i oni koji nemaju pojma sa programiranjem) ga nauče za par sati. Po onome sto si napisao ti i nije template engine nego (ne)običan PHP. Mi smo jednom imali diskusiju po tom pitanju i kod tebe se, bar prema onome što sam video, nigde ne vidi čak ni tanka linija između template i engine. Tu si pravio krucijalne greške (ne programerski nego konceptualno za template sistem), ti na primer iz backend dodeljuješ .CSS određenom template, što ruši sam "backend-template" koncept. Backend ne mora da zna koji CSS se koristi na strani, njegovo je da obezbedi zatražene podatke, a frontend template ih prikazuje ili radi sa njima šta hoće. Pravi template sistem mora da jasno razgraniči dokle ide backend (php), a gde je frontend (template). Takav sistem mora da omogući da recimo programer i dizajner mogu odvojeno da rade na istom projektu. Tvoj sistem je možda dobar, neću da ulazim u to, ali to nema veze sa template engine. |
@Ilija: osnovna ideja template endzina ala Smarty je za timski rad, kad imas ljude koji ne znaju php (pa su manje placeni), a rade ti template... onda oni nauce par osnovnih fora iz Smarty sintaxe i mogu na miru da seckaju html, a ti radis programiranje nezavisno...
Inace kad ja sam radim sve, apsolutno se slazem sa tobom, php je sam po sebi embeded jezik i nema potrebe da se izmislja dodatni jezik. Ako nateras sebe da koristis minimum koda u templejtima (echo, if, for, funkcije...), a sav ostali kod drzis van templejta, onda Smarty sintaxa nije preterano laksa od php-a, ko zna bar neki jezik sa C-like sintaxom (php, js..) ce se lakse snaci sa for petljom nego sa smartijevim blokovima... Ali ostaje i dalje kesiranje outputa, koje je u Smartiju odlicno reseno, a ovako bi morao da ga sam pises... |
Prednosti ima par:
1. Bojanje sintakse, prepoznavanje blokova itd itd. Koji editor ima te mogućnosti za Smarty? 2. Radi code completion i code proposal. Ako mnogo koristiš OO onda ove stvari jako mnogo znače. Inače sam ranije dosta vremena gubio (na duže staze) jer ovu mogućnost nisam imao unutar templatea. 3. Može se pozivati sve, uključujući i statičke metode (jako mnogo koristim Singletone klase kojima se pristupa statički pa mi je ovo bilo izuzetno bitno). 4. Sve je manje, urednije, brže, a radi isti posao. Mane: 1. Mogućnost da se pomeša aplikacija i kod unutar template. Ovim sam se ogradio jer sam napravio strog MVC framework. Tačno se zna šta gde i šta čemu sme da pristupa. Radio ranije pogrešno (Blues je spomenuo jedan od radnijih radova ;) ), udario glavom u zid i ispravio. 2. Iza ovoga nije uloženo toliko truda kao iza Smartyja tako da neki detalji nisu toliko ispeglani. Što se keširanja tiče za sada mi nije potrebno tako da o njemu nisam preterano razmišljao. Ne verujem da bi trebalo više od par sati da se implementira kvalitetno rešenje kad zatreba. PS: PHP je sam po sebi template engine, a Smarty je template engine za template engine. Hm... |
Prednosti (?)
1. Ima homesite kada se skine syntax highlighting sa official smarty sajta 2. Ima homesite. 3. ne znam na šta misliš, ali 'ajde. Mada ne vidim prepreku tome i kroz smarty {PHP} {/PHP} 4. Naravno da je brže designtime kada nema kompajliranja, ali runtime ne može biti brže (bar ne iole značajno). Urednije? Možda tebi i meni, ali nekom ne-programeru koji zna samo HTML verovatno liči na gomilu nebuloza. Mane 1. Nemogućnost timskog rada, potrebno je obučiti dizajnera da nauči PHP, dok su smarty modifiers prilično straightforrward, a sve što treba da nauči je kako da koristi petlju 2. Egzaktli :) Pored toga, za smarty postoji gomila 3rd party ekstenzija koji odrađuju i one jednostavne kao i vrlo komplikovane stvari. Ni ja ne koristim keširanje jer sam testirajući naišao na dosta problema, mada za neke polu-dinamičke sajtove gde ima puno statičkih strana tipa "about us"... može da bude prilično handy. |
<flame target="Ilija Studen" mode="irony">Pa koja je pozicija i oblik tvoje rupe na saksiji?</flame>
|
Citat:
Ne koristim HomeSite već Zend Studio koji nema tu podršku (meni je ona izuzetno bitna). Ne bih ovo okarakterisao kao "nemogućnost timskog rada". Sam PHP je malo kompleksniji od Smartyjevih tagova, ali opet razlika nije preterano velika. Kad čovek skonta osnovne koncepcije onda će mu i Smarty i PHP delovati relativno jednostavno jer je to manje više jedna stvar i međusobno jako liče (primera radi if i foreach su manje više isti i u PHP i u Smartyju). Citat:
|
Imam utisak da u ovoj diskusiji fali realna distanca... viđenje nekoga ko nije primarno developer a jeste dizajner i uspeva da se snađe u HTML-u. Jer, Smarty po definiciji i jeste dizajniran za takav profil korisnika. Baš kao što su to i drugi template sistemi.
Meni je jasno da developeru može da izgleda suludo da priprema podatke za izlaz ako se sam bakće i sa samim izlazom. U tom slučaju gleda šta mu je bliže, a tu je već PHP, pa zašto onda Smarty??? Ali, ako o izlazu treba da se stara neko drugi, onda mora da uzme u obzir kako će se pripremati podaci. Da li će to biti neka PHP struktura, Smarty ili neki drugi template engine, XML za XSLT, to su samo moguće opcije, suština je da priprema podataka treba da jasno bude odvojena od pripreme izlaza, a izbor opcije je stvar dogovora i naravno umeća. |
Evo i ja nesto da kazem na ovu temu :)
Ja tezim da koristim smarty kad god moram da se bakcem sa html-om, osim kod trivijalnih html strana. Recimo juce sam kreirao neki jednostavan script gde sam imao 30-tak linija html koda cisto kao demonstraciju (posto se sav posao obavlja u backendu), i tu naravno nisam koristio smarty. Alternativa smarty-u su php klase koje generisu html output. Tako sam ja recimo u svojoj bivsoj frmi morao da koristim neki rotella framework (http://www.rotella.org) koji je generisao html sa php kodom tipa: $table = new table("640",2,2); $table->tr ... itd ... svaki html element je imao odgovarajucu klasu. Mislim da postoji nesto slicno i u PEAR-u. Meni je recimo to bilo uzasno smaranje. Posle toga smarty deluje kao pesma :) Ali opet stvar licnog ukusa. Inace, ja smarty prevashodno koristim da bi razdvojio dizajn (html kod) od logike aplikacije, i zaista se trudim da na tome i ostane, tj. da nikako ne predjem onu crtu koju je u smarty-u tako lako preci, a to je da se smarty stara o stvarima o kojima ne bi trebao. Mislim da sam u tome uspevao. Smarty koristim cak i kada nemam apsolutno nikakvu potrebu da to uklapam sa nekim dizajnerom, niti licno smatram da je smarty bas tako jednostavan dizajnerima kao sto neki drugi misle. Btw, jos jedan fin nacin da vidite prednosti smarty-a je da uporedite kôd nekog projekta gde je koriscen smarty sa nekim koji koristi spageti php/html pa cete i sami videti sve prednosti smarty-a :) A moj "favorit" stvari tipa: PHP kôd:
|
Citat:
Mada bih ja dodao da Iliji fali jedan veliki projekat koji nije uradio on sam. Tada će pogledati na ove stvari drugim parom očiju :) Kada je tako podeljen posao: programiranje | layout, jednostavno ništa ne sme da prelazi crtu između osim samih podataka. Recimo, idealno stanje stvari je da postoji još jedna osoba između koja ih koordinira. Znači imamo šemu sajta, zna se šta se na kojoj strani radi, programer dobije zadatak podeljen u 2 dela: priprema podataka za output i prijem i obrada primljenih podataka. Njega ne interesuje da li će output biti HTML ili možda šalje podatke u flash, njegov posao se završava u oba pravca sa njegove strane crte. Njega ne interesuje da li će biti ovaj css, ili će menu biti levo ili gore, on čak ne mora ni da vidi kako izgleda sajt dok god hrani frontend podacima koji su zatraženi. Teoretski (ako izuzmemo ljudsku osobinu zvanu znatiželja :) ) on ne mora nikada ni da vidi sajt a da sajt bude završen uspešno. Koder (dizajner, ali dizajner je malo više, pa je možda bolje da kažem "onaj koji radi layout") ne mora da zna kako su i odakle podaci došli, on zna šta dobija, kakvu strukturu podataka i prikaže ih kako želi. Isto tako, kada ima input (form) kaže programeru "dobićeš na taj i taj script podatke .a, b, c, treba mi povratna informacija da li je ok. Njega ne interesuje kako je došao do "ok", bitno je da on dobije nazad "ok" ili "error" ili šta god. Ne interesuje ga da li je to php, asp, da li su podaci iz mysql ili iz text fajla, on zna šta dobija i zna šta šalje, šta se između dešava može da bude predmet njegovog fakultativnog interesovanja. Takvim načinom rada (uz tu treću osobu) programer i "onaj koji radi layout" mogu čak i da budu u svađi, da ne pričaju, pa da uspešno završe posao :) Smarty (ili neki sličan tempate engine) je ta veza između njih, dovoljno jednostavan da "onaj koji radi layout" može brzo da ga savlada, a dovoljno kompleksan i promenljiv (expandable) da može da se dobije i više od osnovnog. Razmislite samo, iz perspektive nekoga ko ne zna programiranje, da li mi je lakše objasniti: PHP kôd:
ili HTML kôd:
{$string|replace:"search":"replace"}HTML kôd:
{$string|lower|spacify|truncate}Citat:
HTML kôd:
{if($nesto)} |
Citat:
Kôd:
<?= str_replace("Search", "Replace", $string) ?>Citat:
Kôd:
<? if($nesto) {------ Nego, možemo da teoretišemo koliko hoćemo. Jedno jednostavno pitanje: u koliko projekata ste učestovali gde je bila povučena crta između dizajnera i programera (oboje u crnim kutijama)? Koliko puta ste se našli (ili uspeli da izbegnete korišćenjem Smartyja) u situaciji kad vas dizajner (dizajner = osoba koja radi layout :) ) zove telefonom i ređa sve po spisku jer apsolutno ne razume template koje ste mu poslali? Ja ni jednom. Uglavnom radim sa ljudima koji jako dobro poznaju kako PHP tako i XHTML, CSS. Ako ne onda ja kodiram (jako retko). Znači, sve te priče: "Kad bi ti morao da radiš sa..." ili "Kad bi bilo ovako..." jednostavno ne stoje kao argument za ogroman broj projekata. Slažem se, postoje situacije kad je to potrebno, ali koji je njihov procenat? PS: Evo baš ću u trenutnom projektu koristiti Smarty za generisanje stranica (ne kao primarni template engine) jer će sa tim korisnici dolaziti u direktan kontakt. Ne kažem da je Smarty loš ili bilo šta slično tome, samo tvrdim da ga ljudi trpaju u stvari gde je on jednostavno nepotreban... Ljudi ga koriste po inerciji, ne po potrebi ------ Ako Smarty koristite samo da biste jasno povukli crtu između aplikacije i template kao što Dinke reče onda tu ne vidim poentu. Isti trik se postiže sa klasom od 60 linija koda: template se učitava u funkciji (nema globalni scope), sme da pristupa samo onim promenljivima koje su mu prosleđene ili servisnim klasama i to je to => kontrolisano okruženje. Za takve stvari nije potrebna klasa od 1.5k koda... Kao što sam već rekao, ako se držite MVCa nema puno grešaka. ------ Citat:
|
Citat:
Citat:
Pošto je bilo preko 5 000 proizvoda koje je trebalo srediti, pri tom upisati ih sve u bazu, organizovati po kategorijama (recimo sofa ide pod "sofa" ali i pod "living room"), svaki je imao bar po 3 fotografije, pri tom su one čuvane u neko softweru gde su slike u nekim ogromnim fajlovima sa definisanim keywords, koje je trebalo iščupati iz svake slike i ubaciti u bazu. Znači veliki posao, dodeljen je dvojici ljudi, jedan je radio slike, a drugi katalogizaciju. Naravno, za to je bio potreban jak backend koji je sve to povezivao i uz to omogućavao još neke druge stvari, na primer imali su svoje dilere, koji su mogli da se uloguju i svaki diler ima svoj portfolio od proizvoda koje on sam izabere, gde prati prezentacije, prodaju... Gomila programerskog posla za koji je bio zadužen jedan čovek. Četvrti čovek je bio zadužen za prikazivanje svega toga, ceo frontend, uključujući i JavaScript kojeg je bilo puno. Peti čovek je radio quality control, proveravao upise, pazio na definisane rokove i koordinisao rad ove četvorice. Projekat je dobijen na konkursu, a kao ilustraciju koliko je "veliki", bilo je bid-ova od po 800.000 USD. Naravno, naš je bio mnogo manji od toga, pa smo i dobili posao. Korišćen je u potpunosti PHP / MySQL / Smarty. 3 od tih 5 ljudi nemaju veze sa programiranjem. Kako je rađeno: Čovek koji radi PHP backend, napravi script i osnovni template koji izgleda otprilike ovako: Citat:
Citat:
Znači, programer nema pojma niti fa interesuje šta će koder sa tim podacima, dok ovog drugog ne interesuje odakle ti podaci, bitno je da su tu, a sve što ga interesuje je kako da ih prikaže. O ostaloj trojici da i ne pričamo. Jedan je bio fotograf, drugi je asistent na filološkom fakultetu a treći je bio pomoćni radnik. Znači jedina veza sa programiranjem im je kada okrenu programator na veš mašini :) |
Kad smo vec kod petlji,
isto pregledno: PHP kôd:
|
Kôd:
<? include_template('header.tpl') ?>Ja opet ne znam zašto bi onaj Smarty kod bio jednostavniji nekoj osobi od recimo ovog gore. Ako ga već forsiraš da uči jezik (pošto Smarty skoro da jeste jezik) mislim da mu je svejedno da li će blok obeležavati sa { - } ili sa <? - ?>. Što se navedenog projekta tiče on je obiman po materijalu kojim barata, ne i po komplekesnosti skripte, bar koliko ja vidim iz ovog opisa, a od pet osoba koje su radile na projektu samo dve su dolazile u kontakt sa templateima. Nego, imam čudan osećaj da vi PHP template vidite kao prljave i konfuzne. Oni su takvi kad ih prave početnici. |
Pa ja sam ti dao samo deo projekta, a ovo shorthand pisanje je depreciated. Zar i ti? Koji toliko drzis do standarda? :)
I nemoj samo da mi objasnjavas kako je lakse nauciti PHP nego Smarty :) |
^^ pa nije Smarty bas toliko jednostavan, recimo ja bas sad pokusavam da naucim jednog momka sa kojim saradjujem, a koji zna html i css solidno, i javascript pomalo... mnogo mu je jasniji php kod (bar one najjednostavnije stvari koje idu u template), nego Smarty, jer je php vrlo slican javascriptu u osnovama, pa vec zna kako da napise if, petlju, pozove funkciju... Smarti mora da uci iz pocetka..
Mislim da su XML based sistemi kao sto je coldfusion i struts mnogo bolji za totalne pocetnike koji znaju samo HTML, ali sta je tu je, dok ne naprave nesto jos bolje, Smarty radi posao... |
Citat:
Jedno je slepo poštovati standarde i trošiti vreme na stvari koje toga nisu vredne, a drugo je poštovati standarde, ali ipak težiti što praktičnijem rešenju. :cool: Citat:
|
Da nije taj isti čika iz primera počeo da uči JavaScript od sredine? <?= $wtf ?>
|
ALGORITAM je najvazniji, a jezik moze biti i kineski.
Ko ne razume nacin na koji se neke stvari odvijaju, dzaba mu bilo kakav prost jezik. Takodje, ako je jezik prost nemogu se pisati remek dela. Mislim d a ovo vazi za sve oblasti pa i za programiranje. C++ > PHP > Smarty Znate na sta mislim. |
^^ deep :)
pa slazem se ja sa ovim genralno, ali pricamo o Smarti vs. plain vanilla PHP.. a algoritme ne stavljas u templejte, u templejte stavljas prikazi ovo jedanput, a ovo deset puta, i ispisi mi onda ovo sa velikim pocetnim slovom...i ideja je da templejt jezik bude sto prostiji da bi se : a) brzo naucio b) napravilo sto manje gresaka sad je samo pitanje da li se isplati koristiti veliki sistem koji trosi resurse, ali olaksava stvari narocito ne-programerima, ili koristiti mogucnosti jezika direktno i efikasno, a uz cenu da moras da nadjes pomagace koji vec znaju nesto... moj komentar je da se osnove php lako pokupe, za nekog ko je radio u javascriptu, actionscriptu ili recimo Maya script jeziku (posto je pretpostavka da se radi o nekome ko se pretezno bavi grafikom i dizajnom), tako da sama lakoca sintaxe posle 2 projekta vise nije argument jer ce taj neko uveliko nauciti bilo Smarty bilo osnovne stvari u php-u... |
Trazio sam nesto po netu, pa slucajno naleteh na ovaj text
U principu covek prica istu pricu o kojoj smo i mi ovde raspravljali, ali na lep i organizovan nacin (stim da jeli zastupa jednu stranu u raspravi, ali argumentovano) |
Ajd dodatak, posle određenog vremena:
1. U više navrata sam se opet uverio da klasičan pristup (korišćenje PHP umesto template enginea) ima niz prednosti u odnosu na template engine. Praktičnost, brzina itd... 2. Template enginei poput smartyja mogu biti korisni ako želite korisnicima da date mogućnost izmene istih kroz administracioni panel (dati im PHP u ruke na taj način je ravno samoubistvu). Znači, u tim situacija IMO najbolje rešenje je Smary sa registrovanim pluginima i resursima. Znači, opet branim stav: PHP za sve, Smarty samo za posebne slučajeve (naveden primer gore). PS: ivanhoe hvala za link. Baciću detaljniji pogled kad se dokopam normalnog neta i komentarisati tako ima nešto da se komentariše. Inače se slažem sa originalnim postom (komentare nisam čitao). |
Citat:
Što se tiče linka koji je ivanhoe ostavio mogu zaključiti nekoliko stvari: 1. Ričard je neupoznat sa osnovnim principima softverskog inženjerstva. 2. Zapad je truo - dokaz: autor gorepomenutog unosa je "Zend sertifikovani inženjer". 3. Uzimati s izvesnom dozom rezerve ono što pročitate na nekom blogu/sajtu/forumu. |
osnovni princip svakog inzenjerstva, pa i softverskog je da moraju da postoje prakticna opravdanja zasto se nesto radi na odredjeni nacin...tako da pokusaj da budes argumentovan kad dajes izjave kako taj i taj nema pojma, cisto da ovo ne bi bio obican flejm war, nego konstruktivna rasprava..
Ja sam koristio Smarty dosta, pre toga sam templejt sistem iz phpLib-a, a pre toga koristio sam TT2 za perl (vrlo slican koncept), a pre toga smo imali sopstveni templejt endzine napisan u perlu i C-u kao cgi (koristen za cleverform.com dok sam jos radio tamo)... tako da nije da sam neko kome su templejti strana stvar, i naravno da podrzavam upotrebu templejta, samo sto sam tek nedavno postao svestan da je PHP zapravo jednostavan, ali vrlo efikasan templejt endzine sam po sebi... Dakle nije pitanje uopste da li koristiti templejte ili ne, nego da li praviti templejte u PHP-u direktno, ili koristiti Smarty koji ce automatski da ti izgenerise templejte, koji su isto tako u PHP-u (ali vrlo cudnom i prilicno neefikasnom u poredjenju sa rucno kreiranim) Ako se covek samodiciplinuje da od php-a u templejtima koristi iskljucivo echo varijabli, if-else, petlje i poziva funkcija, i uz to koristis skracenu sintaxu za php onda nema velikog gubitka na citljivosti templejta ne-programerima. Ostaje druga velika prednost Smartija sto on ima gomilu gotovih funkcija, ali to su vecinom obicne php funkcije koje se vrlo lako mogu odraditi i u cistom php-u...nista te ne sprecava da napravis (vecina nas to vec ima) svoju biblioteku util funkcija koje ce se onda pozivati iz templejta. Isto vazi i za pluginove, nikakav problem da ugradis i to u svoj sistem ako ti se svidja, to su ionako samo jedan include i jedan niz koji registruje callback funkcije, nije neka pamet... Ostaje jos pitanje kesiranja, koje naravno mozes opet da odradis direktno...jedna stvar koju ne znam kako bi moglo da se laku uradi je Smartijeva mogucnost da keshira samo delove templejta, to je odlicna stvar...ali realno vecina ljudi koje ja znam uopste ne koristi kesiranje u Smartiju... I na kraju bottom line je da smarti olaksava stvari utoliko sto ima puno toga uradjeno, pa ga zato ja i dalje koristim (jer sam lenj da pravim sve iz pocetka), ali definitivno (IMHO) ne stoji tvrdnja da ne moze da se uradi ili da je losije onako kako autor onog clanka ili Ilija tvrde... Petre, naravno da bih voleo i da procitam neku tvoju kontra-argumentaciju...nemam nista protiv da me ubede da nisam u pravu, ako zaista nisam...ali onda daj neke konkretne stvari, cinjenice, a ne metode srpskih politicara...:) |
Disclamer: Pun odgovor ću napisati ujutru ;)
Najveći problem za mene, kao nekog ko uči da postane inženjer, nije ni čitljivost koda, ni perfomanse, ni keširanje, ni... Ono što mene interesuje je sigurnost. Ako koristiš php direktno kao template jezik samo tražiš nevolju - čovek koji sređuje html markup onda može: 1. Da promeni ponašanje aplikacije - jako zeznuta stvar. 2. Da uz pomoć introspekcije sazna neke osetljive stvari o aplikaciji - zna prilično da zaboli ako tako skonta lozinke ili, perish the thought, olakša reverse engenering tvoje enkriptovane aplikacije. 3. ... (More to come after a good night sleep) |
ok, to stoji za sigurnost (to je i Ilija pomenuo uostalom), ali to vazi iskljucivo za varijantu gde prvo imas neke korisnike koje ne poznajes, drugo oni mogu da menjaju templejte. To je jako specificna sredina, gde pored php-a postoji opasnost od milion drugih stvari (pristup tudjim fajlovima, javascript napadi..)
Ali 99% projekata nisu takvi, uglavnom radis sam ili sa jos par ljudi na sajtu, a korisnici (ako postoje uopste) neimaju nikakav pristup templejt sistemu....a ljudi sa kojima radim ionako imaju pass za ftp i bazu, kako da rade bez toga...Jedino da kazes da ce neko nevestom upotrebom php koda da nesto zezne, ali kao sto rekoh fora je da se praktikuje disciplina sta sme da ide u templejte. Ako samo prikazujes podatke i pozivas high-level funkcije nema sta da se zezne slucajno (ili bar isto toliko moze da se zezne iz Smartija, zar ne?) |
kao sto ivanhoe rece, a i koliko je meni poznato, smarty ima {php} tag, pomocu kog u template mozes da ubacis php kod koji hoces. toliko o smartiju i sigurnosti ako se gleda iz tog ugla. druga je stvar to sto neko ko menja smarty template najverovatnije mora i da ga uploaduje, a da bi ga uploadovao, najverovatnije ce imati pristup ili celom vhost root-u, ili makar direktorijumu koji sadrzi ceo template koji se edituje - tu dolazimo do pitanja - hoces li nekom kome ne verujes dozvoliti da pravi template za tvoju state-of-the-security aplikaciju? kada je neko paraoican, onda je paranoican na svim poljima...
ja sam za sebe odradio neki mini-template engine, koji je na neki nacin imitacija smartija, ali samo u odredjenoj meri. taj moj engine guta sirov php, ali ima neke osnovne skracenice koje smarty koristi (tipa, varijabla se ispisuje sa {$var}, postoje if/else/elseif, foreach strukture, vise-dimenzionim array-ima moze da se pristupa kroz {$var.lvl1.lvl2....}, itd), ali to su samo neke skracenice da ucine kod preglednijim. dalje, sam template engine podrzava template injection, tako da je moguce spucati template iz baze (umesto iz fajla na disku), engine ga renderuje i to lepo zapise u fajl na disku, tako da sledece pozivanje istog template-a (u slucaju da nije promenjen) samo include-uje php kod. nisam napravio pravo smartijevo keshiranje, jer po meni to ima smisla samo (i samo) ako je sajt zaista (jako) posecen. dakle, mislim da parsiranje template-a nije ni izbliza posao kao na primer generisanje grafikona i ostalih slika pomocu gd-a gde je cachiranje gotovo "a must". nista revolucionarno, ovo sam opisao samo u slucaju da je nekom potrebno nesto brzo i jednostavno (i nedovoljno testirano, da bih ga proglasio robusnim), a opet funkcionalno. (/me looks at ivanhoe's post #7 since 1.5 months ago..;)) |
Smarty ima jednu jako zgodnu stvar: resurse. Plus možeš limitirati potencijalno nesigurne "tagove" ({php} npr). Zato sam ga koristio kao osnovu za template sa kojima korisnici dolaze u kontakt (kroz admin aplikacije). Sve ostalo je stari dobri PHP.
|
ma smarty ima dosta jako zgodnih stvari ;)
|
Ccc, em što me čitate šta pišem, em što ne čitate dokumentaciju:
1. Smarty ima jednu lepu promenljivu klase koja se (suprise, suprise) zove $security tako da sve te priče o php injection padaju u vodu ako znate da konfigurišete smarty. Nasuprot tome, želeo bih da vidim kako ćete u svojim "mixed PHP/HTML kod" template-ima da zabranite izvršavanje arbitrary php koda. 2. Zextra, keširanje je odluka vezana za poboljšanje perfomansi. O merenju perfomansi i poboljšanja u istim sam ti već dao savet. 3. Ako ne shvatate koje su to prednosti koje dobijate korišćenjem Smarty-ja (ili čak bilo kog drugog template engine-a) u odnosu na mixed PHP/HTML kod, savetujem Vas da pažljivo pročitate ovaj članak. Ako bude bilo nedoumica slobodno postavite pitanja, ali tek nakon što ste pročitali celokupan članak. 4. I, molim Vas, dosta mi je argumenata nepotkrepljenih činjenicama: - Smarty src je preveliki. Smarty biblioteka kod mene na disku zauzima 310KB (317.636 bajta za picajzle). Da li to predstavlja problem za kapacitet na disku na Vašem web hosting nalogu? Čisto sumnjam. Doduše, može predstavljati problem da se dotična biblioteka prenese na server, ali to ne morate raditi svaki put kada vršite ažuriranje sajta. - Smarty je prespor. Just the facts Jack. Napravi benchmark-e, ostavi kod istih i rezultate pa ćemo da uporedimo koliko je veliko to usporenje koje Smarty unosi. - Moja home-made XY biblioteka je bolja/lepša/brža od Smarty biblioteke. Ne isključujem mogućnost, samo da li bi bio ljubazan da podeliš tvoj kod sa nama i ostatkom sveta - bilo bi lepo kad bismo mi mogli to isto da uvidimo i onda koristimo ono što nam je bolje/lepše/brže. |
aman Petre, a da ti procitas sta ljudi ovde zapravo pisu ??
Uporno izigravas advokata upotrebe templejta, a naravno da svako normalan podrzava upotrebu templejta, pa niko to ne dovodi u pitanje... samo je pitanje da li ti treba poseban jezik za to, kad vec imas php? To nije isto kao pisanje html/php spageta... ako cemo pravo onda samo XML/XSLT templejti imaju smisla, sve ostalo su spagete ovako ili onako... Sto se ostalih komentara tice: Koliko cesto pravis sajt sa korisnicima kojima neverujes, a mogu da menjaju templejte? Evo ja sam radio puno toga (radim web programiranje od 2000-te i od toga zivim), i jos nikad nisam pravio takav sajt... jedino CMS-ovi za vise korisnika imaju taj problem, a takvih projekata ima sveukupno da ih na prste prebrojis... meni bar jos niko nije nudio da uradim neki, ti ako si radio, bas bih voeo da cujem ? naravno da u takvoj sredini neces dozvoliti direktnu upotrbu php-a, ali realno je u takvoj sredini i upotreba Smartija securtity risk, pogleda change log za Smarty pa ces videti prilican broj security propusta koji su pronadjeni vremenom...kad god koristis neki opste poznat sistem(CMS, template engine, etc..), onda znatno povecavas sanse da te neko uhakuje... za zextrin licni templejt endzine niko nije cuo sem njega, niko nije video kod, samim tim manje su sanse da neki klinac iskopa na IRC-u uputsvo kako da dropne bazu... pogledaj sta se desilo staroj Zoni, zbog rupa u IPB-u... Sto se perfomansi Smartyija tice on je najbrze sto moze da se postigne takvim pristupom, ali ne treba biti genije pa shvatiti da automatski generisani php ne moze da se meri sa rucno pisanim, da ne pominjemo sav glue kod koji mora da se ubaci, i overhead zbog kreiranja Smarty objekta... u vecini sajtova to i nije neki problem, ja koristim Smarty godinama bez ikakvih problema, ali da budemo iskreni ja bas i nisam pravio neke heavy-duty sajtove...ljudi koji jesu pravili takve sajtove kazu da treba izbegavati Smarty za to, zbog overhead-a i ja cenim njihovo misljenje...that's all.. |
dakle, Petre, tebi smarty odgovara, nekom drugom (npr. meni) delimicno odgovara, a nekom trecem ne. e sad, ako ti pokusavas da ubedis nekoga kako treba da koristi smarty (a on to bas nece jer nije bio u stanju da procita kompletnu dokumentaciju), zasto TI lepo ne pokusas da razuveris njega po pitanju, recimo, te iste brzine koja je problematicna u ovom slucaju, time sto ces naci argumente u korist smartija i kontra-argumente u korist neceg sto taj hoce da koristi? mislim, ovo je cist flame-wars, ako cemo iskreno. to me podseti kako sam ja svojevremeno pokusavao da sve neke ljude ubedim da je perl zakon jezik ;)
dakle - koristiti tpl engine ili ne je samo stvar izbora. uzgred, brzina je vrlo vrlo relativna stvar... p.s. procitao sam tvoj predlog po pitanju optimizacije skripti, tnx. |
Sad me flejmujte ako treba:
PHP je sam template engine. Koliko je koriscenje Smartyja bezbedno, to je pitanje, jer je to opensource program i reversing koda nije problem, kada vec govorimo o radu u timu. Dizajner moze da ubaci PHP preko nekog exploita u Smarty, i BTW zasto dizajner mora da pise HTML uopste? Ne moze li to webdeveloper? Uz takvo resenje rada u timu, nema problema sa insertovanjem PHP/SQL-a kako bilo, uz Smarty ili bez njega |
| Vreme je GMT +2. Trenutno vreme je 07:37. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.