Zašto Smarty?

[Ilija Studen]

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

[bluesman]

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.

[Petar Marić]

<flame target="Ilija Studen" mode="irony">Pa koja je pozicija i oblik tvoje rupe na saksiji?</flame>

[Ilija Studen]

Originalno napisao Naučni radnik

<flame target="Ilija Studen" mode="irony">Pa koja je pozicija i oblik tvoje rupe na saksiji?</flame>

Pre mislim da je Smarty ponovno izmišljanje rupe na saksiji više nego ovo, ali dobro. Ti si čovek koji je koristio Smarty u skripti koja je cela nešto preko 2kb koda (situacija => skripta je 2kb, Smartz 250kb).

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

Možda tebi i meni, ali nekom ne-programeru koji zna samo HTML verovatno liči na gomilu nebuloza.

Zato i imamo posao Nego, koliko puta ti se desilo da je klijent kasnije zadužen za redizajn? Najčešće ti kasnije održavaš skriptu, a ne neko treći. Meni se do sad ni jednom nije desilo da mi to zahtevaju (što ne treba da znači da neće, ali ćemo onda lako)...

[noviKorisnik]

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.

[dinke]

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:

<?php
if($nesto)
{
    //php code goes here
}
else
{
?>
<html>
<head>
<body>
...
<!-- 100-tinak linija html koda ide ovde  a onda -->
<?php
}
?>

koriscenjem smarty-a zaobilazim u veeelikom luku

[bluesman]

Originalno napisao korisnik

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.

Egzaktli

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:

<?php echo str_replace("Search", "Replace", $string); ?>

( i meni se desava da pogresim redosled parametara )
ili

{$string|replace:"search":"replace"}

ili recimo

{$string|lower|spacify|truncate}

ili alternativa ovome što je dinke pričao:

<?php
if($nesto)
{
//php code goes here
}
else
{
?>
<html>
<head>
<body>
...
<!-- 100-tinak linija html koda ide ovde a onda -->
<?php
}
?>

u smarty je, za jednog ne-programera, daleko čitljivija (naročito ako imaš homesite i syntax highlighting):

{if($nesto)}
    nešto
{else}

<html>
<head>
<body>
...
<!-- 100-tinak linija html koda ide ovde  a onda -->
{/if}

[Ilija Studen]

<?php echo str_replace("Search", "Replace", $string); ?>

Skraćeno:

<?= str_replace("Search", "Replace", $string) ?>

Znam da nije preterano lepše ali je kraće.

<?php
if($nesto)
{
//php code goes here
}
else
{
?>
<html>
<head>
<body>
...
<!-- 100-tinak linija html koda ide ovde a onda -->
<?php
}
?>

<? if($nesto) {
  // PHP code
} else { ?>
  <!-- Gomila HTMLa -->
<? } ?>

E ovo već jeste znatno lepše. Namerno ste pisali rogobatni PHP kako bi ispalo što nepreglednije Cccccc

------

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.

------

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

Koji je "kalibar" takvog projekta? Primer... Ajd da otvorimo novu diskusiju o ovome: odnos veličine projekta i broja ljudi koji su uključeni u njega. Mislim da bi to bilo zanimljivo...

[bluesman]

Ja ni jednom.

My point

Koji je "kalibar" takvog projekta?

Pa evo recimo jednog takvig kalibra. Radio sam tamo negde 1998-1999, ne sećam se tačno, projekat Morson Collection. To je firma, više galerija nameštaja, koja prodaje ekskluzivni nameštaj vodećih stetskih proizvođača.

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:

{* ovde dobijaš sledeće podatke

products - array of array
id, name, text, ...

categories - array of array
id, parent, name, ....

images - array of array
id, filename, comment....

user - array
username, access,....
*}

I to je sve što je on trebao da napravi u template. A onda čovek koji radi layout, zna šta treba da uradi sa tim podacima i pravi template:

{include file="header.tpl"}
<table>
{section name=i loop=$products}
<tr><td>{$products[i].name}</td>
<tr><td>{$products[i].text}</td>
....
{/section}
</table>
....

i tako dalje.

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

[oliver78]

Kad smo vec kod petlji,
isto pregledno:

PHP kôd:

<?php
        if ($test):
    $title = 'asdasdfas';    
    include './templates/head.php';
?>
       <-- HTML Kod -->
<?php
       else:
          $nesto_drugo;
       endif; 
?>