Django parte1

Ho deciso di scrivere prima la guida su Django ,sospendendo quella che avevo già iniziato su

google App Engine. Il motivo ? GAE (Acronimo della tecnologia di google) nella versione

sviluppata con l SDK python ,si basa e,prende molto spunto proprio da Django.

I motivi ,per chi conoisce Django ,sono piuttosto evidenti.Per me,è che Django è progettato

veramente bene ,ha una sintassi precisa ed elegante,che non si puo non appassionarvici.

Su Django di guide in italiano(a differenza di Quixote) ce ne sono di diverse ,io comunque

voglio scrivere la mia ,tenendo sempre a mente di chiarire bene quei passaggi dove

personalmente ho trovato qianche ostacolo nella comprensione ,che sia la sintassi ,la logica,

configurazione  o altro. L’ indirizzo di riferimento della comunità Django è: Djangoproject

Qui si trova praticamente tutto ciò che ci occorre ,ed anche di più.La versione su cui ho

scritto questa guida,è la  1.0, la prima definitiva¹.Oggi che inizio siamo giunti all 1.2.5.

Anche se ci sono differenze anche interessanti tra le versioni,in linea generale comunque la

guida è valida anche per la versione più aggiornata.

Ricordo che quando ci trovavamo ancora alla beta 0.96 quando andavamo a scrivere le classi per i models, quando andavamo a creare le proprietà-campo dei model-oggetto ,

nei campi testuali nome = models.CharField() ,potevamo passargli un argomento che

indicasse il numero massimo di caratteri che poteva accettare (molto utile nelle form).

Essa si chiamava appunto ‘ maxlength ‘ nella beta 0.96 , e ‘ max-length ‘ ,nella 1.0.

Tranne il modo di esplicitare i nomi ,la logica dell applicazione è comunque

rimasta uguale.Ricordo comunque che questo fatto mi fece penare non poco ,dato che

non mi riusciva di risalire al motivo dell’ errore,che benchè Django ( debug-mode),

mi dicesse dell errore sintattico , io non riuscivo a capirlo,dato che davo per scontato

il nome dell’attributo..

questo affinchè teniate a mente questa possibilità nello scrivere applicazioni Django.

Installazione:

Prerequisiti.

Per installare Django , ci occorrono : L interprete Python , ed un motore server di database.

Django gira con una versione di Python che va dalla 2.3 in poi,escludendo la versione 3.0.

I motivi di questa esclusione sono che python 3 non è retrocompatibile al 100% , cioè

applicazioni strutturate su di una versione 2.x di Python spesso

non girano con la versione 3.0.

Questo non è accaduto negli upgrade precedenti , ma con la 3.0 ci son stati cambiamenti

basilari ,da qui ,i problemi di retrocompatinilità.Sicuramente in futuro ,come per Django ,

anche per altre applicazioni si scriveranno nuove versioni compatibili con la 3.0  ,

ma al momento tanti framework python con la versione 3.0 del linguaggio non vanno.

Allora dicevamo,necessitiamo di una versione python che sale dalla 2.3.

Oltre all’ interprete Python ci occorre un database engine,e Django ne supporta parecchi ,

a partire dal complesso Oracle ,passando per Postegresql , per Mysql fino al minimale Sqlite.

Io ho deciso per Mysql ,per cominciare è ,molto facile da gestire,veloce , e quasi tutti

quelli che scrivono codice per il web , lo conoscono.E poi è Free !

Prima di passare ad una guida che faccia riferimento ad esempi di una applicazione reale,

soffermiamoci a descrivere 2 caratteristiche di Django che spesso vedrete definite

attraverso degli acronimi .

Il primo è O.R.M. ( Object-Relational Mapping ) .Tecnologia che attraverso dei comandi

( syncdb per Django) esegue la mappatura degli oggetti-classe che il programmatore Django

scrive nel file model.py ,i models appunto,con un database relazionale di quelli sopra citati.

Il models corrisponde ad una tabella,e le sue proprietà ai suoi campi-colonna.

La flessibilità e portabilità sono massime , infatti possiamo nel models, creare delle

proprietà model.ForeignKey(nomeclasse ) che fa riferimento all id di un altro model

di cui sono la chiave esterna,come vogliasi per ogni buon database relazionale .

Dicevamo poi la portabilità ,infatti nel file settings.py possiamo scegliere qualsiasi

