Django introduction

Editor's Notes

• #3: Cos’è Django, o, meglio Jang-oh? E’ un web-framework scritto interamente in Python, che nasce da un’esigenza pratica: un team di sviluppatori americani creavano e manutenevano numerosi siti di news locali. Si dovettero imbattere in deadline «ostiche» in quanto sia i giornalisti che il «management» dietro questi siti richiedevano di continuo l’aggiunta di features (spesso comuni tra loro), con pochissimo preavviso (qualche giorno o addirittura qualche ora). Per riuscire a «stare dietro» a queste deadlines così «incalzanti» crearono un Web-Framework «salva tempo» per creare e manutenere questi siti in modo veloce ma preciso, che svilupparono per due anni, prima di renderlo pubblico e rilasciarlo nel 2005 come software open-source. Attualmente Django è un progetto maturo, con migliaia di utenti che contribuiscono alla crescita di tale progetto e numerosi utilizzi di tale framework per siti di produzione.
• #4: Due parole su Python: È un linguaggio interpretato È Interattivo; il suo interprete permette infatti di inserire codice da un terminale e visualizzare subito il risultato È multiparadigma ed ha una sintassi semplice e snella, con l’indentazione, al posto di mille parentesi, per la definizione di blocchi di codice. Possiede una tipizzazione dinamica (in cui il controllo avviene a runtime) Infine, una sua valida caratteristica è l’essere modulare e l’essere corredato, come vedremo, di batterie incluse
• #5: Per capire le principali funzionalità di Django e la metodologia per la creazione di un’applicazione, vediamo in concreto una semplicissima applicazione reale e i passi fondamentali da affrontare per il suo sviluppo. L’applicazione in questione permetterà di eseguire sondaggi; per ognuno, avremo una domanda e una serie di risposte, tra cui gli utenti dovranno scegliere. Visualizzeremo poi quante volte ciascuna risposta è stata scelta.
• #6: Primo passo: installare Python (in una versione fino alla penultima, perchè l’ultima, la 3.0, non è ancora supportata) Secondo passo: installare Django. Dove verrà installato (in Windows)? C:\\Program Files\\Python27\\Lib\\site-packages Poi apriamo la shell e verifichiamo che python sia stato installato correttamente Python; se viene correttamente mostrata la shell di python tutto è ok! Quindi verifichiamo se anche django è stato installato correttamente Python => import django => django.VERSION In ultimo, decidiamo che db vogliamo utilizzare: nativamente django supporta PostgreSQL, SQLite, MySQL e Oracle; tranne che per SQLite, che useremo per comodità, è necessario scaricare e installare l’adattatore Python ad-hoc per il determinato tipo di database.
• #7: Ed ora creiamo il nostro progetto. Cos’è un progetto in Django? è un insieme di app, più le configurazioni di esse. Ci posizioniamo nell cartella in cui vogliamo creare il nostro progetto, ci copiamo il file django-admin.py che prendiamo dalla bin ove è stato installato django (per evitare di copiarlo ad ogni progetto, si può metterle come variabile d’ambiente!), apriamo la shell: django-admin.py startproject demoProject Ci ha creato un file di utility, un file di impostazioni e un file che definisce le regole di routing per il nostro progetto. Verifichiamo se anche questo step è andato a buon fine: entriamo nella cartella del progetto e facciamo partire il server di sviluppo di django Cd demoProject python manage.py runserver http://127.0.0.1:8000/ Creiamo quindi un’app. Cos’è un’app? È un insieme PORTABILE (quindi riusabile in diversi progetti) di funzionalità django che coesistono in un unico package python. Creiamo quindi l’app dei sondaggi: python manage.py startapp polls Ecco i files creati.
• #8: I files «models» e «views» dovrebbero farci venire alla mente il famoso pattern di progettazione MVC, model view controller. In realtà Django ne adotta, possiamo dire, una «reinterpretazione», denominata MTV, ovvero model template view. Vediamo in che relazione si pongono tali pattern. In MVC: Il MODEL è il layer di accesso ai dati; contiene ogni informazione riguardo come accederli, come validarli, che comportamenti hanno e che relazioni intercorrono tra di loro. Tale layer è il medesimo per entrambi gli approcci. La VISTA è il layer di presentazione; contiene le «decisioni» riguardo COME i dati devono essere mostrati in una pagina web o in un altro tipo di documento. In Django la presentazione dei DATI è affidata ad un TEMPLATE. Il CONTROLLER incapsula il comportamento dell’applicazione, descrive QUALI DATI vengono mostrati all’utente e fa da legame tra i dati e la loro presentazione. In Django questa funzione è implementata dalle VISTE, cioè funzioni Python. Infine, anche Django possiede un concetto di CONTROLLER, che è rappresentato dall’intero framework, cioè dal meccanismo che, a partire dal template, inoltra la richiesta alla particolare vista, sulla base delle regole di routing definite.
• #9: Esaminiamo dapprima il livello di accesso ai dati: i MODEL. Per velocità vi mostro i files dell’applicazione già implementata. Nella nostra applicazione abbiamo le due entità «Sondaggio» e «Scelta, Risposta». Esse vengono rappresentate da due classi Python; per potersi interfacciare con il database, esse ereditano dalla classe Model. Questo dichiarazione di eredità è l’unico codice necessario per avere l’accesso ai dati con l’ORM fornito in automatico da Django. Ogni model ha determinate variabili di classe, ognuna delle quali rappresenta nel modello un campo nel database. Ogni campo è rappresentato da un’istanza della classe «FIELD»; l’obbligatorietà di un campo, il valore predefinito ed altre caratteristiche dii un campo sono definite sempre a livello di model, come parametri dell’istanza della classe «FIELD». Nel nostro esempio, il modello SONDAGGIO possiede una domanda testuale e una data di pubblicazione, mentre ogni SCELTA possiede una descrizione testuale, il numero di volte in cui è stata scelta e il riferimento, tramite relazione many-to-one al sondaggio di appartenenza. Grazie alle informazioni definite nei model, Django è in grado di creare lo schema del db per questa applicazione e un set di API per l’accesso ad oggetti di tipo Sondaggio e Scelta. Due sono le configurazioni da impostare prima di lanciare la creazione dello schema: Aggiungere la nostra Applicazione nei Settings del progetto. Perchè fino ad ora, nonostante sia stata creata al suo interno, il progetto è ignaro dell’esistenza dell’App. Impostare il tipo di database utilizzato e, nel caso di sql lite, il percorso dove si troverà il db (la prima volta il file viene creato da Django) Quindi torniamo alla nostra shell, ed eseguiamo i seguenti comandi: python manage.py sql polls: ci vengono mostrate le query di creazione dello schema che Django ha intenzione di eseguire python manage.py syncdb: questo comando scorre le app installate e per ognuna crea, se non già esistenti, le tabelle opportune in base agli script precedentemente mostrati. Ogni volta che viene lanciato questo comando, solo le tabelle che non esistono vengono create, le altre rimangono invariate. Se ci volessimo togliere lo sfizio di verificare che anche questo comando sia andato a buon fine, apriamo il db e verifichiamo le tabelle create (per ex. Con Navicat)
• #10: Una volta che i model sono pronti, passiamo a definire le viste, cioè le funzioni Python che accedono ai dati, che decidono cosa far mostrare ai template, che implementano la business-logic. Ogni vista è responsabile di eseguire una di queste due cose: o ritornare un oggetto di tipo HttpResponse contentente il «contenuto» per la pagina richiesta, o lanciare un’eccezione, come ad esempio un’Http404. Al suo interno la funzione può accedere o meno il db, può generare files di qualsiasi tipo.. L’importante è che restituisca o un HttpResponse o che lanci un’eccezione. Nel nostro esempio avremo quattro viste: Index: la index recupera dal db gli ultimi 5 sondaggi in base alla data di pubblicazione e li salva in una lista. Carica quindi il template index.html, e gli passa un context, cioè un dictionary che mappa nomi di variabili del template con oggetti python. In questo caso viene passata la lista. Detail: la detail riceve in ingresso l’id del sondaggio da mostrare, grazie a questo recupera l’entità dal db e la passa al template detail.html. Vote: la funzione che implementa il meccanismo di voto riceve l’id del sondaggio che si sta visualizzando, recupera l’entità sondaggio; recupera quindi la scelta effettuata dall’utente accedendo ad una specie di dizionario che contiene i dati SUBMITTED. Se l’utente non ha scelto alcuna opzione, gli viene mostrata nuovamente il template per votare. Altrimenti, va ad incrementare il contatore dei voti della scelta selezionata e passa il controllo alla vista results Results: la quale reperisce il sondaggio di cui mostrare i risultati e lo passa al template results.html.
• #11: Ma dove si trovano questi template? E come sono fatti? Non si trovano dentro l’app, in quanto non sono files python. Li possiamo mettere in una qualsiasi cartella, il cui percorso verrà inserito nei settings. Nel nostro caso ho creato la cartella Template dentro il progetto, e una sottocartella Polls, per racchiudere i template della nostra applicazione. Apriamoli brevemente. Tutti e tre «estendono» un template comune, una sorta di «masterpage», la base.html, in cui vengono definite le componenti html della pagina da mostrare. Cominciamo con index; la vista inviava a tale template la lista degli ultimi sondaggi. Se tale lista contiene almeno un elemento, si cicla su questa collezione e per ogni sondaggio viene stampata la domanda come link per visualizzare il dettaglio del sondaggio. Altrimenti viene visualizzato un messaggio che indica che nessun sondaggio è presente a database. Il template Detail mostra la domanda del sondaggio, un eventuale messaggio di errore che compare se l’utente preme il pulsante per votare, senza aver selezionato alcuna opzione. Per ogni scelta viene creato un radiobutton ed infine viene creato il pulsante di invio dei dati. L’ultimo template, infine, mostra la domanda del sondaggio, le relative risposte e per ognuna il numero dei voti ottenuti. Più un link per poter votare nuovamente. Dovremmo essere a posto, abbiamo definito i model, le viste e i template. Prima di far partire l’applicazione andiamo ad aprire il file url.py, definito a livello di progetto, per visualizzare le regole di routing, cioè il meccanismo che mette in relazione gli URL con il codice Python. Quando un utente richiede di visualizzare una pagina all’interno di Django, il sistema va a vedere nel settings il nome del modulo python che contiene le regole di routing. Carica poi tale modulo e va a scorrere le tuple contenute nella variabile «urlpatterns»: ogni tupla possiede un’espressione regolare, la funzione python (o vista) da invocare, e un dictionary opzionale di parametri. Django scorre le varie espressioni regolare, comparandole con l’URL richiesto, finchè trova l’espressione che matcha. Quando la trova, invoca la funzione python definita nella tupla, passandole un’HttpRequest come primo argomento, eventuali valori definiti nell’espressione regolare, catturati tramite le parentesi tonde e, opzionalmente, altri argomenti definiti nel dictionary. Stop, facciamo girare l’applicazione. Facciamo partire il nostro server, aggiungiamo la parola polls nell’url per matchare con la prima regola di routing che ci mostra l’elenco dei sondaggi e.. Accidenti, non vediamo nulla perchè il nostro db è vuoto. Mancano i dati. Come possiamo velocemente inserirli? Varie le soluzioni. Potremmo farlo tramite la shell di Python.. Ok.. Un pò macchinoso.. e magari non ricordiamo esattamente la sintassi... Potremmo farlo tramite un’ulteriore template con una form.. E una view che recupera i parametri inseriti e crea nel db le entità.. SI potrebbe fare ma è un pò lunghetto da fare ex-novo. Ma.. Non abbiamo detto all’inizio che Django è nato da un’esigenza reale di velocizzare il tempo di sviluppo e manutenzione di siti che, come quelli di news, sono di tipo «content-site», come l’esempio che stiamo sviluppando? Come può quindi Django venirci incontro e velocizzare il nostro lavoro di inserimento dati, col minimo sforzo? Andiamo a sfruttare una delle «batterie incluse» in Django.
• #12: Una delle maggiori forze di Python è la sua filosofia a «batterie incluse»: quando installi Python, esso si presenta come una grande libreria di package che possono essere utilizzati da subito, senza dover scaricare nient’altro. Django ha seguito questa filosofia e include nella sua libreria numerosi add-on per i task più comuni dello sviluppo web. Tra di esse possiamo ricordare l’add-on per gestire l’autenticazione, per gestire le form (anche le più complesse) e, per curiosità, l’add-on per eseguire query geografiche.. Ma l’add-on che serve a noi è l’ «Admin Site», cioè un pannello di backend per la gestione dei contenuti. Come abbiamo detto, non bisogna installare nulla, è una «batteria inclusa». 4 sono i passi velocissimi da fare per abilitarlo e in meno di un minuto saremo pronti ad utilizzarlo. Nella lista della app del progetto, dovremmo andare ad inserire anche l’app che implementa questo AdminSite Nelle regole di routing dovremmo andare ad aggiungerne una che gestisca l’url dell’AdminSite Creiamo quindi nella nostra applicazione un file admin.py in cui specifichiamo quali entità vogliamo gestire dall’AdminSite Infine, visto che l’accesso a tale pannello è vincolato da un’autenticazione, creiamo a livello di db un superuser per poterci in seguito loggare (se non già creato in fase di creazione dello schema del db) Python manage.py createsuperuser STOP Facciamo partire il server, digitiamo Admin .. Ed ecco.. Creiamo un sondaggio con qualche opzione... Ora puntiamo alla nostra applicazione e... Well done!