Django parte4

Siamo arrivati a spiegare le opzioni di localizzazione ed interazionalizzazione del file

settings.py di Django,che si trova nella directory di progetto.

TIME_ZONE = ‘Europe/Rome’

esso definisce il fuso orario da utilizzare nell uso dell ora.

LANGUAGE_CODE = ‘en-us’

Siccome Django offre la possibilità di servire le pagine  [ data/ora e  costanti ]

in diversi linguaggi ,questa opzione ci dice quale è la lingua di default con la quale

formattare i dati.La cosa è un po piu complessa ,Django offre diverse possibilità

riguardo la manipolazione e la formattazione dei dati,vedremo  come Django usa

le varie funzioni e keyword per la localizzazione ed internazionalizzazione.

USE_I18N = True;

Questa opzione settata a True,avvia il meccanismo di internazionalizzazione dei dati.

In pratica in django ci sono delle stringhe costanti ,come quelle nell interfaccia di

amministrazione,nei testi di aiuto,nel caso di errori ad es. nelle form ,ed in altri casi,

queste stringhe sono gia internazionalizzate in django,in molti linguaggi.

Quando questa opzione è settata True,esse vengono tradotte automaticamente nel

linguaggio del visitatore ,mettiamo che nonostante l opzione

LANGUAGE_CODE = ‘ en-us ‘ ,io con il mio browser , visito le pagine dell

applicazione,Django con questo settaggio, mi ritorna le costanti-stringa  tradotte

in italiano.Quindi se LANGUAGE_CODE =’ en-us ‘ ,come fa Django a sapere in

che lingua restituire le costanti stringa (oppure la data e l’ ora)? Django lo fa

controllando prima le variabili della sessione utente ,poi eventuali cookie ,infine

gli header HTTP del client (browser).

USE_L10N = True;

Questa invece permette a django di formattare la data e l ora secondo  la codifica

locale‘  usata. Ricordate che quando nelle guide  trovate il termine inglese

locale ‘, esso sta a significare qual’è la lingua  impostata di default nel client.

Da non confondere con la codifica .I vari codici identificativi  in locale sono

(it =italiano,fr=francese ,en-US =inglese americano).Questo perchè Django

traduce  i nomi dei mesi ,dei giorni della settimana, l ordine ed i nomi nelle date.

Non è solo una questione di traduzione ,ma ci sono anche differenze posizionali.

Ad esempio la data e l ora ,in inglese ,si scrive mese/giorno/anno,

mentre in italiano avremo giorno/mese/anno.Con quest’ultima  avremo la

data formattata in base al linguaggio identificato dal parametro ‘locale‘ .

Ci sono altre diverse opzioni,anche se non indispensabili ,che ci danno la

possibilità di formattare a  piacere la data e l ora,sia in caso di input che di

presentazione.A mio parere ,il loro valore di default è piu che sufficiente ad un

ottima localizzazione di data ed ora,in tutte le lingue.

Adesso ,a proposito dell internazionalizzazione e localizzazione ,apriamo una parentesi.

Come abbiamo scritto sopra , l opzione USE_I18N , ci pemette la traduzione di

stringhe costanti,USE_L10N invece si interessa alla traduzione e posizione di tutto

ciò che riguarda la data e l’ ora.Tutto bene finchè questi dati sono contemplati nelle

stringhe o formattazioni base di Django,ma che succede quando abbiamo dei dati che

non sono  tradotti di base?Ad esempio se in una form abbiamo un controllo che esula

da quelli ovvi, come il controllo di sintassi di una email,oppure la lunghezza di un

campo password che deve essere piu lungo di 6 caratteri ? Questi controlli sono tra

quelli che Django internazionalizza di default ,attraverso l opzione USE_I18N ;

e,in una eventuale form,gli errori di inserimento ci verrebbero restituiti

correttamente translati nel linguaggio corrispondente alla lingua del client.

Ma se ,ad esempio in una form ,in un  campo text- input ,vogliamo sia inserita una

stringa  previo un controllo personalizzato che,se non soddisfatto  il corrispondente

oggetto-model  ORM non potrebbe essere creato. Se vogliamo avvisare l utente

