Version 1 (modified by paolo <paolo@…>, 18 years ago) ( diff )

Django FAQ, Italian translation.

Domande frequenti su Django

traduzione in lingua italiana.

Documento originale: Django FAQ

Traduzione: paolo <paolo@php3.it>

Aggiornato alla revisione: 3137

Contenuti del capitolo

Domande frequenti su Django

Domande generali

Perché esiste questo progetto?

Django è cresciuto grazie ad un'esigenza pratica: il ruolo di World Online, un'agenzia giornalistica su Web, consiste nel realizzare applicazioni Web per la pubblicazione di articoli e notizie. Nel vorticoso mondo dell'informazione, Word Online spesso deve trasformare applicazioni Web concettuali in materiale pronto per il lancio al pubblico, in poche ore.

Contestualmente, gli sviluppatori Web di World Online sono stati puntigliosi quando si è trattato di seguire meticolosamente le best practices (ndt, le migliori pratiche, intendendo le esperienze più significative o dai migliori risultati adottati in diversi contesti) dello sviluppo Web.

Quindi Django è stato progettato non soltanto per consentire un veloce sviluppo Web, ma anche uno sviluppo che seguisse le migliori modalità per ottenere ottimi risultati.

Django non sarebbe mai stato possibile senza alcuni altri progetti open-source -- Apache, Python e PostgreSQL, per citarne qualcuno -- e noi ci siamo sentiti elettrizzati nel poter restituire qualcosa alla comunità open-source.

Che cosa significa "Django", e come lo si pronuncia

Il nome Django deriva da Django Reinhardt, un chitarrista jazz gitano del periodo dagli anni '30 ai primi anni '50. Ai giorni nostri è considerato uno dei migliori chitarristi di tutti i tempi.

Ascolta la sua musica. Ti piacerà.

Django è pronunciato JANG-oh. La rima è con FANG-oh.

Django è stabile?

Sì. World Online ha utilizzato Django per più di due anni. Siti costruiti con Django sono stati esposti a picchi di traffico di più di un milione di richieste all'ora, ed ad almeno un effetto Slashdot. Sì, è piuttosto stabile.

Le applicazioni realizzate con Django possono scalare?

Sì. Confrontando il costo legato ai tempi di sviluppo ed il costo ben più modesto dell'hardware, abbiamo pensato di progettare Django affinché sia in grado di sfruttare al meglio tutta la potenza di calcolo che gli viene messa a disposizione.

Django adotta una architettura "shared-nothing", cioè puoi decidere di potenziare l'hardware ad ogni livello -- sui server database, sui server di cache o sui Web server.

Il framework separa in modo netto i componenti, come ad esempio il livello del database dal livello dell'applicazione. Inoltre è a corredo un simplice ma potente cache framework.

Chi c'è dietro al progetto?

Django è stato sviluppato in World Online, il dipartimento Web di un giornale in Lawrence, Kansas, USA.

Adrian Holovaty

Adrian è uno sviluppatore Web con competenze in campo giornalistico. E' stato il programmatore principale a World Online per due anni e mezzo, durante i quali Django ha vissuto il suo sviluppo e ha potenziato molti siti per World Online. Attualmente lavora per washingtonpost.com, dove realizza importanti siti di informazione basati su database, mentre continua a sopraintendere lo sviluppo di Django. Gli piace suonare la chitarre (nello stile di Django Reinhardt) e lavorare su progetti secondari, come chicagocrime.org. Vive a Chicago.

Su IRC, Adrian è noto come adrian_h.

Jacob Kaplan-Moss

Jacob è un ragazzo californiano che trascorre il suo tempo scrivendo codice e cucinando. E' lo sviluppatore principale a World Online e lavora attivamente su progetti collaterali di considerevole interesse. Ha contribuito ai binding Python-ObjC ed è stata la prima persona a scrivere applicazioni per Tivo in Python. Di recente ha cominciato a interessarsi a Python su PSP. Vive in Lawrence, Kansas.

Su IRC, Jacob è noto come jacobkm.

Simon Willison

Simon è uno sviluppatore Web molto apprezzato proveniente dall'Inghilterra. Ha lavorato internamente a World Online per un anno, durante il quale assieme ad Adrian ha sviluppato Django da zero. E' l'inglese più entusiastico che si possa incontrare, è appassionato di best practices in ambito Web ed ha mantenuto per anni un blog di successo sullo sviluppo Web, che puoi leggere all'indirizzo http://simon.incutio.com. Lavora per Yahoo UK, dove ha ottenuto il titolo di "Hacker Liaison". Vive a Londra.

