..:: php-si ::.. slovenska php stran

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 18:33

Znotraj smartyja bi rad uporablu pear:db ker drugace ne morem priti do nekih poizvedb. Za pear:db imam napisan razred. Kako naj ta razred uporabljam v smartyju? Tako kot z funkcijo noce delat.

Mogoce kaka ideja, oz kako naj izvedem poizvedbo znotraj smartyja, znotraj foreach stavka v smartyju.

nisem majster a neki upam da znam:D

Roky
član

št. sporočil: 518

datum: 24.03.2008 | čas: 18:39

Uporabi php blog:

{php}
   global $foo, $bar;
   if($foo == $bar){
   echo 'This will be sent to browser';
   }
// assign a variable to Smarty
$this->assign('varX','Toffee');
{/php}

http://www.smarty.net/manual/en/language.function.php.php

http://trsplet.com || http://fri.trsplet.com || http://trsplet.com/blog/ .::. blog o spletu ||

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 18:52

hvala ampak nisi me zastopil, rabim poizvedbo se pravi morem brat iz baze, in ce naredim to potem javi da ne pozna getAll. Zaj kako uporabit ta getAll v smartyju. To je kot sem omenil razred in ne funkcija.

berem na primer:
$sql = $db -> getAll($sql);

Se 1x problem je kako getAll spravit da bo delal v smaryju, je pa del razreda.

sporočilo je spremenil senzacionale [24.03.2008 ob 18:55]

nisem majster a neki upam da znam:D

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 19:14

foreach($sql as $novica)
{
$smarty->assign('novica', $novica);
}

in primer v .tpl
{$novica.naslov}

sem sel predelovat izpis ampak tako pa mi smarty vedno izpise samo eno novico in nikoli vec, zakaj?

nisem majster a neki upam da znam:D

fatg
član

št. sporočil: 1693

datum: 24.03.2008 | čas: 19:18

to je zato, ker ti foreach-aš skozi array in vsako novico zapišeš v isto spremenljivko. Seveda je potem na koncu noter samo zadnja.

En način je, da v smarty pošlješ kar $sql in potem v smarty-ju iteriraš po njej. Ne vem točno, kako, ampak se da.

Drugače pa malo razmisli, če se ti splača sploh matrat s smartyjem, jaz sem ga uporabljal eno leto in sem nazaj na čistem php-ju, ker smarty ne doda niti ene same prednosti, samo komplikacije (kot recimo tvoja) ...

lp

you\'re never too fat to do it

ace
član

št. sporočil: 1291

datum: 24.03.2008 | čas: 20:33

Koda:

$smarty->assign('novice', $db -> getAll($sql));

{foreach from=$novice item="novica"}
...
{/foreach}

Smarty definitivno pohitri štancanje templateov, ker je sintaksa preprosto krajša od phpjeve.
Sploh v primeru, ko se želiš izogibati uporabi short open tag-ov. Seveda je pa treba imeti nekako glavne funkcije in sintaktične zanke v glavi.

sporočilo je spremenil ace [24.03.2008 ob 20:39]

[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url]

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 20:49

ace hvala samo na tak nacin ne gre

imam takole:

$sql = $db -> getAll($sql);
$smarty->assign('sqlnovice', $sql);

in v .tpl

{foreach from=$sqlnovice item=novice}
tu not pa bi rad se eno poizvedbo ampak ne gre, ker moram glede na nek id dobit se neke informacije iz baze. Pa ne vem kako se tu noter uporabit getAll metodo
{/foreach}

zato sem v .php datoteki hotel uporabiti na sledec nacin

$sql = $db -> getAll($sql);
foreach($sql as $novica)
{
$smarty->assign('novica', $novica);

se 1x getAll metoda, ker tu dela
}

in primer v .tpl
{$novica.naslov}

ampak izpise samo prvo novico in ne vseh ker kot je rekel fatq zapisem v isto novico.

Zaj kako naj resim na prvi ali na drugi nacin, samo da bo delalo

Hvala

nisem majster a neki upam da znam:D

fatg
član

št. sporočil: 1693

datum: 24.03.2008 | čas: 20:59

Citiram:

"Smarty definitivno pohitri štancanje templateov, ker je sintaksa preprosto krajša od phpjeve."

Koda:

$smarty->assign('novice', $db -> getAll($sql));
{foreach from=$novice item="novica"}
...
{/foreach}