con output appropriato,in caso di condizione insoddisfatta.

In questo caso Django non possiede una costante specifica  da ritornare all

utente.Ne in lingua inglese ,figuriamoci se ha le translazioni corrispondenti

in altre lingue. Quindi,se vogliamo dobbiamo scrivercela da soli , e così per ogni

personalizzazione che esuli dai casi generici piu ricorrenti.(email,passw.,ecc.).

Certo,potremmo crearci un metodo di controllo nella

classe-model ,oppure nel codice della view, oppure anche nel file di template.

Se ci aggrada potremmo scriverla anche nella lingua che ci serve , pensate se

volessimo internazionalizzare  questa costante ,quanto ci toccherebbe scrivere ?

La strada migliore in questo caso,è procedere in questa maniera:

1] Nel file settings.py dove sta l opzione  MIDDLEWARE_CLASSES vi

aggiungeremo l’ elemento ‘ django.middleware.locale.LocaleMiddleware ,

ma attenzione ,gli elementi in questa opzione vanno così disposti:

django.contrib.sessions.middleware.SessionMiddleware ‘  ,va per

primo,quello che abbiamo aggiunto adesso sopra,va per secondo, e per terzo,

ci va ,’ django.middleware.common.CommonMiddleware ‘ .

Le altre voci possiamo lasciarle dove sono ,comunque ,nel caso avessimo

avuto bisogno di ‘.CacheMiddleware ‘ ,questa sarebbe dovuta esser la seconda,

dopo ‘ .SessionMiddleware ‘   e , ‘ .LocaleMiddleware ‘  per terza.

Questo perche la nuova voce aggiunta ,per funzionare  potrebbe aver bisogno

delle sessioni ,e siccome i file di configurazione vanno letti dall alto in basso,

avrebbe dovuto prima accertarsi dell esistenza del middleware delle sessioni,

prima di attivare il meccanismo della translazione locale.

2] Indicare a Django quali sono le stringhe da translare.

Python ,usa la libreria ‘gettext‘ per la translazione delle lingue.Questa libreria

installa nel namespace globale (builtins) ,la funzione underscore ” _() ” .

Essa viene appunto usata per marcare le stringhe da translare.

Django invece non usa questo sistema ,onde evitare conflitti ,ma possiamo

sempre usarla come ‘ alias ‘ della funzione ‘ ugettext ‘ ,importata come modulo.

[ from django.utils.translation import ugettext as _ ] .Ciò non ci vieta di usare

stessa ‘ ugettext ‘ per marcare la stringa , ma per convenzione si usa l’ underscore .

Quindi basterà mettere la stringa o variabile da translare cosi : var = _(“my string code “)

che questa verrà tradotta nella lingua indicata dall identificativo nella directory /locale .

Queste funzioni [ ugettext() ed il suo alias _() ] servono per marcare le stringhe da translare

nelle funzioni della view.Oltre a questi metodi ,ne abbiamo altri ,sempre importati da

django.utils.translation ‘  , ne cito alcuni:

ugettext_noop() ‘ ,che ha la particlarità che serve per marcare stringhe che devono essere

conservate in lingua originale, perchè scambiate tra sistemi, (ad es. trascritte in database)

e poi tradotte solo all ultimo ,quando date in output all utente.

ungettext() ‘ ,che sceglie autonomamente tra una forma singolare ed una plurale ,in base

al parametro in input. ad esempio:

from django.utils.translation import ungettext

def esempio(request,count ):

output = ungettext(“c’è %(count)d oggetto”, “ci sono %(count)d oggetti”, count) % {

‘count': count,

}

return HttpResponse(output)

Dall esempio sopra possiamo vedere che la funzione ungettext sceglie in base al valore

di ‘ count ‘ ,che se count=1 , pone in output la prima frase (quella singolare) ,se count >1

invece ritorna la forma plurale.

pgttext() ‘ , invece viene usata quando delle stringhe nella lingua originale possono avere

diversi significati.Come potrebbe sapere il sistema di translazione di django a quale dei

significati ci rivolgiamo ? Infatti dobbiamo dirglielo noi.Se ad esempio in inglese abbiamo