database noi vogliamo,di ciò se ne occuperà l ‘ORM di Django.

Quello che a noi deve è solo creare i models con la giusta sintassi e logica di relazione.

Il resto , come le differenze di SQL delle query tra i diversi RDBMS ,se ne occupa DJANGO

che attraverso le sue query associate agli oggetti del models ci permette di lavorare nel DB

direttamente attraverso il codice del framework .

Un altro importante acronimo che incontrerete spesso, con Django,

è il paradigma M.V.C. ( Model View Controller ) .

Questa tecinca di programmazione è oramai diventata regola per i framework che

vogliono occupare le prime posizioni in fatto di avanguardia e standard di sviluppo.

Esso consiste nel  metodo di separare la logica dai contenuti ,e dalla loro presentazione.

All inizio delle applicazioni web ,questo era di importanza minima, basti

gurdare alle implemantazioni SSI , ma ancora oggi in tutti i liguaggi  Server Side,

capita di scrivere codice  ” Embedded ” , cioè linee di scripting tra i tag di markup

dell HTML ,senza far uso di file di template ,che però oggi ,in qualsiasi framework che si

rispetti,è divenuto parte imprescindibile.Questa abitudine di ” embeddare ” logica applicativa nell’ HTML

l’abbiamo sia in Python ,quando scriviamo funzioni che danno in output codice html,

con moduli di basso livello ,oppure con framework a loro piu vicini (ad esempio Quixote)

dove, anche se ci sono dei sistemi di template ,essi sono molto” grezzi “,nel senso che

scrivevo prima,cioè si servono di moduli a basso livello per restituire  html in output.

Sempre in python .Le Python Server Pages ( PSP )  codice python sviluppato in stile

ASP  PHP  JSP.

Oltre che Python ,il modo EMBEDDED lo abbiamo anche in PHP,anche se i nuovi framework

fanno tutti uso di MVC,e ancora le Java Server Pages che ,a differenza delle Servlets

(che invece separano presentazione e logica) ,usano ancora inserire TAG speciali nel

codice html,come ben sa chi ha sviluppato attraverso  Tomact o Jboss.

Quindi , con MVC, gli elementi da separare sono i Dati (Models), la

View (rappresentazione dei dati e dell output  del Controller ) e Controller (

che si riferisce alla parte logica dell applicazione , funzioni ed interazioni varie)

Una cosa è importante , non bisogna rimanere troppo legati agli acronimi ,rigidamente,

quello da tener presente ,è ciò che vogliono significare (la separazione tra gli stati dell’

applicazione),dato che ogni framework , il paradigma lo esplicita in maniera personalizzata.

Infatti lo stesso Django potrebbe indurre ad una certa confusione ,in quanto ,il Model ,

vabbè resta il model cioè i dati grezzi ,quelli rappresentati dalle classi scritte in models.py

(appunto),e che attraverso ORM , vengono poi trasferiti in record del database scelto.

La View in Django è rappresentato dal file di template ,in quanto è quello che si

occupa di come mostrare i dati del Models ,od i risultati stessi.

Infine il compito del Controller viene svolto dalle Views.

Nel file Views.py infatti si esplicita la logica dell applicazione,in esso avvengono

le operazioni sui Models ,in esso si scrivono poi le funzioni che raccolgono i dati  ,

attraverso le scelte utente interfacciati ai Template ,si svolgono su di essi le operazioni

necessarie ,e ritornano i risultati.

Il Controller ,si inserisce in pratica come collegamento tra il Models ed il Template.

Capite quindi che se rimaniamo troppo legati ai ” nomi ” delle cose ,si rischia di fare

un po di confusione.Molto meglio capire cosa è che fanno ,le varie componenti,

e perciò affidare ad ognuna i suoi compiti.

Torniamo all elenco di ciò che occorre per sviluppare applicazioni web con django.

Dicevamo Python > 2.3 è database relazionale (per noi mySQL ).

Per un ambiente di sviluppo non necessitiamo di null’altro,dato che Django

include nel package un web server piu che sufficiente a testare le applicazioni,sopratutto in

modalità di Debug.Si trattasse solo si eseguire codice python ,il web server interno a Django

andrebbe benissimo,ma spesso un server web fa molto altro ,e poi le cose si possono fare

in tanti modi,si posson fare bene ,oppure male, lentamente ,o velocemente,quindi

in un ambiente di produzione  , è  consigliato  usare   Django   abbinato ad un web server