vs.

Koda:

<?php foreach ($novice as $novica): ?>
...
<?php endforeach; ?>

A je ta razlika vredna učenja nove sintakse, zapletov zaradi omejenosti smartyja, upočasnitev izvajanja in ne nazadnje težjega razhroščevanja? Meni se ne zdi.

you\'re never too fat to do it

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 21:27

delno imas prav fatq, sintaksa je cisto nova, logika je ista ampak druga sintaksa. Je pa dober smarty za multidesign. Zaj ce sem se ze spravil na smarty bom se na njem ostal, samo ta problem morem resit

nisem majster a neki upam da znam:D

Roky
član

št. sporočil: 518

datum: 24.03.2008 | čas: 21:45

{foreach from=$sqlnovice item=novice}
tu not pa bi rad se eno poizvedbo ampak ne gre, ker moram glede na nek id dobit se neke informacije iz baze. Pa ne vem kako se tu noter uporabit getAll metodo
{/foreach}

... namesto tegale lahko takole narediš:

PHP:
$sql = $db -> getAll($sql);

foreach($sql as $key => $novica) {
$sql[$key]['dodatne_informacije'] = $db->getAll('query: ki dobi neke informacij glede na nek id, recimo $novica['id']);
}

$smarty->assign('novice', $sql);

Smarty:
{foreach from=$novice item="novica"}
//nek info
// dodatne informacije, ki smo jih dobili s PHP-jem pri dodatnem querjiu
{/foreach}

@fatq: Se strinjam, nekje delaš po ovinkih s smartijem da prideš do tistega, kar bi s PHP-jem veliko lažje naredil ali pa primeri kot je recimo senzacionale-tov, ampak vseeno se mi zdi, da je nekje smarty bolj pregleden kot PHP, primer:

<?php foreach($Models as $model) { ?>
<div class="frame">
<a href="/pricelist/?model=<?php echo $model['BrandModel']['model_id']; ?>">
<img src="/img/pricelist/<?php echo strtolower($model['BrandModel']['name']); ?>.jpg" alt="<?php echo $model['BrandModel']['name']; ?>" />
<b><?php echo $model['BrandModel']['name']; ?></b>
</a>
</div>
<?php } ?>

$smarty->assign('Models', $db -> getAll($sql));

{foreach from=$Models item="model"}
<div class="frame">
<a href="/pricelist/?model={$model.BrandModel.model_id}">
<img src="/img/pricelist/{$model.BrandModel.name}.jpg" alt="{$model.BrandModel.model_id}" />
<b>{$model.BrandModel.model_id}</b>
</a>
</div>
{/foreach}

Je pa to spet odvisno od posameznika ...

sporočilo je spremenil Roky [24.03.2008 ob 21:51]

http://trsplet.com || http://fri.trsplet.com || http://trsplet.com/blog/ .::. blog o spletu ||

ace
član

št. sporočil: 1291

datum: 24.03.2008 | čas: 21:46

Koda:

{$array.vrednost}

vs.

<?php echo $array['vrednost'];?>

Razlog "učenje nove sitankse" je precej IN zadnje čase na razno raznih PHP guru blogih. Obstaja nek smarty cheat sheet na 2 straneh, kjer so vse specifike in sintaktične posebnosti smartya. Mislim, da več kot en dan učenja nebi smelo biti, da nekdo to poštudira. Tako da pomojem je investicija vredna, če le ta za 20-30% zmanjša količino tipkanja templatov, ki so vsaj meni najbolj nadležen in ponavljajoč se del izvedbe web projektov.

Moj edini resni pomislek so možni zapleti, ki se jih sicer vedno da obiti z vključitvijo {php} ampak mislih, da z prakso do teh skoraj ne pride več.
Kar se tiče optimizacije mislim, da ni ravno nek faktor, ki bi pretehtal, saj ima interno keširanje "skompajlanih" templateov.
Razhroščevanja smartya konkretno pa v 4ih letih še nisem rabil početi. Mislim, da je kot produkt dovolj stestiran, da nekih major bugov ne vsebuje, razen seveda v kakšnih eksperimentalnih okoljih.

Nekako sem se odločil, da nekdo pa vseeno mora stopiti na stran Smarty-a v teh zanj tako težkih časih. :)

[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url]

Roky
član

št. sporočil: 518

datum: 24.03.2008 | čas: 21:52