Su IRC, Simon è noto come SimonW.

Wilson Miner

Le doti artistiche di Wilson ci fanno apparire come star del rock. Quando non si trova a progettare piscine serpeggianti in qualche appartamento, ricopre il ruolo di "Direttore dello Sviluppo Commerciale" per World Online, cioè produce il denaro dei nostri salari. Vive in Lawrence, Kansas.

Su IRC, Wilson è noto come wilsonian.

Quali siti usano Django?

Il wiki di Django esibisce una lista in costante crescita di siti realizzati con Django. Aggiungi liberamente anche il tuo sito a questa lista.

Sembra che Django sia un framework MVC, ma ciò che voi chiamate "view" è il Controller, e la View il "template". Come mai non usate i nomi standard?

Bene, la nomenclatura standard è opinabile.

Per come noi interpretiamo il paradigma MVC, la "view" descrive i dati che vengono presentati all'utente. Non necessariamente come si presentano, ma quali dati sono presentati. La view descrive quali dati sono esposti, non come vengono esposti. E' una distinzione sottile.

Perciò, nel nostro caso, una "view" è una funzione Python che viene invocata per un particolare URL, poiché questa funzione descrive quali dati sono presentati.

Inoltre, serve per separare i contenuti dalla presentazione -- fase in cui subentrano i template. In Django, una "view" descrive quali dati sono presentati, e normalmente delega la presentazione ad un template, il cui compito è descrivere come i dati sono presentati.

Quindi il "controller" dove rientra? Nel caso di Django, probabilmente è il framework stesso, inteso come serie di meccanismi che inviano le richieste alla view appropriata in base alla configurazione degli URL.

Se sei affamato di acronimi, potresti dire che Django è un framework "MTV" -- ovvero, "model", "template" e "view". Questa suddivisione può avere un senso.

A fine giornata, ovviamente, l'importante è aver terminato il proprio lavoro. E, indipendentemente da come vengano chiamate le varie parti del framework, Django consente di compiere gli incarichi lavorativi nel modo che secondo noi è più logico.

<Il framework X> offre la <funzionalità Y> -- Perché Django no?

Siamo ben consapevoli che esistono altri framework Web grandiosi, e non siamo contrari a prendere alcune idee in prestito. Tuttavia Django è stato sviluppato precisamente perché eravamo scontenti della situazione che esisteva prima della sua progettazione, quindi "che il <framework X>" metta a disposizione qualcosa in più non è una ragione sufficiente per aggiungere quella funzionalità a Django.

Perché avete scritto Django interamente da zero, invece di usare librerie Python a disposizione?

Quando un paio di anni fa Django fu scritto, Adrian e Simon dedicarono parte del loro tempo all'esplorazione dei vari framework Web scritti in Python.

Secondo noi, nessuno di essi era completamente adeguato.

Siamo esigenti. Potresti anche chiamarci perfezionisti (con scadenze).

Con il trascorrere del tempo siamo incappati in librerie open-source che offrivano funzionalità da noi già sviluppate. Era rassicurante vedere che altre persone risolvevano problemi simili ai nostri in modi simili, ma era troppo tardi per integrare codice esterno: considerando il tempo che sarebbe servito avremmo invece scritto, testato ed implementato i bit del nostro framework in ambiente di produzione -- ed il nostro codice ha incontrato le nostre esigenze deliziosamente.

Nella maggior parte dei casi, tuttavia, abbiamo riscontrato che i framework e gli strumenti esistenti avavano qualche genere di fondamentale, fatale pecca che ci avrebbe nauseati. Nessun tool incontra la nostra filosofia al 100%.

Come abbiamo detto: siamo perfezionisti.

Abbiamo documentato la nostra filosofia nella pagina delle filosofie di progettazione.

Avete qualcuno di quegli screencast così attraenti?

Puoi scommettere che arriveranno. Ma, poiché stiamo ancora lavorando su alcuni aspetti, vogliamo essere sicuri che essi riflettano lo stato conclusivo delle cose al momento del rilascio di Django 1.0, evitando ritratti intermedi. In altre parole, non intendiamo ancora impiegare molte energie per gli screencast, perché le API di Django muteranno.

Nel frattempo, puoi guardare questi screencast non ufficiali.

Django è un sistema per la gestione dei contenuti (CMS)?