la stringa ‘ may ‘ ,essa puo assumere diversi significati, infatti puo signifivare il mese

di ‘ maggio ‘ ,oppure una voce del verbo potere .Questo potrebbe confondere Django ,

,e quindi la cosa si risolve spiegandogli il significato esatto da assumere quando

andiamo a marcare la stringa ,scriviamo :

month = pgettext(“month name”, “May”) ,cioè ,indichiamo al sistema di traduzione,

a quale significato accostare la stringa da translare.Di conseguenza ,dopo il

comando  makemessages (spiegato poco sotto ),avremo il file .po con una voce in più.

‘ msgctxt ‘=” name of month “ ,che spiega quale tra i diversi significati assumere.

ugettext_lazy() ‘ ,viene usata come ugettext() sopra ,per le stringhe che non devono

essere tradotte alla chiamata, ma soltanto quando diventa accessibile al client.

Esse vanno usate solo con oggetti stringa di tipo unicode.

Se ad esempio vogliamo definire un model-oggetto Libro ,faremo:

from django.utils.translation import ugettext_lazy

class Libro(models.Model):

titolo = models.CharField(help_text=ugettext_lazy(‘This is the help text for Libro’))

La strnga verra translata al momento che verra restituita in output attraverso un template

oppure nell interfaccia di amministrazione , oppure in una form , ecc.

Ricordiamo che nel caso di piu occorrenze di translazione in uno stesso model ,possiamo

per comodità usare sempre l alias ” _() “.Esempio, nel caso dovessimo translare il nome

di una tabella ( classe -model ) sia in singolare che plurale:

from django.utils.translation import ugettext_lazy as _

class Book(models.Model):

title = models.CharField(_(‘title of book’)¹, help_text=_(‘This is the help text’²))

class Meta:

verbose_name = _(‘my Book’³)

verbose_name_plural = _(‘my books’)

In quest esempio le stringhe da translare sono 4. Il verbose_name dell attributo title

della classe Book(spiegheremo meglio dopo a proposito l’ uso  dei Models ) ,marca la stringa

¹ che rappresenta un verbose-name ,nome che rappresenta il nome del campo nella tabella

campo che fa riferimento all attributo title della classe.Il verbose_name darà il nome al campo

della tabella ,esso viene passato ,o in forma esplicitata (verbose_name =’ nome ‘ ),oppure come

primo parametro posizionale (come da esempio ) .Se assente il campo prende come nome,il nome

dell attributo (in questo caso title ), ed eventuali underscore verrebberotramutati in spazi.

²Questo  , è un altro parametro dell’ attributo  della classe-Model,sta ad indicare un eventuale

testo di help,che possiamo poi ritrovare in interfaccia di amministrazione ,oppure in una form

di inserimento.La terza ³ , è sempre un verbose_name che pero si riferisce al nome della

tabella-classe-model ,stessa cosa come il verbose_name del campo title.

L’ ultima stringa marcata  è sempre un verbose_name ,ma per le voci al plurale ,non per

essere inserite come nome di tabella o campo del database.

Altre eventuali utility per translare le stringhe li trovate da soli ,altrimenti questa guida

non termina piu !.

Come abbiamo scritto su,queste marcature vengono usate nelle views oppure nei Models ,

Nei Templates , i principale tags sono :

{% trans [costante o segnaposto] %} ,che appunto puo contenere sia una stringa costante

sia un segnaposto o variabile proveniente da una view.

{% blocktrans %} My string and my {{ var }} for translation{% endblocktrans %}

che puo contenere espressioni piu elaborate,come stringa e segnaposti insieme

inoltre possiamo inserirvi statement e filtri (vedremo dopo ).

obbligatorio inserire in capo nel file di template, il tag di translazione:

{% load i18n %} .

Adesso abbiamo visto come indicare a Django le stringhe che vogliamo internazionalizzare.

Adesso dobbiamo compilare i ‘messagges’,cioè tradurre le stringhe nella lingua/e che piu ci occorre.

Lo faremo attraverso 2 utility che django ci mette a disposizione come argometi al comando

