Lo sviluppo web moderno prevede un uso solo marginale di codice HTML statico. Eppure l’output di una applicazione web è principalmente di questo tipo. Che sia pyton, perl, php, ruby o qualsiasi altro linguaggio server side, il risultato che vogliamo ottenere nella maggior parte dei casi è codice html da visualizzare via browser.
Quello che vediamo in ultimo è il risultato di un processo complesso di aggregazione di dati, calcolo di variabili, manipolazioni di stringhe… A monte quindi c’è qualcosa di estremamente diverso. Una serie di processi sistemici che permettono di raggiungere l’obiettivo finale.
Proprio perchè si parla di processi sistemici, è evidente la possibilità di vedere la creazione di una pagina web in termini di "ciclo di vita".
Si parte dalla richiesta del client remoto. Questa avrà dei parametri che l’applicazione andrà ad elaborare. Una volta ottenuti tutti i dati necessari è possibile produrre l’output desiderato. Oggi parliamo proprio dell’ultima fase e di quanto sia conveniente delegare un processo proprio alla creazione del risultato finale.
Template Engine
Sta in questo il template engine. Bella definizione con cui si vuole sintetizzare l’attitudine di un’applicativo web a creare output visuale in modalità indipendente dai processi di acquisizione ed elaborazione della richiesta remota.
E’ un po’ quello che succede in questo blog, ma anche in wordpress, joomla e la quasi toalità dei content management system open source in circolazione. La gestione del template è completamente separata ed indipendente dal resto del sistema. Il template engine viene usato dal core code dell’applicazione come uno dei tanti strumenti di elaborazione dati. Nel caso specifico un processo di finalizzazione.
Come agire in concreto
Le modalità operative di implementazione di un sistema di template engine partono da un presupposto di progettazione abbastanza preciso: l’applicativo che si vuole realizzare deve essere visto come una serie di processi indipendenti e collegati fra loro in modalità sussidiare ad un motore centrale.
Questo permette non solo di creare un buon concept dell’applicazione, ma anche di rendere portabile le varie fasi in altri progetti. In una logica ampia la progettualità di un’applicazione web che vede le seguenti fasi:
- Ricezione richiesta remota.
- Elaborazione della richiesta.
- Rilascio dei dati risultanti dall’elaborazione.
- Rappresentazione grafica tramite template.
L’ultima fase è quella che si relazione con l’utente finale. Il front office dell’applicazione web si occupa di consegnare il pacco al cliente. Ma penseranno i processi di produzione ad elaborare la richiesta e preparare il tutto per il fiocco finale.
Template strutturali e funzionali
Si può affermare che ogni template engine sia un sistema strutturale. Avrà i suoi processi interni di gestione ed interfacciamento con il core code. In una logica di separazione delle fasi di processo, riuscirà ad adattarsi al sistema che deve servire mantenendo un’alta scalabilità in termini di facile implementazione di interfaccia.
La funzionalità del template engine è invece una scelta più radicale. Si può decidere infatti che il templating sia atto solo a visualizzare, nel formato adatto, il risultato della richiesta cliente. In altri casi si può anche decidere di destinare al template parte dell’elaborazione, passando a questo dati a livello più grezzo.
Non esiste una scelta migliore e molto dipende dalle modalità di rilascio dell’applicativo. Un esempio di template engine strutturale e poco funzionale è Smarty. Tramite l’utilizzo di file .tpl ed un interfacciamento semplice, riesce a gestire le risultanze passategli da un sistema complesso. Sconta, come ogni altro sistema del genere, la necessità di implementazione nel core code di nuove funzionalità anche per modifiche banali. Si presta però molto bene ad essere incluso in software proprietari a rilascio privato. In questo caso le personalizzazioni e le modifiche successive trovano logica in una modifica diretta del motore centrale dell’applicativo. Mentre il front end può essere gestito facilmente da personale che abbia grandi conoscenze di styling puro, senza bisogno di competenze a livello di scripting.
Per i software a rilascio pubblico e diffuso invece, si consiglia l’utilizzo di un template engine funzionale. Meglio se scritto nello stesso linguaggio di programmazione usato dal motore principale.
L’esempio banale è wodpress. Il sistema di template è scritto in PHP. I file di template sono scritti in PHP. Lo stesso motore centrale fornisce numerose api per implementare nuove funzionalità all’interno del visuale utente. Perchè questo? WordPress è un software open source, a rilascio diffuso e frequente. Nuove funzionalità che non prevedono scrittura nel database possono essere inserite direttamente nel template. In questo modo, insieme al sistema di plugin, si riesce a non toccare mai il cuore dell’applicazione, potendo procedere ad aggiornamenti di struttura in maniera indipendente e quindi sostenibile.
Solo HTML?
Lo stesso principio con cui strutturiamo il template engine per la produzione di output HTML può essere utilizzato per qualsiasi tipo di output. Ipotizziamo di dover rilasciare un’immagine jpeg con un testo arbitrario. Probabilmente avremo un processo per selezionare l’immagine di sfondo. Un altro proceso si occuperà di processare la stringa da scrivere sull’immagine stessa. Se tale funzione è ripetitiva risulta più economico creare un file di template unico che si occuperà di mostrare il risultato, piuttosto che far produrre il jpeg al codice operativo. Stesso discorso per file XML, PDF, CVS e altro.
Tutte queste sono nozioni di base e del tutto teoriche. Nessun esempio di codice è inserito proprio perchè l’intento è quello di mostrare una logica progettuale efficace ed efficiente. Per le modalità operative, buon lavoro 🙂