@ace: Smarty ima včasih kake čudne variante pri IIS, drugače je pa na splošno kot si rekel pretestiran produkt.

sporočilo je spremenil Roky [24.03.2008 ob 21:52]

http://trsplet.com || http://fri.trsplet.com || http://trsplet.com/blog/ .::. blog o spletu ||

senzacionale
član

št. sporočil: 1132

datum: 24.03.2008 | čas: 22:21

Hvala Roky to mi niti na pamet ni prislo.

edit:

Samo nekaj kako pa sedaj z smartijem dobim ven te dodatne_informacije.

{$novica.dodatne_informacije.ime} ne deluje ceprav {$novica.dodatne_informacije} vrne da je array

sporočilo je spremenil senzacionale [24.03.2008 ob 22:27]

nisem majster a neki upam da znam:D

fatg
član

št. sporočil: 1693

datum: 25.03.2008 | čas: 00:03

Citiram:

"Razlog "učenje nove sitankse" je precej IN zadnje čase na razno raznih PHP guru blogih. Obstaja nek smarty cheat sheet na 2 straneh, kjer so vse specifike in sintaktične posebnosti smartya. Mislim, da več kot en dan učenja nebi smelo biti, da nekdo to poštudira. Tako da pomojem je investicija vredna, če le ta za 20-30% zmanjša količino tipkanja templatov, ki so vsaj meni najbolj nadležen in ponavljajoč se del izvedbe web projektov."

če povem po pravici, me učenje nove sintakse ne moti zelo. Če se programer ni sposoben naučiti nečesa tako preprostega, mu je treba znižat plačo

. Učenje nove sintakse je bolj problematično pri dizajnerjih, kjer pa je konec koncev čisto vseeno; če se je nekdo sposoben naučiti smartyjeve sintakse, se je sposoben naučiti tudi php-jeve. Med njima ni težavnostne razlike.

No, v preprostih primerih res prišparaš 4 znake pri sintaksi, ampak kakšen je setup-fee, je pa drugo vprašanje. Inicializacija objekta, nastavljanje in predpriprava spremenljivk, to vse pri php templejtingu sploh ni potrebno. Spremenljivke dobiš direktno iz klicev, includaš php in to je to. Kaj profitiraš, če imaš pri Smartyju za 2% čistejši template (pri čemer je "čistost" stvar mnenja), če pa na koncu brez dvoma končaš z več kode overall? Prišpara količino tipkanja v templejtih? Doda pa opazno večjo količino kode v php.

Eden od Smartyjevih problemov je tudi njegova togost. Če hočeš v Smartyju izpisati nek kompleksnejši konstrukt (recimo zanka v zanki, ali pa recimo subqueryje, kot je vidno v dotičnem primeru), moraš telovaditi. Nedolgo nazaj nisi mogel niti chainati metod ($obj->metoda()->metoda()), kar sicer zdaj baje že lahko narediš. Variable assignment? Klicanje vgnezdenih funkcij s parametri? Saj to ni ničemur podobno. Se vidi, da primarno ni bilo mišljeno, da bi smarty kdaj to podpiral in so vgradili samo po potrebi. Veliko stvari dobesedno štrli iz dizajna. Če bi celoten templejting bil samo {$variabla}, potem bi bilo vse ok, ampak kompleksnost templejtinga bo samo naraščala.

Torej, trend gre tja, da bo smarty konec koncev moral podpirati vse osnovne konstrukte, ki jih podpira php. Še vedno bo pa omejen, ker bo namenjen templejtom. Rezultat? Pohabljen PHP z drugačno sintakso. Smartyja sem uporabljal res veliko, tako da poznam vse njegove lastnosti, razen kakšnih novosti. Ni mi žal, da sem ga uporabljal (razen ko kaj popravljam za nazaj), ampak ne bom ga več. :)

Citiram:

"Kar se tiče optimizacije mislim, da ni ravno nek faktor, ki bi pretehtal, saj ima interno keširanje "skompajlanih" templateov."

Optimizacija ni problem, dokler enkrat ne postane. Takrat je pa to pomembno. Keširanje pri smartyju rešuje problem, ki ga brez smartyja sploh nimaš. In ni to edini primer. Bolj splošno rečeno: v smartyju lahko obideš cel kup problemov, ki jih brez smartyja sploh ne bi imel. Meni se tak pristop ne dopade.

Citiram:

"Razhroščevanja smartya konkretno pa v 4ih letih še nisem rabil početi. Mislim, da je kot produkt dovolj stestiran, da nekih major bugov ne vsebuje, razen seveda v kakšnih eksperimentalnih okoljih."

Bolj sem imel v mislih hitre preverbe spremenljivk; print_r, zakaj je neka vrednost null, logging v templejtih, da zveš vrednosti spremenljivk itd. Pač zadeve, ki jih vsak od nas vsake toliko rabi. Da ne rečem, da ti {$x} ne vrže noticea, če $x ni nastavljen. V času razvoja so pomembne take malenkosti, ne pa prišparanje par znakov v tmpl datoteki. Kodo spišeš v malo časa, vzdržuješ in spreminjaš jo pa neprimerno več časa, torej moraš programirati na dolgi rok.

Citiram:

"Nekako sem se odločil, da nekdo pa vseeno mora stopiti na stran Smarty-a v teh zanj tako težkih časih. :)"

devil's advocate, a? :)

Roky: res je odvisno od posameznika. Meni osebno sta oba primera nečitljiva :D. Šalo na stran, res sta nečitljiva na prvi pogled (kot so templejti itak skoraj vedno), ampak ko enkrat zadevo pogledaš in zagrabiš, si pa na istem. Enako hitro bi zadevo popravil, kaj dodal, itd.

V bistvu mi je žal, da smo tole temo hijackali (v glavnem jaz kriv), ampak dobra argumentacija ni izbirčna glede lokacije.

lp

you\'re never too fat to do it

ace
član

št. sporočil: 1291

datum: 25.03.2008 | čas: 07:27

Citiram:

"No, v preprostih primerih res prišparaš 4 znake pri sintaksi, ampak kakšen je setup-fee, je pa drugo vprašanje. Inicializacija objekta, nastavljanje in predpriprava spremenljivk, to vse pri php templejtingu sploh ni potrebno. Spremenljivke dobiš direktno iz klicev, includaš php in to je to. Kaj profitiraš, če imaš pri Smartyju za 2% čistejši template (pri čemer je "čistost" stvar mnenja), če pa na koncu brez dvoma končaš z več kode overall? Prišpara količino tipkanja v templejtih? Doda pa opazno večjo količino kode v php. "

Vse je stvar načina programiranja. Smarty-a vsekakor ne uporabljaš pri preprostih skriptah, ki niti niso del nekega frameworka.
Kjer pa že itak imaš recimo MVC pa vsekakor moraš imeti nek način komunikacije med Viewov im Controlerjem oziroma Modelom, torej vsekakor prenašaš spremenljivke oziroma jih assignaš v php based template. 2% je tudi zelo relativna številka, če mene vprašaš je smary template nepremirljivo preglednješi od phpjevega.

Citiram:

"Eden od Smartyjevih problemov je tudi njegova togost. Če hočeš v Smartyju izpisati nek kompleksnejši konstrukt (recimo zanka v zanki, ali pa recimo subqueryje, kot je vidno v dotičnem primeru), moraš telovaditi. "

Ne rabiš telovaditi sploh, ker je vse to že precej časa del Smartya. {foreach}{foraech}{/foreach}{/foreach}... deluje lepo kot solza in se ne rabiš nič naprezati.

Citiram:

"Variable assignment? Klicanje vgnezdenih funkcij s parametri? Saj to ni ničemur podobno. "

{assign var="variabla" value="nekaj"} (daljše kot php, ni pa problem) , {include file="trenutni_template_file_ki_se_klice_rekurzivno.tpl" level=$level+1}
Včasih je treba tudi malo premislit, če mogoče ni katero od stvari procesirati že level višje (assign).

Citiram:

"Torej, trend gre tja, da bo smarty konec koncev moral podpirati vse osnovne konstrukte, ki jih podpira php. "

Ideja je da logika ostaja v phpju, Smarty je view, torej naj skrbi izključno za generiranje izpisa ob že razdelani logiki. Kakšen IF pa tudi ni ravno problem?

Citiram:

"Optimizacija ni problem, dokler enkrat ne postane. Takrat je pa to pomembno. Keširanje pri smartyju rešuje problem, ki ga brez smartyja sploh nimaš. In ni to edini primer. Bolj splošno rečeno: v smartyju lahko obideš cel kup problemov, ki jih brez smartyja sploh ne bi imel. Meni se tak pristop ne dopade. "