django-admin.py .  Essi sono makemessages e compilemessages .

Cosa sono i messages ?

L ‘ internazionalizzazione ,cioè la trduzione simultanea nel linguaggio occorrente , è una

procedura standard collaudata già su molti software e sistemi.Esse funzionano tutte

allo stesso modo .Ci sono dei file con estensione .po,dove si trovano le stringhe originali

con la relativa traduzione ,relativa appunto alla codifica /locale  dell identificativo

( o directory che ha come nome proprio il codice di identificazione per il particolare

linguaggio ) seguito da /LC_MESSAGES/file.po .

D’ altronde li potete trovare in /conf/locale/id/LC_MESSAGES/django.po dell

installazione di django,dove stanno le translazioni delle costanti-stringa e le

tarduzioni-formattazioni della data e dell ora in base alla localizzazione  /locale,

per quelle che sono di uso piu comune e generico. [id sta per identificativo locale

della lingua di translazione (it, fr, en-us, en , mn , ecc. ecc.)].

Questo lavoro di creazione del file con le stribghe originali che saranno da tradurre ,

django ci evita di farlo manualmente ,attraverso il comando makemessages.

Quindi entriamo nella root directory del progetto (quella creata con startproject),

oppure nella root-dir dell applicazione (quella creata con startapp ).

Qui apriamo un terminale shell (o finestra dos su windows ) ,creiamo manualmente

la directory /locale , e lanciamo il comando:

[gianluca@samson django_breve]$ django-admin.py makemessages -l it

questo creerà  sotto /locale l albero , /locale/it/LC_MESSAGES/django.po .

Questo file  (di default si chiamerà django.po ) contiene tutte le stringhe marcate

nei file views.py models.py e template ( .html ) .Di base il comando cerca queste stringhe

in files con estensione .html e .py ,se volgiamo estrarre stringhe da altri tipi di files

dobbiamo passare un argomento diverso al comando. [djangojs]

Il file .po contiene dicevamo il segnaposto msgid =” stringa originale”

e sotto msgstr = ” ” , dove saremo noi ad inserire la giusta traduzione in base all id locale.

Avremo una coppia per ogni stringa da translare.

Attenzione alla stringa nel blocco del template ,ad es. se abbiamo :

{% blocktrans %} My string and my {{ var }} for translation{% endblocktrans %}

nel file django.po  ,qui avremo msgid = “My string and my %(var)s for translation”

una sorta di formattazione delle strighe con i specificatori come si fa in python,

e nel corrispondente msgstr = “La mia stringa e la mia %(var)s per la translazione”

lo specificatore di formato della stringa-variabile ,resta uguale ,

dato che nel template la variabile var stava translata gia nel tag {% trans var %}

( avremo un esempio piu in là dei template  ).

Una volta tradotte tutte le stringhe nel file django.po possiamo avviare il comandi

compilemessages, che tradurrà i file .po in binari .mo che saranno i file letti da django :

[gianluca@samson django_breve]$django-admin.py compilemessages

senza opzioni ,che django tradurra tutti i file .po ,in corrispondenti binari .mo.

A questo punto tutto e pronto affinchè Django possa servire ad ogni visitatore la pagina

translata nel giusto linguaggio.Per provare basta seguire questa procedura per il linguaggio

di identificativo che desiderate ,(ad esempio fr [ francese ]),andiamo a marcare le stringhe,

lanciamo makemesages ,tarduciamo tutte le occorrenze nel file django.po,lanciamo

il comando compilemessage,ed il gioco è fatto.

Adesso basta impostare il browser nella ligua di interpretazione in francese,apriamo il

browser alla pagina dell applicazione da testare , e vdrte la pagina con le occorrenze

tradotte in francese.Stessa procedura se avessimo voluto translare in un altra lingua.

Riguardo al linguaggio del client (browser) ,possiamo attraverso le variabili di ambiente

del server web,risalire al linguaggio (id locale ) dell utente.

request.LANGUAGE_CODE, esso ci ritorna l’id di codifica del client,(it, fr, en, en-us, ecc. )

dopo di ciò in base a questo id, possiamo scegliere un eventuale traduzione da tornare