No, Django non è un CMS, né una sorta di "prodotto chiavi in mano" di suo. E' un framework Web, uno strumento di programmazione che consente di realizzare siti Web.

Ad esempio, non ha molto senso confrontare Django con un sistema come Drupal, in quanto usando Django puoi creare qualcosa simile a Drupal.

Certamente l'interfaccia di amministrazione di Django è fantastica e ti consente di risparmiare moltissimo tempo -- ma il sito di amministrazione è un modulo del framework Django. Inoltre, sebbene Django si presti particolarmente per creare applicazioni "CMS-y", non significa che non sia appropriato per realizzare applicazioni "non-CMS-y" (qualsiasi cosa si voglia intendere!).

Quando rilascerete Django 1.0?

Risposta breve: quando saremo convinti delle API di Django, quando avremo aggiunto tutte le funzionalità che riteniamo essere necessarie per guadagnare lo stato "1.0", e infine quando saremo pronti per cominciare a mantenere la compatibilità relativamente alle versioni precedenti. Tutto questo dovrebbe accadere con buona approssimazione nell'arco di un paio di mesi, benché sia possibile che si verifichi in seguito. Un periodo di rilascio verosimile è l'estate 2006.

L'integrazione del codice magic-removal nei sorgenti della linea di sviluppo principale di Django ha considerevole influenza sul rilascio della versione 1.0.

Naturalmente, dovresti non trascurare il fatto che esistono vari siti in produzione che usano Django nello stato attuale. Non farti inibire dalla non ufficialità della versione corrente.

Come posso scaricare la documentazione di Django e leggerla offline?

La documentazione su Django è disponibile nella directory docs di ogni archivio contenente un rilascio ufficiale. Questi documenti sono in formato ReST (ReStructured Text), ed ogni file di testo corrisponde ad una pagina Web del sito.

Poiché la documentazione risiede in un sistema per il controllo delle revisioni, puoi consultare le modifiche apportate adottando le stesse modalità usate per il codice sorgente.

Tecnicamente, i documenti sul sito di Django sono generati usando le ultime versioni di sviluppo dei documenti ReST, e per questo la documentazione sul sito può offrire informazioni più aggiornate rispetto a quelle che trovi a corredo dell'ultimo rilascio di Django.

Domande sull'installazione

Da dove comincio?

  1. Scarica il codice.
  2. Installa Django (leggi la guida di installazione).
  3. Segui il tutorial.
  4. Leggi il resto della documentazione, e fai domande se incontri qualche problema.

Come risolvo l'errore "install a later version of setuptools"?

Semplicemente esegui lo script ez_setup.py nella distribuzione di Django.

Quali sono i prerequisiti richiesti da Django?

Django richiede la versione 2.3 di Python o successiva. Non serve nessun'altra libreria.

In ambiente di sviluppo -- se vuoi soltanto fare esperimenti -- non hai l'esigenza di dover usare un server Web separato; Django viene fornito con un server Web adatto ad essere usato in ambienti di sviluppo. In ambiente di produzione, raccomandiamo Apache 2 e mod_python, sebbene Django segua la specifica WSGI e quindi possa essere usato su un vasto numero di piattaforme server.

Ti servirà anche un motore di database. PostgreSQL è raccomandato, MySQL e SQLite 3 sono supportati.

Devo usare mod_python?

Non se intendi sviluppare applicazioni di prova o applicazioni che nascono per essere usate sul computer locale. Django integra un server Web, e il sistema dovrebbe semplicemente funzionare ed essere pronto per l'uso.

Per ambienti di produzione, tuttavia, raccomandiamo mod_python. Gli sviluppatori di Django stanno usando mod_python da più di due anni, e come soluzione è risultata ampiamente stabile.

Se però non vuoi usare mod_python, puoi usare un server differente, purché offra gli hook WSGI. Consulta la pagina del wiki sulle configurazioni dei server.

Come installo mod_python su Windows?

Dovrei usare la versione ufficiale o quella di sviluppo?

Gli sviluppatori migliorano Django ogni giorno e sono molto abili a non inserire codice mal funzionante. Noi usiamo il codice di sviluppo (proveniente dal repository Subversion) direttamente sui nostri server, perciò lo consideriamo stabile. Con questo in mente ti raccomandiamo di usare la versione più recente del codice in sviluppo, poiché generalmente contiene un maggior numero di funzionalità e meno bachi rispetto alla versione "ufficiale".

Usare Django

Perché ottengo un errore sull'importazione di DJANGO_SETTINGS_MODULE?