esterno al framework ; Apache va benissimo , ma potremmo usarne anche

uno minimale,importante è che supporti le interfacce per  eseguire codice python di Django.

le interfacce  ci permettono di  passare la request ad un programma esterno ,scritto in un

linguaggio di programmazione ,e che produce contenuto dinamico.Il web server si

“interfaccia” a questi programmi in diversi modi.Ci sono i vecchissimi CGI ,che sono

il modo piu semplice (ma meno performante) per richiamare un interprete python,

pressochè tutti i web server li supportano.In pratica (non staremo qui a spiegarli),

attraverso un paio di linee di codice nel file,e di opzioni nella configurazione del web

server,ad ogni request verrà richiamato l interprete per eseguire il codice del file cgi.

Per Apache occorre il giusto modulo  mod_cgi ,che comunque mi sembra venga

installato di default,mentre per il linguaggio esistono opportune librerie.

Abbiamo poi fcgi o fastcgi , e scgi , tutti e 3 tentano di ridurre i

problemi di performance dei CGI, tenendo in memoria l’intreprete in background,

esso rimane sempre esterno al web server,che per passare la request all interprete,

non ha bisogno di avviare un processo nuovo ogni volta.

Apache supporta i primi 2 ,attraverso mod_fcgid e mod_fastcgi, mentre mi pare

non supporta SCGI ,infatti un mod_scgi esiste ma  per   lighttpd ,che è un web

server minimale.Per Apache poi abbiamo il modulo  mod_python che mantiene

in memoria nel processo di Apache,tipo come fa il FASTCGI ,solo che lo   mantiene in

esecuzione all’ interno del web server.Ad ogni request,si avvia un processo “Child” di

Apache. mod_python  inoltre ci mette a disposizione molte altre funzioni,infatti si

puo definirlo un vero e proprio franework anche se molto  a basso livello di astrazione.

Abbiamo poi WSGI protocollo per crare un interfaccia standard per l’applicazione che ,

funzionerà con qualsiasi server  che implementi un wrapper per WSGI.L’  interfaccia client

e l implementazione server ,hanno pi bisogno di un ‘ gateway’ ,cioè di codice che fa da

colla fra i 2 ,affinchè entrino in comunicazione.Il lato applicazione (o framework) non

importa se   poi usi per ciò CGI, FCGI, o mod_python, qualsiasi server che supporti

WSGI ,pur nelle sue differenze di implementazione,riuscirà ad eseguirla.Possiamo quindi

spostare,un applicazione WSGI da un server all altro(purchè lo implementi) ,che essa

funzionerà sempre ,senza alcuna modifica.

Abbiamo poi il mod_wsgi,che è stato creato  per evitare di inserire la chiamata CGI

o chi per loro,nel codice applicazione client,inserendola all interno del server.

Però esso funziona solo con Apache

Come scrivevo sopra un applicazione web con Django,non è solo codice python ,per cui

appunto il web server incluso in django sarebbe ottimale,senza ricorrere ad interfacce di

gateway per fer passare la request a python.infatti una applicazione è formata anche di

immagini,video,file pdf,css , javascript ecc.,files statici insomma,per i quali invece le

performance migliori  ce le da un web server esterno.infatti ,rimanendo su Apache,che

in quanto a web server è di sicuro il piu usato e versatile del web,potremmo configurarlo

in modo che le richieste per i files statici le serve lui ,mentre tutto il resto lo lascia a python.

meglio ancora usarne 2 di web server esterni,che sembra sia il modo piu veloce,un

webserver ci serve gli statici,mentre per il resto ci fa da reverse proxy per un altro che

funziona da interfaccia server per gatway WSGI alla applicazione.

vedremo di fare degli esempi di codice e configurazioni di queste implementazioni.

Torniamo alla installazione:

Allora scarichiamo la versione piu recente di Django dal sito  http://www.djangoproject.com

Al momento siamo arrivati alla versione 1.3 ,(no problem le differenze sintattiche  con la 1.0

sono irrisorie),scaricate comunque la versione che volete basti che sia >= la 1.0.

Una volta scaricata decomprimere il pacchetto se si tratta di archivio compresso,

entrare nella directory decompressa e, installare Django attraverso il comando

[gianluca@samson ~]$ sudo python setup.py install

(samson è il nome della mia macchina ,e guianluca l account loggato)

Ovvio che se l utente non