Poanta je v tem, da dokler Smarty "te" probleme uspešno rešuje jih nekako ni oziroma rabiš iskat načine optimizacije na istih mestih kot če imaš php template. V praksi še nikoli nisem prišel do tega, da bi mi template predstavljal šibko točko, ampak je le ta ponavadi vezana na kakšne obsežne podatkovne baze.

Citiram:

"Bolj sem imel v mislih hitre preverbe spremenljivk; print_r, zakaj je neka vrednost null, logging v templejtih, da zveš vrednosti spremenljivk itd. "

Mislim, da je temu namenjena funkcija debug, niti pa ni težko dodatki nek svoj modifier ali svojo funkcijo, ki debugira točno na način kot si sam želiš.

Citiram:

"Pač zadeve, ki jih vsak od nas vsake toliko rabi. Da ne rečem, da ti {$x} ne vrže noticea, če $x ni nastavljen. "

Seveda vrača, samo pravi error reporting je potrebno nastavit. ---> var $error_reporting = null;

Citiram:

"devil's advocate, a? :) "

Bi rekel, da prej obratno. Navržti cel kup ne preverjenih argumentov ni ravno prepričljivo.
Res je, vsak ima svoj pogled, jaz skušam na stvar gledati predvsem iz praktične plati, in ne toliko razmišljati o raznih več ali manj filozofskih pravilnostih.
Če se zadeve na splošno hitreje, bolj pregledno in bolj učinkovito dela z Smarty-em, potem ni kaj razmišljati. :)

sporočilo je spremenil ace [25.03.2008 ob 07:29]

[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url]

ace
član

št. sporočil: 1291

datum: 25.03.2008 | čas: 07:32

Citiram:

"Samo nekaj kako pa sedaj z smartijem dobim ven te dodatne_informacije.

{$novica.dodatne_informacije.ime} ne deluje ceprav {$novica.dodatne_informacije} vrne da je array"

Prvi korak je da se zavedaš kaj sploh assignaš in v kakšni obliki. Tukaj ti noben ne more ugotoviti zakaj se ti nekaj ne izpiše, če izvor variable ni pojasnjen.
Lahko pa poskusiš z kakšno 090 pomočjo.

[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url]

MrM
član

št. sporočil: 2078

datum: 25.03.2008 | čas: 08:22

Koda:

{foreach from=$novice item="novica"}
...
{foreach from=$novica.dodatne_informacije item="dodatno"}
...
{/foreach}
{/foreach}

V debate "Smarty da/ne" pa se zaenkrat še raje ne bom vključeval, saj se mi zdi, da je na eni in na drugi strani nekaj tehtnih argumentov, sam pa se tudi še nisem popolnoma odločil, če bi še naprej delal s Smartyjem ali ne.

God is real, unless declared integer.

fatg
član

št. sporočil: 1693

datum: 25.03.2008 | čas: 09:18

Citiram:

"Vse je stvar načina programiranja. Smarty-a vsekakor ne uporabljaš pri preprostih skriptah, ki niti niso del nekega frameworka.
Kjer pa že itak imaš recimo MVC pa vsekakor moraš imeti nek način komunikacije med Viewov im Controlerjem oziroma Modelom, torej vsekakor prenašaš spremenljivke oziroma jih assignaš v php based template. 2% je tudi zelo relativna številka, če mene vprašaš je smary template nepremirljivo preglednješi od phpjevega."

V phpju je prenos spremenljivk lahko precej bolj enostaven; itak že maš v lokalnem scope-u. Če narediš recimo include, jih imaš na voljo v templejtu. Lahko pa bolj zakompliciraš. Šele če se res potrudiš, dobiš toliko kode, kot pri smartyju. O preglednosti pa ni izgubljati besed, ker je popolnoma stvar okusa. In meni osebno je enostavnejša smartyjeva sintaksa všeč, ko pa začneš komplicirati, rata pa bolj nepregledno od php-ja. Na primer klici parametriziranih vgnezdenih funkcij (oz. modifierjev).

Citiram:

"Ne rabiš telovaditi sploh, ker je vse to že precej časa del Smartya. {foreach}{foraech}{/foreach}{/foreach}... deluje lepo kot solza in se ne rabiš nič naprezati.
{assign var="variabla" value="nekaj"} (daljše kot php, ni pa problem) , {include file="trenutni_template_file_ki_se_klice_rekurzivno.tpl" level=$level+1}"