Assicurati che:

  • La variabile d'ambiente DJANGO_SETTINGS_MODULE sia impostata su un modulo Python completamente specificato (fully-qualified) (ad esempio, "mysite.settings.main").

  • Detto modulo sia elencato in sys.path (in questa evenienza, import mysite.settings.main non dovrebbe segnalare errori).

  • Il modulo non contenga errori di sintassi (ovviamente).

  • Se stai usando mod_python ma non il request handler di Django, devi operare per aggirare un baco di mod_python relativo all'uso di SetEnv; prima di importare qualsiasi cosa da Django devi eseguire:

    os.environ.update(req.subprocess_env)

    (dove req è l'oggetto request di mod_python)

Non posso adottare il vostro linguaggio di template. Devo usarlo per forza?

Ci capita di pensare che il nostro motore di template sia la miglior trovata dopo il chunky bacon, ma riconosciamo che scegliere un linguaggio di template è qualcosa di religioso. Non c'è nessun motivo per cui Django ti imponga di usare il nostro linguaggio di template, perciò se hai buona confidenza con ZPT, Cheetah o altro, sei libero di poterli usare.

Devo usare i vostri strumenti per creare i modelli e gestire l'interfacciamento ai database?

No. Proprio come per il sistema di template, il sistema di gestione dei modelli e dei database è disaccoppiato dal resto del framework. L'unica eccezione è che usando una differente libreria di interfacciamento ai database non ti potrai avvalere del sito di amministrazione generato automaticamente. Infatti l'applicazione dedicata a ciò utilizza il nostro database layer.

Come si usano i campi immagine e file?

Usare un campo FileField o ImageField in un modello consiste in alcuni passi:

  1. Nel file di configurazione, definisci come valore di MEDIA_ROOT il percorso completo alla directory dove vuoi che Django memorizzi i file caricati (per motivi legati alle prestazioni, questi file non vengono mantenuti nel database). Definisci come valore di MEDIA_URL l'URL pubblico base per quella directory, ed assicurati che l'utente che esegue il server Web abbia i diritti per scrivervi.
  2. Aggiungi il campo FileField o ImageField al modello, ed assicurati di definire per l'opzione upload_to la sottodirectory di MEDIA_ROOT dove desideri che i file vengano mantenuti.
  3. Tutto quello che verrà mantenuto all'interno del database sarà il percorso del file (relativo a MEDIA_ROOT). Probabilmente ti troverai spesso ad usare la comoda funzione get_<fieldname>_url fornita da Django. Ad esempio, se il nome del campo immagine è mug_shot, potrai accedere all'URL assoluto dell'immagine in un template con {{ object.get_mug_shot_url }}.

Se modifico il modello, come aggiorno il database?

Se non ti interessa mantenere eventuali dati preesistenti, l'utility manage.py offre un'opzione per resettare i dati di una particolare applicazione:

manage.py reset appname

Questo comando elimina le tabelle associate a appname e le ricrea.

Se invece vuoi mantenere dati preesistenti, dovrai eseguire i costrutti ALTER TABLE manualmente. Noi abbiamo sempre scelto questa strada perché avere a che fare con i dati è un'operazione delicata e perciò abbiamo preferito evitare automatismi. Detto questo, è in corso una parziare implementazione della funzionalità di aggiornamento automatico dei dati.

I modelli di Django supportano chiavi primarie a colonna multipla?

No. Sono supportante soltanto chiavi primarie costituite da una singola colonna.

Ma nella pratica questo non rappresenta un problema, poiché non c'è nessun impedimento nell'aggiungere altri vincoli (usando l'opzione unique_together nel modello o agendo direttamente sul database), e richiedendo l'unicità a questo livello. Le chiavi primarie a colonna singola sono necessarie per far funzionare ad esempio l'interfaccia di amministrazione; (questo perché offrono un modo semplice per poter modificare o eliminare un oggetto).

Le API del database

Come posso vedere l'SQL nativo delle query eseguite da Django?

Assicurati che l'impostazione DEBUG sia True. Poi, semplicemente scrivi:

>>> from django.db import connection
>>> connection.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
'time': '0.002'}]

connection.queries è disponibile solo se DEBUG è True. Si tratta di una lista in cui i dizionari che contengono le informazioni appaiono in ordine di esecuzione. Ogni dizionario è composto da:

``sql`` -- Il codice SQL nativo
``time`` -- Il tempo richiesto per l'esecuzione della query, in secondi.