in output,ad esempio una view:

def miaView(request):

if request.LANGUAGE_CODE = ‘it':

return HttpResponse(‘<h5>sei un utente italiano </h5>’)

else:

return HttpResponse(‘<h5>this is for all who do not speak Italian</h5>’)

Certo che una funzione così è da usare solo nel caso ,i linguaggi da translare siano pochi,

altrimenti ci sarebbe troppo codice da scrivere ,a quel punto ci converrebbesare i messages.

MEDIA_ROOT = ‘ ‘

MEDIA_URL = ‘/media/’

queste 2 opzioni ci servono, la prima per il path assoluto dove

inserire immagini ,video ,media appunto,anche se nessuno ci impedisce di metterci altri tipi di

files,sopratutto però,viene usata per i files che vengono mandati  in Upload,ad esempio potremmo

creare  un file javascript in MEDIA_ROOT ,direttamente senza mandarlo in upload attraverso

una form, e poi richiamarlo prefissando il path realativo fissato in MEDIA_URL.

Comunque atteniamoci alle raccomandazioni di Django,ed usiamo queste opzioni solo per i file in

upload.

La seconda voce invece indica il percorso relativo al path di installazione del progetto

,che useremo per richiamare i files che si trovano all’ interno di MEDIA_ROOT .

Per convenzione per la costante MEDIA_URL , si usa il

valore  ‘/media/ ‘ .

Stessa logica di funzionamento più o meno ,la abbiamo per i prossimi 2  valori :

STATIC_ROOT =’ ‘

STATIC_URL=’ /static/ ‘

Queste 2 voci come da nome ,vengono usate per gestire la collocazione ed i links dei

files statici ,pensate a tutti i file css ,i javascript ,i pdf ,m anche qualsiasi altro file,che comunque

non sia un modulo python ,che in questo caso sarà gestito in maniera standard da Django.

Dicevamo , i file  statici ,però non devono essere creati in STATIC_ROOT  , ma come spiega la doc

di Django,essi vanno creati in una sottodirectory della  applicazione (non progetto attenti ) di nome

fisso ‘/static/ ‘  , oppure in una delle directory eventualmente settate nella costante  opzionale di settings

STATICFILES_DIRS =( ) ,una tupla ,i cui valori sono path assoluti dove creare i nostri files statici.

Una volta che abbiamo creato i nostri files ,siano css , o javascript ,o qualsivolgia tipo,possiamo gia

richiamarli attraverso il path relativo settato in STATIC_URL. A questo punto allora , a cosa serve il

settaggio di STATIC_ROOT ?

Django per velocizzare il suo lavoro ,in ambiente di produzione ,ci mette a disposizione un opzione

del comando da shell  django-admin.py ,che abbiamo già visto in precedenza.

Questo comando con l’ opzione collectstatic ,crea una copia dei files statici che si trovano nelle directory

segnalate nella costante  STATICFILES_DIRS .La copia viene messa nella directory appunto segnalata

in STATIC_ROOT.Per funzionare , collectstatic ha bisogno che sia attivata (di default lo è ) in

INSTALLED_APPS , la voce  ‘django.contrib.staticfiles’ .

Una volta riempita la directory  ,i files verranno richiamati alla stessa maniera ,prefissando il

path relativo  ‘ /static/ ‘  . Attenzione che dalla versione 1.3  di Dajngo le 2 voci di settaggio ,

MEDIA_ROOT e STATIC_ROOT ,vanno inserite con lo slash finale  ,mentre fino ad allora ,esso non

era indispensabile.

Qualcuno potrebbe chiedersi giustamente ,perchè creare queste costanti,quando basterebbe creare

la directory ,sotto il project-path ,e richiamare i files al suo interno come si fa solitamente in http.

Vero! Il fatto è che questa opzione che fa riferimento ai soli files statici,con le sue  costanti ,ci

tornerà molto utile ,quando in seguito andremo a testare Django insieme al web-server Apache.

Nessuno ci vieta di usare il solo web-server interno a Django ,in ambiente di produzione ,ma è

molto meglio abbinare django ad Apache ,in quanto quest’ultimo è molto più varsatile  e

