ugrás a tartalomhoz

Design: templates and template engines

tiku I tikaszvince · 2006. Júl. 25. (K), 12.56
Érvek a template kezelő könyvtárak ellen. Vissza a gyökerekhez?
 ■
1

háát

Anonymous · 2006. Júl. 25. (K), 16.33
Szerintem ezt azért nem gondolta át teljesen. Egy kicsit egyoldalúan nézi a dolgot.

-- hector
2

de

__Ferus · 2006. Júl. 27. (Cs), 12.48
Szerintem meg igaza van és persze hogy egyoldalú :)
3

Végre...

vbence · 2006. Júl. 27. (Cs), 14.54
...valaki észreveszi :) Ezek szerint nem csak nekem furcsák az a dolgok.
4

hitvita?

tiku I tikaszvince · 2006. Júl. 27. (Cs), 15.20
Az a baj, hogy nem is hajlandó elfogadni ezeknek a rendszereknek a létjogosultságát. Plusz: azokat a megállpításokat, melyek a smartyra igazak, és elfogadható érvek, általánosítja az összes többi sablonozóra.

Abban maximálisan egyetértek vele, hogy a smarty létrehozott egy új script nyelvet, aminek az értelmezőjét PHP-ban írták meg. Ennek én sem látom sok értelmét.
5

hitvita.

Bártházi András · 2006. Júl. 27. (Cs), 17.16
De nem úgy hitvita. Egyszerűen van amikor template rendszert *kell* használni, máskor pedig tök felesleges. Azt kell tudni felismerni, hogy mikor melyik a helyzet.

A Smarty-féle kijelentés legalább részben nem igaz. Smarty-val sokkal hatékonyabban lehet leírni szerkezeteket, sokkal hatékonyabb célnyelv tud lenni a feladatra, és a végeredmény is átláthatóbb tud lenni. Ezen kívül jogosultságokról is szó lehet, ha valaki csak a Smarty sablonokhoz fér hozzá, akkor sokkal kevesebbet tud a rendszerrel tenni, mint ha PHP-vel sablonozna. Ugye a végeredmény pedig hatékonyság szempontjából a Smarty használata esetén tök ugyanaz lesz, mintha PHP-ben írtuk volna - tehát hatékonyság szempontjából mindegy.
8

nem teljesen

Hodicska Gergely · 2006. Júl. 27. (Cs), 23.23
Egyszerűen van amikor template rendszert *kell* használni, máskor pedig tök felesleges.

A cikk ugye nem erről szól, hanem szerinte ha már használunk template kezelőt, akkor nem érdemes erre a célra egy új nyelvezetet bevezetni, főleg, ha ez némileg a teljesítmény róvására is megy.

Azt kell tudni felismerni, hogy mikor melyik a helyzet.

Ha feltesszük, hogy webes alkalmazásokról beszélünk (felejtsük el a script farigcsálást), akkor SZVSZ minden esetben érdemes valamilyen szinten a megjelenítési réteget különválasztani, különben egy nehezen módosítható, rugalmatlan kódot kapunk. Az meg ugye nagyjából sosem igaz, hogy amit épp csinálunk, ahhoz nem kell majd hozzányúlni soha, még a legegyszerűbb rendszerek esetében sem.

Smarty-val sokkal hatékonyabban lehet leírni szerkezeteket, sokkal hatékonyabb célnyelv tud lenni a feladatra, és a végeredmény is átláthatóbb tud lenni.

Ez szerintem eléggé szubjektív dolog. Számomra is tetszetősebb a smarty template, de van akinek meg ugyanúgy kézre áll a HTML-be ágyazott PHP, sőt van aki szerint meg az XML/XSLT páros az üdvözítő, pedig aki nem találkozott még ezzel, annak valszeg fel áll a hátán a sző egy ilyentől.

Ezen kívül jogosultságokról is szó lehet, ha valaki csak a Smarty sablonokhoz fér hozzá, akkor sokkal kevesebbet tud a rendszerrel tenni, mint ha PHP-vel sablonozna.

Szerintem ez a kulcs. Egyrészt olyan szempontból, hogy megakadályozzuk, hogy a sitebuilder esetlegesen odacsúnyázzon, plusz egy grafikus beállítottságú embernek könnyebben emészthető a smarty vagy hasonló szintaktika, mint a PHP.

Ugye a végeredmény pedig hatékonyság szempontjából a Smarty használata esetén tök ugyanaz lesz, mintha PHP-ben írtuk volna - tehát hatékonyság szempontjából mindegy.

Ez mondjuk többszörösen nem igaz. Ha belenézel egy smarty lefordított templatebe, akkor az azért némileg zsúfoltabb, mint amit kézzel csinálnál, de ez mondjuk nagyjából minden generált kódra igaz lehet. Másodsorban a smarty includolásával elég sok kódot behúzunk a rendszerbe, amit alap esetben (sokszor nincs opcode cache) parse-olni kell, futnia kell.

