Con questo articolo voglio spiegarti perchè non amo i Template Engine, perchè non li utilizzo e non li utilizzerò. Ma partiamo dall’inizio che sembra la cosa più giusta da fare 😀
Cos’è un Template Engine e a cosa serve?
Un Template Engine è un insieme di librerie e/o codici che permette di separare il contenuto dalla presentazione in un applicazione web. Il Template Engine più famoso e utilizzato è probabilmente Smarty.
Separare il contenuto (codice, dati ecc.) dalla presentazione (layout, html, css) è sicuramente un approccio da adottare in quanto agevola il lavoro delle diverse figure professionali che collaborano per lo sviluppo di un’applicazione (il web developer e il web designer), che possono lavorare separatamente senza dover dipendere l’uno dall’altro. Come riporta l’articolo di php.html.it linkato all’inizio del post:
“il programmatore si preoccupa solamente di reperire i dati, operarvi le modifiche necessarie e renderli disponibili; il designer si occupa di creare le presentazioni inserendo al posto dei dati effettivi dei marcatori speciali; il template engine fonde i due aspetti: prende i dati forniti dalla parte applicativa, e li inserisce al posto dei marcatori prestabiliti.“
Bene, tutto molto utile. Ma allora perchè non ami i Template Engine?
Per uno motivo molto semplice: li reputo un “layer” inutile, superfluo.
Molti sono soliti associare il concetto di separazione del contenuto dalla presentazione all’adozione di un Template Engine. Ma, in realtà, si può tranquillamente separare il contenuto dalla presentazione facendo benissimamente a meno di un Template Engine. Ecco perchè è inutile. Sicuramente, gli utilizzatori incalliti di Template Engine, mi avranno insultato dopo aver letto queste mie parole… machissenefrega 😛
Un Template Engine non eguaglia le performance del codice PHP nativo in quanto, il codice del Template Engine, dovrà essere riconvertito in codice nativo al momento dell’esecuzione. Poi, da un punto di vista sintattico, il designer non è che sia particolarmente agevolato, vediamo in questo esempio:
Codice nativo
Codice Template Engine
-
{foreach from=$users item=item}
- {$item} {/foreach}
Ecco, fornire al designer una funzione/API (o chiamiamola come preferiamo) di questo genere, può essere una soluzione senza dubbio comoda per lui…ed è anche in codice nativo:
Per una soluzione più “potente” si può ricorrere all’ottimo Plates.
In sostanza, per separare il contenuto dalla presentazione, la differenza la fa la fase di analisi e progettazione…non l’adozione o la non adozione di un Template Engine. Scegliere un buon Framework PHP che adotta il Pattern MVC è un ottimo punto di partenza e, sembra banale ma non lo è, massima collaborazione e intesa tra Developers e Designers sono sufficienti…con la speranza che non vi imbattiate in uno di questi ambigui personaggi 🙂
Condivido in parte buona parte ciò che dici.
La soluzione che preferisco è quella di utilizzare all’interno delle view codice nativo.
Oramai anche i designer hanno imparato a familiarizzare con la sintassi base di php, basti pensare ai temi per wordpress.
Fornire al designer una funzione di output() personalmente non la preferisco come soluzione. Nel tuo esempio se il designer vuole attribuire una classe agli elementi li (o altra personalizzazione del markup) non potrà farlo.
I template engine come smarty hanno una loro sintassi, ed è questo a me non piace.
Tuttavia, bisogna fare una ulteriore considerazione: lo scopo dei template engine come Smarty non è solo quello di separare la logica dalla presentazione ma anche quella di sfruttare un sistema di caching.
A conti fatti, salvo se si tratta di un piccolo sito poco frequentato, la soluzione che preferisco è quella di utilizzare un framework (io utilizzo codeigniter) dove le funzioni per gestire la cache sono integrate.
Preciso che la funzione “output” che ho suggerito è soltanto un semplice esempio assolutamente generico.
E’ ovvio che le functions/API dovranno essere ben caratterizzate e la possibilità di aggiungere classi (o altro) si può prevedere come parametro delle funzioni.
Per tutte le features più importanti, come hai ricordato tu, dal sistema di caching, all’autenticazione utenti passando per internazionalizzazione ecc. E’ cosa buona e giusta, come ho anche segnalato nel post, utilizzare un buon framework PHP 🙂
Ciao,
io sono PRO template engine, probabilmente perchè ho quasi sempre avuto che fare con tanti “personaggi ambigui” differenti… Il discorso delle performance è facilmente trascurabile grazie a sistemi di caching come apc e smarty ad esempio può utilizzarlo tranquillamente azzerando (quasi completamente) il gap con le funzioni php native. Inoltre un template engine migliora secondo me anche la sicurezza dell’applicazione, in quanto si può limitare l’utilizzo di determinate funzioni e/o variabili, impedendo di fatto al “personaggio ambiguo” di turno di fare danni… Concordo comunque sul fatto che se si ha la possibilità di lavorare con professionisti, un template engine non è necessario… Avendo lavorato principalmente con figure poco skillate, il template engine è sempre stato un’obbligo e mai una scelta. Chissà che in futuro non vada meglio 🙂
Ciao Andrea,
alla fine concordi con me sul fatto che il template engine non è necessario…è proprio questa la realtà, non è necessario.
Sul discorso delle performance, della sicurezza ecc., come già detto anche nel post, tutto dipende dalla fase di analisi e progettazione…dalla scelta del pattern architetturale, dalla qualità del codice scritto, dalla massima collaborazione tra developers e designers.
E anche separare il contenuto dalla presentazione non può che dipendere da questo, da un buon lavoro di progettazione/esecuzione che lo preveda 🙂
Ciao,
sono dell’opinione che se si programma con attenzione e con cura i… “Template Engine” sono assolutamente innecessari; si può perfettamente fare in modo che nei file di visualizzazione o comunque quelli riservati solo al codice HTML, vengano passate variabili ottimizzate in modo che l’unica funzione di php da utilizzare sia echo. E penso che anche i più inesperti sappiano che significa echo, altrimenti farebbero prima a cambiare mestiere.
@roilld eh eh, siamo d’accordo 🙂