performante quando si tratta di files statici.In seguito spiegherò appunto come usare Django

(che si occuperà del codice python ) con Apache ,attraverso il modulo mod_python  ,WSGI,

senza dimenticare  le interfacce CGI ed FAST-CGI .Vedremo dopo.

STATICFILES_FINDERS  ,che lasceremo così com’ è ,ci indica dove django andrà a cercare i files

statici da copiare attraverso collectstatic .Sappiamo già che di base li cerca nella /static/ sotto

la directory dell applicazione , e nella directory segnata  da STATICFILES_DIRS.

Un ultima cosa a proposito di files statici,l opzione collectstatic ,la doc di Django ,dice che

va passata come argomento al comando django-admin.py da shell,ma io provando ,ho

trovato che esso viene permesso solo a seguire il comando:

[gianluca@samson django_breve]$ python manage.py collectstatic .Mha ….. significa che

ci perderò ancora un po di tempo in seguito.

Continuiamo con delle precisazioni per quanto riguarda l’ uso delle costanti  che definiscono

i path assoluti ed i path per i link ai files statici.

Fino ad adesso abbiamo dato per assunto che la costante DEBUG = True .Così impostata ,ci è

utilissima in fase di sviluppo delle applicazioni,dato che in caso di errore Django ci ritorna molte

informazioni riguardo l’ applicazione in esame.Volete mettere che dobbiamo essere noi a trovare

l’ errore ,e che invece Django ci suggerisca il rigo il file ,ed  il tipo di errore ,piu tutte le variabili di

ambiente eccetera? Questa cosa ci si ritorcerebbe contro in  ambiente di produzione . Eh si!  Non

vorremmo mica dare tutte queste informazioni ad un malintenzionato ?

Poniamo che stiamo sviluppando un applicazione Django , e che  stiamo usando il webserver interno

[gianluca@samson django_breve]$ python manage.py runserver

ed appunto la costante DEBUG=False anzichè True come di default. Succede che Django non trova più

i files (ad es. un css o un immagine) se chiamati attraverso la costante STATIC_URL ,quella che linka i files

che si trovano all interno della STATIC_ROOT ,dopo che ,come abbiamo già visto, con il comando

manage.py –collectstatic vi sono copiati dalle directory   settate in STATICFILES_DIRS , e nelle

directory /static sotto le applicazioni ,non sotto il progetto ,dove invece sta la STATIC_ROOT ,che

è quella appunto dove vengono copiati.

Con DEBUG=False ,dicevamo che Django non trova piu il path STATIC_URL ,quindi mancheranno css,

immagini eccetera.Come si può quindi fare ?

Il problema non si pone se ,seguendo i consigli delle doc di Django,usassimo 2 webserver separati ,uno

per Django ,ed uno per i files statici ,quelli settati in  MEDIA_ROOT e STATIC_ROOT.

