Template engine: nozioni e linee guida
La tecnica del template engine consiste nello slegamento della parte tecnico-applicativa di un progetto dal suo template grafico, per facilitare ogni tipo di aggiornamento alle figure preposte nello sviluppo e nella realizzazione. Sebbene sia una pratica adottata soprattutto quando si lavora in gruppo, è decisamente preferibile attuarla in qualsiasi progetto e in qualsiasi modalità di lavoro, dal semplice sito vetrina al più complesso gestionale o e-commerce e lavorando da soli o in un team composto da varie figure.
È una tecnica multiforme estremamente difficile da riassumere in un solo articolo ma tenterò comunque di fornire delle brevi spiegazioni e delle linee guida per il suo chiarimento e il suo utilizzo.
Quando si lavora in team composti da più sviluppatori, copywriter e web designer, può capitare che il copywriter e il web designer non abbiano alcuna competenza tecnica e si renda necessario adottare un metodo di sviluppo sicuramente più lungo e complesso ma che renda possibile alle altre figure qualsiasi aggiornamento/intervento indipendente. Se ad esempio al web designer viene richiesta la variazione dei colori o lo spostamento di porzioni di codice mark-up altrove o se il copywriter, in assenza di un pannello di controllo, viene incaricato dell'aggiornamento del testo, è assolutamente necessario e buona norma che possano farlo autonomamente senza chiamare in causa le altre figure di riferimento.
Benché io lo ritenga necessario per qualsiasi progetto e per qualsiasi modalità lavorativa, durante la mia carriera professionale mi è capitato di dover intervenire su delle applicazioni web destinate ad aziende importanti sviluppate senza alcuna tecnica di separazione, con codice mark-up di ignota provenienza e istruzioni SQL memorizzate dove non era possibile immaginare, confermando i sospetti comuni secondo cui si sviluppa in modo irrazionale (o non ottimizzato) non solo per i piccoli progetti ma anche per quelli di una certa portata e destinati a grandi aziende in modalità premium.
Più il progetto è complesso o richiede complessità, più in assenza di una tecnica di separazione simile è necessario sviluppare dell'altro lavoro superfluo per razionalizzare i risultati, incidendo negativamente sulla velocità di esecuzione e sulle prestazioni generali. E talvolta la razionalizzazione dell'irrazionale, in quei progetti in cui non è possibile intervenire direttamente, assume la portata di un lavoro vero e proprio, ricorrendo a numerosi test di debug che ne certifichino i risultati e gravando sui tempi e sui costi finali dell'intervento tecnico.
Riprendendo il discorso sulla tecnica del template engine, riporto qualche frammento di codice per esemplificare la consistenza. Gli esempi riguarderanno i linguaggi di mia competenza.
Si ponga il caso di dover produrre degli elenchi e di dover alimentarli con delle voci attinte da una tabella del nostro database. Senza la tecnica del template engine, ci si troverebbe di fronte a una porzione di codice simile:
<?php
echo '<ul>';
while ($row = $sql->fetch()) {
echo '<li>' . $row['item'] . '</li>';
}
echo '</ul>';
?>
Tramite queste poche istruzioni si produrrà, mediante PHP, una lista di voci inaccessibili al web designer. Se, invece, si desidera che possa intervenire liberamente sulle proprietà dei tag HTML, bisognerà utilizzare la tecnica del template engine sviluppando un frammento di codice simile:
<ul>
<?php while ($row = $sql->fetch()) { ?>
<li><?php echo $row['item'] ?></li>
<?php } ?>
</ul>
Per quanto semplice ed essenziale sia l'esempio, si possono comunque evincere dei vantaggi:
- Se il web designer interviene per aggiungere un ID o una classe al tag, non effettuerà interventi di escape particolari per divincolarsi fra apici e doppi apici;
- Se il web designer intende spostare questa porzione di codice in alto o in basso nella pagina, potrà incorporarla fra i tag di apertura e chiusura di altri tag senza il cruccio della compatibilità;
- Se il web designer vuol alimentare una altra lista nella pagina, gli sarà sufficiente spostare il codice racchiuso fra i tag PHP, senza preoccuparsi di dover eliminare o spostare gli output prodotti dall'interprete (come nel primo caso).
Un altro esempio riguarda la stesura di codice SQL che talvolta viene riportato poco prima dell'output che PHP produrrà, come nell'esempio seguente:
<?php
$sql = $conn->query('SELECT item FROM list');
echo '<ul>';
while ($row = $sql->fetch()) {
echo '<li>' . $row['item'] . '</li>';
}
echo '</ul>';
?>
E, invece, è buona norma o consigliabile riportarlo prima dell'inizio del DOM, nella cosidetta zona di elaborazione; oppure, come verificatosi in altri casi, in un file indipendente con altre istruzioni SQL da richiamare/aggiornare. Quest'ultimo caso, però, dipende molto dalla complessità del progetto. Riporto l'esempio per maggiore chiarezza:
<?php
$sql = $conn->query('SELECT item FROM list');
?>
<!-- Inizio del DOM -->
<!DOCTYPE html>
<html lang='it'>
<head>
<title></title>
<meta charset='utf-8'>
<meta name='description' content=''>
<meta name='keywords' content=''>
<meta name='author' content=''>
<meta name='robots' content='all'>
</head>
<body>
<ul>
<?php while ($row = $sql->fetch()) { ?>
<li><?php echo $row['item'] ?></li>
<?php } ?>
</ul>
</body>
</html>
Anche i messaggi che vengono restituiti al termine di una operazione lato server possono essere gestiti separatamente. Personalmente, per questo scopo, ho usato sia file JSON che XML, richiamati all'interno del codice PHP e opportunamente parsati. Esemplificando:
<?xml version="1.0" encoding="utf-8"?> <messages> <success>Operazione andata a buon fine!</success> <error>Operazione non andata a buon fine.</error> </messages>
in JSON:
{
messages: {
success: 'Operazione andata a buon fine!',
error: 'Operazione non andata a buon fine'
}
}
È facile intuire come questa gestione, seppur complessa e lunga, sia di notevole aiuto per tutti i componenti di un team di sviluppo e faciliti e velocizzi ogni intervento di manutenzione e aggiornamento.
Avendo lavorato sempre in team avvalendomi del supporto di collaboratori complementari alle mie esigenze, non è mai stato riscontrato un problema nell'aggiornamento dello stile, del mark-up o dei testi, consolidando di fatto, proficuamente, la collaborazione negli anni.
Tutti gli esempi riportati sopra sono essenziali e funzionali a scopo didattico. Non contemplano molteplici fattori che solitamente subentrano in progetti di ben altra entità o che si interfacciano con API su cui non è possibile intervenire direttamente.
Fonte immagine: Google Immagini