Foreach sam po sebi ni problem. Problem je, da moraš podatke za vsako zadevo ustrezno predpripraviti. In mislim, da si zgrešil z includom: prvič je to pač spet alias za php, kar podpira moje argumente, da bo smarty prej ali slej samo omejen php z drugo sintakso, drugič pa sem imel v mislih klic vgnezdenih funkcij z argumenti. Funkcij, ki jim smarty reče modifierji. Recimo razni parametrizirani string formatterji, htmlentities itd. Vse to se da, ampak output je pa grozen. In ja, lahko bi to predpripravo izvedel v php-ju, ampak to že krivi pravila -- formatiranje in escapanje podatkov se mora načeloma izvajati v View layerju.

Citiram:

"Včasih je treba tudi malo premislit, če mogoče ni katero od stvari procesirati že level višje (assign)."

Ker to premišljanje rešuje samo problem togosti smartyja, je to spet odveč in rešuje problem, ki ga brez smartyja nimaš. Programer mora razmišljati, v kateri layer neka koda spada, ne pa v kateri layer bo on dal kodo, da ne bo programiranje templejta komplicirano. Če nekaj spada v View layer, mora tam tudi biti. To seveda ni tako strogo, ampak princip pa je.

Citiram:

"Ideja je da logika ostaja v phpju, Smarty je view, torej naj skrbi izključno za generiranje izpisa ob že razdelani logiki. Kakšen IF pa tudi ni ravno problem?"

No, to je šibka točka. Zakaj ne bi imel logike tudi v View layerju? Nisem še slišal za pravilo, da View ne sme imeti logike. Se pa strinjam, da ne sme imeti poslovne logike in da ne sme spreminjati podatkov. Če pa imaš view logiko, potem pa po MVC vodilu tega ne smeš delati v Controller layerju, temveč v Viewu. Kot že omenjeni primer, če formatiraš števila, moraš to početi v templejtu, čeprav je res "moraš" nekoliko stroga beseda. In View layer je lahko zelo zelo kompliciran. Ti obljubim, vzdržujem eno veliko intranet aplikacijo z zelo zapletenimi viewi, ki je spisana polovico v smartyju, drugo polovico (novejšo) pa v php templateih. Neprimerno lepši pogled.

Citiram:

"Seveda vrača, samo pravi error reporting je potrebno nastavit. ---> var $error_reporting = null;"

A je ta vrednost v sinhronizaciji s php-jevim error_reporting()? Če je, potem ok, če pa ni, potem pa je še ena stvar odveč, za kar moraš pri incializaciji skrbeti.

Citiram:

"Navržti cel kup ne preverjenih argumentov ni ravno prepričljivo.
Res je, vsak ima svoj pogled, jaz skušam na stvar gledati predvsem iz praktične plati, in ne toliko razmišljati o raznih več ali manj filozofskih pravilnostih.
Če se zadeve na splošno hitreje, bolj pregledno in bolj učinkovito dela z Smarty-em, potem ni kaj razmišljati. :)"

Ne vem, zakaj se ti moji argumenti zdijo nepreverjeni. Mogoče so malo zastarani, ker ne sledim spremembam v Smartyju. Ampak mislim, da to sploh ni pomembno, ker vse kar Smarty trenutno počne, je to, da poskuša na vsak način zagotoviti fleksibilnost in moč php-ja skozi ne-php sintakso. Moj glavni argument je ta, da smarty hitro izgublja moč, ko narašča zapletenost templejtov. Mogoče se lahko komu zdi ti brezvezen argument, ker je zapletenejših viewov manj kot enostavnih. Večinoma je to res, ampak finta leži v tem, da je pri enostavnih viewih vseeno, s čim jih delaš, ker so itak enostavni, pri zapletenejših pa je pomembna kompleksnost. Če moraš za uporabo smartyja določene stvari premikati v Controller, določene pa reševati z gimnastiko znotraj templejta, potem dobiš en nepregleden kos špeha. Enostavno ni vredno.

