PHP - mint sablonrendszer
Brian Lozier a bTemplate szerzője helyzetéhez képest meglepő látásmódú cikkel lepte meg az érdeklődőket a Sitepoint oldalon. A bTemplate oldalán az áll, hogy az lehetővé teszi a PHP kód és a megjelenítéshez használt leíró nyelv elválasztását. Most azonban Brian azt írja, hogy a sablonnyelvek az üzleti logika és a megjelenítési logika elválasztására kell hogy szolgáljanak, és nem a PHP kód és a leíró nyelv kettéválasztására.
Ezutóbbi kijelentése nagyonis igaz, azonban az a kérdés, hogy mennyire radikális az értelmezés. Brian a végletekig elmenve a kérdésben ezzel egyszersmind azon "megtértek" táborához csatlakozik, akik úgy gondolják hogy a PHP nyelven készített sablonkezelők felesleges terhelést tesznek a grafikus tervezők és a webfejlesztők vállára, mivel új nyelvet kell megtanulni, plusz kódot kell a programba építeni, lassab futásidőre lehet számítani. Brian szerint tehát a PHP-t annak eleve sablon nyelvnek tervezett formájában érdemes használni a prezentáció és az üzleti logika szétválasztására.
Cikkében bemutat egy egyszerű sablonkezelő osztályt, mely változók beállításán kívül nem sokat kell tegyen, hiszen a sablon kód PHP-ben íródik, így minden PHP funkció használható a sablonokban is. Véleményem szerint a változó beállítás is teljesen felesleges a kódban (elegendő lenne a sablon megjelenítésekor átvenni a változókat), bár valószínűleg az adat-művelet összezártság erőltetése miatt került be mégis.
A cikk megmutatja, hogy egy ilyen módon készített sablon kimenetét ugyanúgy lehet gyorsítótárazni (cache-elni), mint a Smarty kimenetet, vagy bármely más ezt támogató sablon kimenetét. Komoly előnyként a szerző kiemeli, hogy az így készített sablonok a PHP kód gyorsítótárakkal (Zend Performance Suite, PHP Accelerator, Advanced PHP Cache) rendkívül optimális környezetben futtathatóak. Brian arről azonban nem tesz említést, hogy ugyanez a PHP-ba fordító sablonkezelőkre is igaz.
Ennek a sablon megközelítésnek a hátrányaként azt említi, hogy kifejezett betörési szándékkal érkező sablonok okozhatnak problémát, de a saját grafikus tervező partnereinkben meg kell bíznunk, így gond nem lehet. Arról úgy tűnik megfeledkezik, hogy ha a sablon készítője PHP-ben vét hibát, az sokkal komolyabb következményekkel járhat a web-alkalmazás működésére, mint ha egy hibatűrő feldolgozóval elemzett sablonnyelv elemei között lenne hiba. Elvégre is ez volt az egyik komoly motiváció a ma használatos számos sablonrendszer kifejlesztése mögött...
Ehhez a hírhez kapcsolódik aktuális szavazásunk is.
■ Ezutóbbi kijelentése nagyonis igaz, azonban az a kérdés, hogy mennyire radikális az értelmezés. Brian a végletekig elmenve a kérdésben ezzel egyszersmind azon "megtértek" táborához csatlakozik, akik úgy gondolják hogy a PHP nyelven készített sablonkezelők felesleges terhelést tesznek a grafikus tervezők és a webfejlesztők vállára, mivel új nyelvet kell megtanulni, plusz kódot kell a programba építeni, lassab futásidőre lehet számítani. Brian szerint tehát a PHP-t annak eleve sablon nyelvnek tervezett formájában érdemes használni a prezentáció és az üzleti logika szétválasztására.
Cikkében bemutat egy egyszerű sablonkezelő osztályt, mely változók beállításán kívül nem sokat kell tegyen, hiszen a sablon kód PHP-ben íródik, így minden PHP funkció használható a sablonokban is. Véleményem szerint a változó beállítás is teljesen felesleges a kódban (elegendő lenne a sablon megjelenítésekor átvenni a változókat), bár valószínűleg az adat-művelet összezártság erőltetése miatt került be mégis.
A cikk megmutatja, hogy egy ilyen módon készített sablon kimenetét ugyanúgy lehet gyorsítótárazni (cache-elni), mint a Smarty kimenetet, vagy bármely más ezt támogató sablon kimenetét. Komoly előnyként a szerző kiemeli, hogy az így készített sablonok a PHP kód gyorsítótárakkal (Zend Performance Suite, PHP Accelerator, Advanced PHP Cache) rendkívül optimális környezetben futtathatóak. Brian arről azonban nem tesz említést, hogy ugyanez a PHP-ba fordító sablonkezelőkre is igaz.
Ennek a sablon megközelítésnek a hátrányaként azt említi, hogy kifejezett betörési szándékkal érkező sablonok okozhatnak problémát, de a saját grafikus tervező partnereinkben meg kell bíznunk, így gond nem lehet. Arról úgy tűnik megfeledkezik, hogy ha a sablon készítője PHP-ben vét hibát, az sokkal komolyabb következményekkel járhat a web-alkalmazás működésére, mint ha egy hibatűrő feldolgozóval elemzett sablonnyelv elemei között lenne hiba. Elvégre is ez volt az egyik komoly motiváció a ma használatos számos sablonrendszer kifejlesztése mögött...
Ehhez a hírhez kapcsolódik aktuális szavazásunk is.
Re: PHP - mint sablonrendszer
sose láttam különösebb hasznosságukat.
inkább "csak" a designoló emberek életét könnyítheti meg.
írtam saját portálrendszert, amiben van egy template nevű "modul": áll összesen egy függvényből (template), mely csinál egy preg_replacé()t a paraméterben átadott stringre...
még amit fontosnak ítéltem az a feltételes utasítás, de én több dolgokat nem is várnék egy template rendszertől:
egyszerűbbnek tűnik megírni PHPban...
Re: PHP - mint sablonrendszer
Re: PHP - mint sablonrendszer