connection.queries include tutti i costrutti SQL -- INSERT, UPDATES, SELECT, ecc. Ogni volta che l'applicazione fa uso del database, la query verrà memorizzata.

Il sito di amministrazione

Non riesco a entrare. Quando inserisco un nome utente e una password validi vengo riportato alla pagina di login senza messaggi di errore.

Il cookie di login non è stato impostato correttamente, perché il dominio del cookie mandato da Django non coincide con il dominio nel tuo browser. Puoi provare a:

  • Impostare il parametro SESSION_COOKIE_DOMAIN nel file di configurazione sul nome del tuo dominio di provenienza. Ad esempio se nel browser compare "http://www.mysite.com/admin/", in "myproject.settings" dovresti scrivere SESSION_COOKIE_DOMAIN = 'www.mysite.com'.
  • Alcuni browser (Firefox?) non gradiscono di accettare cookie da domini che non contengano punti all'interno del loro nome. Se stai facendo girare il sito di amministrazione sul "localhost" o su un altro nome che senza punti, prova ad usare "localhost.localdomain" o "127.0.0.1". Inoltre configura SESSION_COOKIE_DOMAIN di conseguenza.

Non riesco a entrare. Quando inserisco un nome utente e una password validi vengo riportato alla pagina di login con l'errore "Inserire un nome utente e una password validi".

Se sei sicuro che il nome utente e la password sono corretti, assicurati che i flag is_active e is_staff relativi all'utente siano True. Il sito di amministrazione permette l'accesso ai soli utenti in cui questi due campi risultano attivi.

Come posso far si che venga memorizzato automaticamente in un campo l'utente che per ultimo ha modificato un oggetto?

Attualmente non è possibile. Considerando però che le richieste per questa funzionalità sono piuttosto frequenti, stiamo discutendo una possibile implementazione. Il problema è che non vogliamo creare dipendenze tra il layer del modello, il layer di amministrazione e il layer di gestione delle richieste (per ottenere l'utente). E' un problema ingarbugliato.

"list_filter" contiene un campo ManyToManyField, ma il filtro non lo mostra.

Django non si prende la briga di mostrare il filtro per un campo ManyToManyField se ci sono meno di due oggetti associati.

Ad esempio, se list_filter include sites, ma c'è un solo sito nel database, non sarà mostrato un filtro "Siti". In questo caso, filtrare per sito non avrebbe senso.

Come posso personalizzare le funzionalità dell'interfaccia di amministrazione?

Disponi di parecchie opzioni. Se vuoi aggiungere qualche funzionalità alla form di aggiunta e modifica che Django crea automaticamente, puoi usare il parametro js nella classe class Admin del modello che intendi modificare, inserendo codice JavaScript. Questo parametro è una lista di URL, specificati come stringhe, che puntano ai moduli JavaScript che verranno caricati dal tag <script>.

Se ti serve maggiore flessibilità per apportare cambiamenti più sostanziali, puoi scrivere view personalizzate per il sito di amministrazione. Questo sito è realizzato con Django stesso, e tu puoi scrivere view personalizzate che si interfacciano al sistema di autenticazione, che controllano permessi e che in genere svolgano qualsiasi funzione che possa tornarti utile.

Se vuoi personalizzare l'aspetto dell'interfaccia di amministrazione, prosegui con la lettura della prossima domanda.

Il sito di amministrazione generato dinamicamente è brutto. Come posso modificarlo?

A noi piace, ma se non sei dello stesso parere puoi modificare l'aspetto agendo sui fogli di stile CSS e/o sulle immagini. Il sito è costruito usando HTML semantico, e gli hook ai fogli di stile abbondano, quindi agendo sui fogli di stile dovresti essere in grado di apportare qualsiasi cambiamento tu desideri. Per aiutarti abbiamo messo a disposizione una guida ai CSS usati nell'amministrazione.

Come creo utenti senza dover fare gli hash delle password?

Noi sconsigliamo di creare gli utenti usando l'interfaccia di amministrazione, poiché ciò richiede la modifica manuale dell'hash delle password (viene effettuato l'hash della password usando un algoritmo di hash one-way, per motivi di sicurezza; attualmente non esiste un'interfaccia Web di amministrazione per cambiare la password immettendo la password stessa invece dell'hash).

Per creare un utente, dovrai usare le API Python. Vedi creare utenti per tutte le informazioni necessarie.

Note: See TracWiki for help on using the wiki.
Back to Top