T sta per template

Quando scrivevo qualsivoglia pagina in PHP, che dovesse essere un pochino complessa, ero solito definire almeno due funzioni in un file. Funzioni che servivano per stampare l'intestazione e il footer della pagina.

Successivamente, quando dovevo scrivere una pagina, includevo questo file e scrivevo il codice PHP misto a HTML. Se per disgrazia dovevo cambiare la grafica, il layout, o fare altre modifiche di natura grafica, dovevo rimettere mano al codice, e scansare man mano le righe di PHP. Tutto questo si traduceva in vari copia incolla dello stesso sorgente, snippet vari conservati in altri buffer dell'editor e così via...

Rimettere mano alla pagina, dopo tanto tempo, diventa un problema perché non ricordi bene il funzionamento, e capita spesso che qualche cosa vada storto per una semplice modifica. Per questi motivi (e altri) motivi decisi di rifare da zero RCP64. I template risolvono questo problema, non fanno altro che separare la rappresentazione della pagina in HTML da tutto il resto.

Un template engine non fa altro che mettere a disposizione dei speciali tag da inserire dentro il codice HTML, questi tag non sono altro che dei segnaposto per le variabili da stampare. Nella pagina così costruita, nel momento in cui dovrà essere visualizzata, verranno sostituiti i segnaposti con i nostri dati. Così facendo, in un momento di restayling, spostare tag e segnaposti è molto più sicuro che rischiare di cambiare il codice.

M sta per models

Un'altra abitudine consolidata nello scrivere siti web che necessitano di connessioni al database, è quella delle scrittura di grezze query SQL all'interno della logica appartenente alla pagina. Scrivere SQL permette di ottimizzare direttamente l'uso del database, si va diritti al punto nel minor tempo possibile. In certe occasioni può servire una astrazione maggiore, una interfaccia con le entità associate a determinate proprietà.

Django mette a disposizione un sistema ORM attraverso i modelli, che non sono altro una astrazione dello schema ER del proprio database. Ogni entità, con i campi e le relazioni, viene definita tramite classi. In questo modo il frame work conosce la struttura dei nostri dati, e potrà prendersi cura di essi validandoli all'inserimento e convertendoli nel tipo di dato appropriato. A tutto questo viene aggiunto un livello per il controllo dell'integrità e della correttezza dei dati, tutto questo senza dover scrivere una riga di SQL ma con la sola manipolazione di oggetti e funzioni. Sono tutte cose che fa intrinsecamente qualsiasi DBMS ma I'astrazione ha un vantaggio pratico con l'interfacciamento del codice Python.

Basandosi sui vostri modelli il frame work è in grado di realizzare una interfaccia di amministrazione per i dati, potete perfezionarla e correggerla in ogni minima parte. Si possono aggiungere particolari elementi come il modulo di ricerca e modificare il template. L'interfaccia non è sola esclusiva per l'admin, potete decidere cosa gli utenti possono accedere e modificare. Il vantaggio in tutto questo è l'estrema rapidità di realizzazione.

V non è per Vendetta ma viste

In PHP quando richiediamo una pagina solitamente ci riferiamo a un file .php, in un determinato percorso con possibili parametri. Con django è totalmente differente, l'URL che cerchiamo viene passato al framework che lo passa attraverso una serie di espressioni regolari. Quando trova una corrispondenza chiama una funzione scelta e scritta da noi, possiamo pure passare dei parametri attraverso l'URL grazie alle regex. Questo permette di lavorare con URL lisci senza passare parametri con GET, una cosa del genere la si ottiene con PHP solo attraverso gli URL rewrite di Apache.

Queste funzioni non sono altro che le viste. La vista è il fulcro per quanto riguarda la logica del nostro sito, processa i dati provenienti dagli URL, li elabora, estrarre contenuti dal database e si interfaccia con il template. Il frame work mette a disposizione degli strumenti per la creazione di speciali viste, queste possono servire ad esempio alla generazione di feed RSS.

Django ha tutta una serie di funzioni per la gestione di un bacino di utenti, crea automaticamente le tabelle nel database implementando un sistema di gruppi e permessi. Possiamo anche associare dei profili per ogni utente senza sforzo, abbiamo a disposizione tutta una serie di funzioni per la registrazione, l'autenticazione e varie forme di controllo.

Conclusioni

Lo sviluppo con django di differenzia notevolmente da chi è abituato con un ambiente LAMP, abbiamo una struttura da seguire e molte operazioni di routine necessitano la riga di comando. Durante lo sviluppo ne avremo bisogno per creare il database, gestire i progetti, le componenti e soprattutto per tenere su un web server di prova durante lo sviluppo. Per il deployment invece si ha bisogno di una struttura più grande, magari basata su Apache o qualche altro software. Ci sono vari accoppiamenti tra web server e DBMS, ma data la sua natura non legata a una particolare tecnologia lo rende flessibile per la maggior parte degli ambienti.

Django è un modo differente di realizzare soluzioni basati su un sito web, mette a disposizione strumenti per il lavoro più ripetitivo e una serie di librerie che ti cullano. Non ti protegge dal scrivere brutto codice più di quanto non lo faccia Python. Ad ogni modo no è la soluzione a tutte le esigenze, è più una valida alternativa per certi tipi di lavori.

Per fissare i concetti e le tecniche ho scritto un blog engine, potete trovare il repository a questo indirizzo. Come libro di testo ho usato The Definitive Guide To Django, consultabile interamente on-line. Non ho trovato il libro molto esauriente, ma per iniziare è un buon testo, non ha nulla di definitivo come afferma il titolo.