(ad es. potremmo avviare 2 webserver  ,ad esempio Apache che attraverso mod_wsgi  richiama l’ Handler

per Django,e poi un webserver minimale tipo Lighttpd ,che  viene configurato per servire i files sll interno

delle STATIC_ROOT e MEDIA_ROOT , ad esempio girando su di un altra porta ,apache

(www.mywebserver.com;80)  e lighttpd (www.mywebserver.com:8000).

Nel nostro caso ,abbiamo il solo Apache ,che deve fare tutto il lavoro, basta configurare

(vedremo meglio nel capitolo apposito) il VirtualHost con l’ Handler per Django ,mentre per gli url che

passano per STATIC_URL o MEDIA_URL ,ad esempio http://django.homepc.it/static/primo.css,

non sia chiamata la funzione handler per Django,mentre per tutte gli altri url si.

Torniamo al webserver di sviluppo  ( runserver ) ,se vogliamo possiamo comunque far si che anche

se DEBUG = False ,venga comunque riconosciuta la STATIC_URL e serviti così i files dentro loa /static.

Qundo da shell avviamo il webserver  di Django , gli passiamo l’ opzione –insecure  :

[gianluca@samson django_breve]$ python manage.py runserver –insecure

Il nome dell opzione dice tutto sull’ opportunità di usare questa modalità in ambiente di produzione.

Comunque ,se stiamo testando ad esempio dei css con il webserver interno a Django ,va benissimo .

Qualcosa la spieghiamo anche rispetto all uso della costante  per i files statici ,quando andiamo

ad usarla come tag nei files di templates.

Possiamo fare in 2 modi ,per inserire un tag come componente di un path per richiamare un

immagine (oppure un css , un JavaScript ecc.).

1   Il primo non richiede alcuna modifica delle impostazioni .Essa è sempre disponibile ,basta

aver dato un valore alla costante  STATIC_ROOT ,che di default è vuota. Nel template  ,per primo

tocca inserire il tag  {% load static %} , così diventa disponibile il tag {% get_static_prefix %}

Adesso se vogliamo inserirlo come path in un tag immagine html ,scriviamo nel template :

<img src=”{% get_static_prefix %}logo2.gif” />.

2    Il secondo modo è un po più elaborato,esso ci permette di usare un tag con lo stesso nome della

costante.  {{  STATIC_URL }} .Per oterla usare però abbiamo bisogno di alcune impostazioni,

nel file settings.py inseiremo la nuova costante  TEMPLATE_CONTEXT_PROCESSORS  . È

una tupla ,i cui valori sono  funzioni ,ognuna delle quali rende disponibili dei nuovi tag di

template.Inseriamolo così come lo troviamo sulle DOC ,le altre voci oltre a quella che occorre

adesso ( ‘django.core.context_processors.static’ ) ,potrebbero tronarci utili in seguito.

Oltre a  questa importiamo nel file views.py  la RequestContext :

from django.template import RequestContext

Il RequestContext , che vedremo poi nell uso dei templates ,si differenzia dall’ altra funzione

Context ,usata per il render  del template ,e che fornisce appunto a quest’ ultimo i valori da

dare in output.Con RequestContext invece si rendono implicitamente disponibili tutti i valori

definiti nelle funzioni importate dalla tupla TEMPLATE_CONTEXT_PROCESSORS ,

Tra cui appunto STATIC_URL disponibile come tag di template. Allora nella views.py

come ritorno della funzione avremo :

return render_to_response(‘template1.html’,{‘vv':var},context_instance=RequestContext(request))

Piu avanti spiegheremo cosa significa il rigo sopra ,per adesso sappiamo che adesso possiamo

richiamare un file dalla STATIC_ROOT  facendo così:

<img src=”{{ STATIC_URL }}logo.gif” />.

Proseguiamo.

ADMIN_MEDIA_PREFIX =’/static/admin/’

Questa indica a Django ,una volta che decidiamo di usare il meccanismo di amministrazione,dove

trasferire i media files  del sistema di amministrazione.

Quando spiegheremo come funziona il tool automatico dell amminitrazione di Django ,le cose ci

saranno più chiare ,per adesso basti sapere  solo alcune basilari.

Con il webserver di sviluppo ( runserver ) il tool di amministrazione si  preoccupa da solo  di come

servire i media  files. A noi basta settare  ADMIN_MEDIA_PREFIX e poi lanciare da shell :

[gianluca@samson django_breve]$ python manage.py collectstatic

Ci penserà Django ,come per i files statici  ,che vengono copiati dentro la /static del progetto,

le 3 directory ( /css , /img, /js ) che stanno dentro  django/contrib/admin/media,verranno copiati

all interno di una directory /admin che Django crea appunto all’ interno della /static .

Quindi adesso Django troverà i media files dell’ amministrazione all interno della directory

/static/admin/css|img|js .

Diverso il caso che sia un altro webserver ( lo stesso,oppure un secondo ,di quello che fa l’ Handler

a Django).In questo caso ,siamo noi a doverci preoccupare di prendere i media files dalla directory

‘django/contrib/admin/media’ ,e copiarli dove siano raggiungibili dal webserver a loro dedicato.

Potremmo creare un link symbolico agli originali ,oppure copiarli direttamente ,fatto stà che dopo

dovremmo andare a mettere mano al file di configurazione del webserver ,oppure nell .htaccess.

SECRET_KEY Non ho trovato una cazzo di piegazione su come Django usa questa costante.

So soltanto che viene creata random automaticamente al lancio di startproject .

TEMPLATE_LOADERS = (

‘django.template.loaders.filesystem.Loader’,

‘django.template.loaders.app_directories.Loader’,

)

Questa tupla contiene 2 elementi di default.Il loro scopo è di indicare le modalità di ricerca per i

files di templates.Il primo indica che vanno cercati nel filesystem,indicazioni da seguire nella costante

TEMPLATES_DIRS. La seconda invece ci dice che sotto ogni directory di applicazione ,se ne abbiamo

una di nome ‘/templates ‘ ,Django cercherà al suo interno l eventuale file.

Dunque ,se abbiamo un ritorno di una views ,che richiama un template di nome file.html,Django

cercherà prima nella directory indicata dalla costante TEMPLATES_DIRS ,e poi un livello sotto le

directory delle applicazioni ,se ne esiste una di nome ‘ /templates ‘  .

TEMPLATES_DIRS

Possiamo dire di averlo appena spiegato sopra.

ROOT_URLCONF =’ nomeprogetto.urls ‘

Ci indica il percorso del file urls.py ,dove stanno le mappature tra gli urls e le views.Rocordarsi che

deve stare sempre all interno del PYTHONPATH  ,cioè il path dove python cerca i moduli.

MIDDLEWARE_CLASSES

Questa tupla ,i suoi elementi rappresentano delle classi python che permettono a Django

di attivare nuove funzionalità.Infatti ad esempio

abbiamo quello per la cache,per le sessioni ,per attivare la localizzazione ed internazionalizzazione.

Ne abbiamo già incontrato qualcuno ,che abbiamo dovuto inseire nella tupla per poter usare

alcune funzionalità di Django.Ad esempio quando abbiamo spiegato come translare le stringhe.

Trattasi di Midlleware in quanto dal nome stesso si va ad inserire tra  2 componenti software ,nel nostro

caso tra la request/response, filtrandole attraverso la sua funzione specifica.

INSTALLED_APPS

Tupla che contiene tutte le applicazioni attive in questo progetto Django.

Gli elementi della tupla rappresentano  dei package che sono proprio applicazioni Django.

Infatti fra queste abbiamo quella per l Admin, auth , che come quella da noi creata quando

si lancia il comando startapp ,contengono tutti i files propri di una applicazione ,models.py

views.py ecc.E in alcuni abbiamo presente anche il middleware come per le sessioni , le auth.

LOGGING

Dalla versione 1.3 esiste questa nuova tupla ,che serve al sistema di log di Django.

Esso non appartiene a Django ,ma è un modulo di python.

La sola configurazione di default  permette a Django di inviare un messaggio email

all indirizzo inserito nella opzione ADMINS ,ogni volta che l’ applicazione torna un errore 500.

Nulla toglie che possiamo configurare il ‘ level ‘  da ERROR . a WARNING a INFO .

Per funzionare necessita che il valore della costante DEBUG = False, altrimenti non sarebbe necessario

perchè il debug l’ avremmo immediatamente e completo.

Inoltre per far si che vengano inviate queste email all’ admin ,abbiamo bisogno di inserire altri

settaggi:

SERVER_EMAIL = ‘l indirizzo email da usare per l’ invio’

EMAIL_HOST =’server posta in invio’

Queste 3 sotto servono solo nel caso che il server per invio della posta richieda autenticazione.

EMAIL_HOST_USERNAME=’username account’

EMAIL_PORT=Numero porta (intero)

EMAIL_HOST_PASSWORD=’password’ (stringa)

Abbiamo poi :

SEND_BROKEN_LINK_EMAILS = True

Settata a True ,fa si che ci vengano inviate email non solo per i codici di errore 500 , ma anche

nel caso di pagina 404 ,pagina inesistente.

Riguardo al file settings.py le voci di default ,e le piu importanti ,sono queste.Ciò non toglie che

se ne possano rendere necessarie delle altre .Invito a leggere la doc ufficiale per visionarle.

<<parte3 parte5>>


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>