Alapvetően viszont nem értek egyet a szerzővel (pedig amúgy csípem nagyon :)), szerintem ha valami komolyabb terhelés nem indokolja, akkor nyugodyan lehet valami template rendszer, mondjuk smarty :), ha pedig ez már esetleg túl "drága" lenne, akkor lehet egyebekben gondolkodni, de még akkor is sok olyan eset lehetséges, amikor kár lemondani a kényelemről, és valamilyen szintű kimenet cacheléssel kint vagyunk a vízből.


Felhő
10

Szerintem

Bártházi András · 2006. Júl. 28. (P), 12.25
akkor SZVSZ minden esetben érdemes valamilyen szinten a megjelenítési réteget különválasztani


Szerintem pedig van, amikor nem. A "Hello World!" bonyolultságú oldalaknál (három-négy oldalból áll, nem túl sok logikát tartalmaz, a design várhatóan nem fog változni) én feleslegesnek tartom. Például a http://web.zin.hu mögött sincs template, mert még ha meg is kell majd változtatni a designt, akkor sem lesz túl nagy feladat, hiszen gyakorlatilag másfél oldalról van szó.

Egy Smarty template lehet, hogy zsúfoltabb, de a PHP sebességénél sohasem volt szempont, hogy sebességoptimalizálás címén három utasításból csináljak egyet, mert akkor gyorsabb lesz.

Most ennyi fért bele a válaszadásba. :)
13

Re: Szerintem

Hodicska Gergely · 2006. Júl. 28. (P), 21.18
A "Hello World!" bonyolultságú oldalaknál

Pont azzal kezdtem, hogy ezeket zárjuk ki. ;)

Egy Smarty template lehet, hogy zsúfoltabb, de a PHP sebességénél sohasem volt szempont, hogy sebességoptimalizálás címén három utasításból csináljak egyet, mert akkor gyorsabb lesz.

Először is nem pont ezt írtad, és én arra reagáltam, másrészt pedig igenis számíthat terhelés szempontjából, hogy ott figyel-e egy smarty vagy sem. Nem véletlenül lett a smartylite sem.


Felhő
6

Simple templates

janoszen · 2006. Júl. 27. (Cs), 18.12
Winstonnal vitáztunk privbe egy sort a template rendszerekről. Végül is oda lyukadtunk ki, hogy az egész oldalt nem szívesen csinálnánk meg template rendszerben, mert túl komplex és átláthatatlan lenne, azonban egy-két helyen, mint pl. a regisztráció aktivációs e-mail-jében elkerülhetetlen. De ilyenkor egyszerű templatezést használunk, azaz search-replace módszerrel dolgozunk.
7

Miért?

vbence · 2006. Júl. 27. (Cs), 18.28
Miért nem jó az echo vagy az eval vagy az ob?
9

miért?

Hodicska Gergely · 2006. Júl. 27. (Cs), 23.26
az egész oldalt nem szívesen csinálnánk meg template rendszerben, mert túl komplex és átláthatatlan lenne

Mi az, ami miatt nem lehetne erre a célra template kezelőt használni?

azonban egy-két helyen, mint pl. a regisztráció aktivációs e-mail-jében elkerülhetetlen

Pont itt elkerülhetetlen, hiszen itt tényleg csak az eméített cserékről van szó, simán állhatnának a placeholderek helyén maguk a változók is.


Felhő
11

butaság

Anonymous · 2006. Júl. 28. (P), 14.00
Szerintem a sablonkezelők hasznát nem érdemes vitatni. A legtöbb esetben elég a változó alapján elágazás és a tömb ciklikus bejárása, ennél bonyolultabb kód a sablonba nem kell, mert áttehető a PHP kódba, azaz a sablon már csak egyszerű értékeket, tömböket, és logikai igaz/hamis feltételeket kap. Ha távol tartjuk magunkat a sablon oldali bonyolult logikai kifejezésektől, szrting-boncolásoktól, matematikai műveletektől, a sablon egyszerű és áttekinthető marad.

Egy sablonkezelő fő előnye pedig épp az egyszerű és áttekinthető kód (nem véltelenül nem XML-kompatibilisek), pl. smartynál a modifierek sokkal tömörebb leírást tesznek lehetővé, mintha egymásba ágyazott PHP függvényhívásokat kéne írnom. Szintén egyszerűsít pl. Smartynál az egyszerű delimiter, a szabványos <?php ?> helyett. Valóban helyettesíthető lehet a sablonkezelő php-val, de jóval csúnyább módon.
12

hehe

Marcell · 2006. Júl. 28. (P), 14.34
Ha már sablonok, itt egy TPL: http://etniesgirl.com/templates/header.tpl. Jó, nem? :)