rientra tra quelli registrati nel file /etc/sudoers ,dobbiamo installare attraverso il

superuser ROOT , altrimenti non riusciremmo a scrivere in /usr/lib/python2.5/sites-packages

che è dove il S.O. installa Django.

Vi rammento che il   S.O. delle prove fatte  è una distribuzione linux fedora 7.

Se invece dal sito djangoproject scaricate un pacchetto .EGG  ,bisogna installarlo

attraverso l utility  easy_install . Che se non l avete bisognerà installarla.

Passiamo a scegliere la directory dove installare la nostra

prima applicazione.Qui bisogna sapere che Django non ci obbliga  a sistemare gli script

in una sottodirectory della WebRoot di Apache,ma attraverso i settaggi del mod_python

possiamo scegliere  dove metterli , come ad esempio mella nostra home dir.

Se poi usiamo il web server  standalone di Django,il problema di applicazioni sotto le webroot

di Apache ,non si pone assolutamente ,anche se questo è sconsigliato in ambiente di produzione.

Infatti in applicazioni definitive su web ,le cose sono piu complesse per cui spesso è

conveniente distinguere le sezioni ed i file che verranno serviti da django ,e quelli che invece

(ad esempio file statici) saranno lasciate  gestire ad Apache.

Questo ci fa aquisire dei vantaggi in termini di sicurezza,dobbiamo solo aggiungere l’

utente apache al gruppo utente del proprietario della home dir dove creiamo i file,

altrimenti il web server non avrebbe permessi di lettura per le directory utente.

Fare attenzione al fatto che spesso delle distribuzioni linux,contengono nei

repository la possibilità di installare diverse utilità ed applicazioni ,tra cui lo stesso Django.

Se questo da una parte può essere vantaggioso ,sia per velocità di installazione ,che

per il diminuirsi delle possibilità di errore,anche grazie all’ automatismo che controlla ed installa

tutte le dipendenze.Dobbiamo però sapere che queste installazioni sono molto personalizzate

da parte delle softwarehouse che le distribuiscono,e quindi possiamo trovarci di fronte a

differenze anche sostanziose riguardo ad esempio a dove vengono installati vari file,e

per la variazione di procedure che, essendo ottimizzate per quella particolare distro,

possono metterci in difficoltà, specialmente quando seguiamo i tutorial piu o meno ufficiali.

Quindi consiglio ,come ho fatto io, di installare sempre una versione scaricata dal sito

ufficiale,sicuramente  ne guadagneremo in seguito ,di fronte ad eventuali intoppi da

risolvere.

Andiamo alla seconda parte del tutorial ,e vediamo come iniziare la nostra prima

applicazione.

parte2

1] la versione trattata non sarà più la 1.0 ,ma la 1.3 SVN, mi sembra la cosa piu ovvia e giusta.

I procedimenti ,fin qui elencati non differiscono in ogni caso ,sia che  si installi la 1.0 oppure

la 1.3 ,tranne per il fatto che l interprete python necessita con Django 1.3 ,della versione >= 2.4,

Mentre la 1.0 lavora anche con python 2.3.Per il resto tutto come prima .

Una sola altra cosa da specificare è che questa che trattiamo è una versione  di sviluppo .

Le versioni di sviluppo ,si contraddistinguono dal fatto che si aggiornano sempre all ultima

disponibile ,e questo è possibile attraverso il software Subversion.

Una volta scaricata la Development Django1.3 SVN (chiamata  Django-Trunk).

possiamo ogni volta che lo desideriamo, andare nella directory django-trunk

posta in sites-packages/  creare un file con estensione .pth ,esso indicherà a Subversion,

il percorso fisico dove sta  django-trunk.  Adesso attraverso Subversion  da shell :

[gianluca@samson ~]$ vn co http://code.djangoproject.com/svn/django/trunk/ django-trunk

Questo comando terrà aggiornato i sorgenti Django sempre all ultima versione disponibile dagli sviluppatori.

Attenzione però !

Attenzione alla compatibilità delle versioni man mano che si faranno degli upgrade del codice.

Ad esempio ,se tramite Subversion noi aggiorniamo Django dalla versione 1.0 ,con python 2.3,

Se avremo (attualmente è così) un upgrade alla 1.3 ,dovremmo assolutamente aggiornare python

alla versione >= 2.4 altrimenti non funzionerà.

Leave a Reply

Your email address will not be published.


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>