Prav tako mislim, da ene stvari niso stvar pogleda. Če obstaja neka optimalna pot, potem je to edina optimalna pot. Če imaš s smartyjem (kot trdim jaz) na koncu skupaj več kode, potem ni nič hitreje in bolj učinkovito. Mogoče se preveč osredotočaš samo na template in pozabljaš, da moraš za smarty template imeti en kos kode v php-ju samo za predpripravo. Ta kos kode mora nekdo spisati. Za foro sprobaj en malo bolj zapleten kos aplikacije, ki ga imaš v smartyju, spisati v php. Premakni view-logiko lepo v template. Mogoče boš presenečen, jaz sem vsekakor bil.

lp

you\'re never too fat to do it

ace
član

št. sporočil: 1291

datum: 25.03.2008 | čas: 10:32

fatg> torej se strinjava. :)

Sočasno delam na projektih kjer nekje uporabljam smarty in nekje ne in zaradi sledečih razlogov preferiram prve:
- boljša preglednost
- php brez htmljev in sestavljanja outputov
- urejanje kode v html načinu
- manj tipkanja

še par citatov:

Citiram:

" V phpju je prenos spremenljivk lahko precej bolj enostaven; itak že maš v lokalnem scope-u. Če narediš recimo include, jih imaš na voljo v templejtu "

pri objektnem programiranju bolj težko rešuješ to z includei ampak rabiš vseeno spremenljivke redefinirati tudi na globalni ravni.

Citiram:

"Foreach sam po sebi ni problem. Problem je, da moraš podatke za vsako zadevo ustrezno predpripraviti."

Predpripraviš jih na identičen način, kot bi jih za svoj php template. Ali je to nek array ali pa objekt preko katerega se sprehajaš ob izpisu.

Citiram:

"Recimo razni parametrizirani string formatterji, htmlentities itd. Vse to se da, ampak output je pa grozen."

Za takšne primere vedno pomaga, če si predhodno pripraviš okolje saj ponavadi vedno rabiš iste stvari večkrat, iste kombinacije escapenja itd,
tako da si jih pač zapakiraš pod svoje custom lične funkcije npr: {$podatek|escapaj_vse_mogoce} Pač ideja je v tem, da se ne omejiš z tem kar dobiš po defaultu,
ampak si okolje prilagodiš za svoje potrebe (v tem primeru dodaš kakšen svoj custom modifier ali funkcijo, ki jo potem vedno uporabljaš)

Citiram:

"No, to je šibka točka. Zakaj ne bi imel logike tudi v View layerju? "

Jap mislil sem poslovno logiko, zato je tudi omenjen IF, ki naj nebi bil preveč problematičen v samih templateih.

Citiram:

"A je ta vrednost v sinhronizaciji s php-jevim error_reporting()? Če je, potem ok, če pa ni, potem pa je še ena stvar odveč, za kar moraš pri incializaciji skrbeti. "

To nebi vedel v vsakem primeru je pa to ena vrstica kode, ki je dodaš v svoj Smarty layer in zadeva vedno deluje tako kot si želiš.

Citiram:

"Če imaš s smartyjem (kot trdim jaz) na koncu skupaj več kode, potem ni nič hitreje in bolj učinkovito. Mogoče se preveč osredotočaš samo na template in pozabljaš, da moraš za smarty template imeti en kos kode v php-ju samo za predpripravo. "

Seveda ne pozabljam, samo upoštevam zgoraj omenjena dejstva da rabiš podatke predpripraviti tudi za php template.

sporočilo je spremenil ace [25.03.2008 ob 10:33]

[url=http://www.mp3.com.au/acecream]KLIK KLIK KLIK KLIK...[/url]

vuego
član

št. sporočil: 666

datum: 25.03.2008 | čas: 11:41

Se vključujem v debato...

tole ni res:

Citiram:

" pri objektnem programiranju bolj težko rešuješ to z includei ampak rabiš vseeno spremenljivke redefinirati tudi na globalni ravni. "

ampak se rešuje z ustreznim zajemanjem outputa (imaš data v lokalnem scopu view singletona, narediš ob start, includaš php tpl in zajameš output).

Na tak princip ima to urejeno tudi cakephp - ni template sistema, tpl (ctp) includi so v bistvu php datoteke. Variable se pa v tpl podaja s set() funkcijo view-a, s čimer se kontrolira tudi dostopnost varov znotraj templata.

Po letih php programiranja in uporabi parih različnih tpl sistemov (smarty, itx, powertemplate) se mi zdi ta pristop daleč najelegantnejši in najbolj učinkovit. Ter brez nepotrebnega balasta.

Pridem takoj. Godot