{"title":"Scrivere la tua prima applicazione in Django, parte 2","version":"6.0","locale":"it","docname":"intro/tutorial02","url":"/it/6.0/intro/tutorial02/","canonical":"https://djangodocs.dev/it/6.0/intro/tutorial02/","summary":"Questo tutorial inizia dove è finito Tutorial 1 . Avvieremo il database, creeremo il tuo primo modello e faremo una veloce introduzione al sito admin di Django, che…","html":"

Scrivere la tua prima applicazione in Django, parte 2Link to this heading#

\n

Questo tutorial inizia dove è finito Tutorial 1. Avvieremo il database, creeremo il tuo primo modello e faremo una veloce introduzione al sito admin di Django, che viene generato automaticamente.

\n\n
\n

Configurazione del databaseLink to this heading#

\n

Ora, apri mysite/settings.py. Si tratta di un modulo Python normale con le variabili a livello di modulo che rappresentano le impostazioni di Django.

\n

Per impostazione predefinita, la configurazione DATABASES utilizza SQLite. Se sei nuovo nel mondo dei database o sei semplicemente interessato a provare Django, questa è l’opzione più semplice. SQLite è incluso in Python, quindi non dovrai installare nient’altro per supportare il tuo database. Tuttavia, quando avvierai il tuo primo progetto reale, potresti voler utilizzare un database più scalabile come PostgreSQL, per evitare problemi futuri legati al cambio di database.

\n

Se desideri usare un altro database, guarda :ref:` dettagli per personalizzare e far funzionare il tuo database <database-installation>`.

\n

Mentre stai modificando mysite/settings.py, imposta TIME_ZONE sul tuo fuso orario.

\n

Notate anche il INSTALLED_APPS setting in cima al file. Questo contiene i nomi di tutte le applicazioni che sono attivate in questa instanza di Django.\nL’app può essere utilizzata in più progetti, inoltre puoi creare un python package e distribuirlo per essere utilizzato in altri progetti.

\n

Per impostazione predefinita INSTALLED_APPS contiene le seguenti app, tutte fornite con Django:

\n\n

Queste applicazioni sono incluse di default come convenienza per l’uso comune.

\n

Alcune di queste applicazioni utilizzano almeno una tabella nel database, quindi dobbiamo creare le tabelle nel database prima di poterle utilizzare. Per farlo, esegui il seguente comando:

\n

Linux / macOS

Shell
$ python manage.py migrate\n
\n

Windows

Windows
...\\> py manage.py migrate\n
\n

Il comando migrate controlla le impostazioni di INSTALLED_APPS e crea tutte le tabelle del database che sono necessarie in accordo con le impostazioni di database nel tuo file mysite/settings.py e le migrazioni del database fornite con l’applicazione (ne parleremo dopo). Vedrai un messaggio per ogni migrazione che applica. Se sei interessato, lancia il client database dalla linea di comando e scrivi \\dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .tables (SQLite) o SELECT TABLE_NAME FROM USER_TABLES; (Oracle) per mostrare le tabelle che Django ha creato.

\n\n
\n
\n

Creazione dei modelliLink to this heading#

\n

Ora definiremo i tuoi modelli – essenzialmente, la struttura del tuo database, con metadati aggiuntivi.

\n\n

Nella nostra app sondaggio, creeremo due modelli: Question e Choice. Una Question ha una domanda e una data di pubblicazione. Una Choice ha due campi: il testo della scelta e il conteggio dei voti. Ogni Choice è associato ad una Question.

\n

Questi concetti sono rappresentati da classi Python. Modifica il file polls / models.py in questo modo:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    question_text = models.CharField(max_length=200)\n    pub_date = models.DateTimeField("date published")\n\n\nclass Choice(models.Model):\n    question = models.ForeignKey(Question, on_delete=models.CASCADE)\n    choice_text = models.CharField(max_length=200)\n    votes = models.IntegerField(default=0)\n
\n

Qui, ogni modello è rappresentato da una classe che è sottoclasse di django.db.models.Model. Ogni modello ha un certo numero di variabili di classe, ciascuna delle quali rappresenta un campo del database.

\n

Ogni campo è rappresentato da un’istanza della classe Field – e.g., CharField per i campi carattere e DateTimeField per le date. Questo dice a Django che tipo di dati contiene ogni campo.

\n

Il nome di ogni istanza Field (e.g. question_text o pub_date) è il nome del campo in formato machine-friendly. Userai questo valore nel tuo codice Python e il tuo database lo userà come nome della colonna.

\n

Puoi passare un primo argomento posizionale opzionale alla classe Field per indicare un nome human-readable. Questo è usato in un paio di parti introspettive di Django e torna utile come documentazione. Se questo argomento non è fornito, Django userà il nome machine-readable. In questo esempio, abbiamo definite un nome human-readable solo per Question.pub_date. Per tutti gli altri campi in questo modello, il nome machine-readable di ogni campo sarà sufficiente come nome human-readable.

\n

Alcune classi Field hanno argomenti obbligatori. CharField, per esempio, richiede che tu gli dia una max_length. Ciò non viene usato solo nello schema del database ma nella validazione, come vedremo presto.

\n

Un Field può avere anche diversi argomenti opzionali; in questo caso, abbiamo impostato il valore default a 0.

\n

Infine, nota che è stata definita una relazione usando ForeignKey. Quello dice a Django che ciascuna Choice è collegata ad una singola Question. Django supporta tutte le relazioni comuni dei database: many-to-one, many-to-many, and one-to-one.

\n
\n
\n

Attivazione dei modelliLink to this heading#

\n

Questo piccolo codice del modello fornisce a Django molte informazioni. Con esso, Django è in grado di:

\n\n

Ma prima dobbiamo dire al nostro progetto che l’app polls è installata.

\n\n

Per includere l’app nel nostro progetto, dobbiamo aggiungere un riferimento alla sua classe di configurazione nell’impostazione INSTALLED_APPS. La classe PollsConfig è nel file polls/apps.py, quindi il suo percorso separato da punti è 'polls.apps.PollsConfig'. Modifica il file mysite/settings.py e aggiungi quel percorso separato da punti all’impostazione INSTALLED_APPS setting. Sarà simile a questo:

\n
mysite/settings.py
\n
Python
INSTALLED_APPS = [\n    "polls.apps.PollsConfig",\n    "django.contrib.admin",\n    "django.contrib.auth",\n    "django.contrib.contenttypes",\n    "django.contrib.sessions",\n    "django.contrib.messages",\n    "django.contrib.staticfiles",\n]\n
\n

Adesso Django sa che deve includere l’app polls . Lanciamo un altro comando:

\n

Linux / macOS

Shell
$ python manage.py makemigrations polls\n
\n

Windows

Windows
...\\> py manage.py makemigrations polls\n
\n

Dovresti vedere qualcosa di simile a:

\n
Text
Migrations for 'polls':\n  polls/migrations/0001_initial.py\n    + Create model Question\n    + Create model Choice\n
\n

Eseguendo makemigrations, stai dicendo a Django che hai apportato alcune modifiche ai tuoi modelli (in questo caso, ne hai aggiunti di nuovi) e che desideri che le modifiche vengano memorizzate come migrazione.

\n

Le migrazioni sono il modo in cui Django memorizza i cambiamenti ai tuoi modelli (e quindi allo schema del tuo database) - sono file sul disco. Puoi leggere la migrazione del tuo nuovo modello se vuoi, all’interno del file polls/migrations/0001_initial.py.\nNon preoccuparti, non devi leggerle ogni volta che Django ne crea una, ma sono progettate per essere modificabili dagli sviluppatori nel caso tu voglia ritoccare il modo in cui Django modifica le cose.

\n

C’è un comando che eseguirà le migrazioni per te e gestirà automaticamente lo schema del tuo database - che si chiama migrate, e ci arriveremo tra un attimo - ma prima, vediamo quale SQL eseguirà la migrazione. Il comando sqlmigrate accetta i nomi delle migrazioni e restituisce il loro SQL:

\n

Linux / macOS

Shell
$ python manage.py sqlmigrate polls 0001\n
\n

Windows

Windows
...\\> py manage.py sqlmigrate polls 0001\n
\n

Dovresti vedere qualcosa di simile al seguente (è stato riformattato per leggibilità):

\n
SQL
BEGIN;\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Create model Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL,\n    "question_id" bigint NOT NULL\n);\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\nCREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");\n\nCOMMIT;\n
\n

Nota bene:

\n\n

Se sei interessato, puoi anche eseguire python manage.py check; che verifica eventuali problemi nel progetto senza effettuare migrazioni o toccare il database.

\n

Ora, esegui: djadmin:migrate di nuovo per creare quelle tabelle nel tuo database:

\n

Linux / macOS

Shell
$ python manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Applying polls.0001_initial... OK\n
\n

Windows

Windows
...\\> py manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Applying polls.0001_initial... OK\n
\n

Il comando migrate prende tutte le migrazioni che non sono state applicate (Django tiene traccia di quali sono applicate usando una tabella speciale nel tuo database chiamata django_migrations) e le esegue sul tuo database - essenzialmente, sincronizzando le modifiche apportate ai modelli con lo schema nel database.

\n

Le migrazioni sono molto potenti e ti consentono di modificare i tuoi modelli nel tempo, mentre sviluppi il tuo progetto, senza la necessità di eliminare il tuo database o tabelle e crearne di nuove - è specializzato nell’aggiornamento del tuo database in tempo reale, senza perdere dati. Li tratteremo in modo più approfondito in una parte successiva del tutorial, ma per ora, ricorda la procedura in tre passaggi per apportare modifiche al modello:

\n\n

Il motivo per cui esistono comandi separati per eseguire e applicare le migrazioni è perché invierai le migrazioni al tuo sistema di controllo della versione e le spedirai con la tua app; non solo semplificano lo sviluppo, ma sono anche utilizzabili da altri sviluppatori e in produzione.

\n

Leggi documentazione di django-admin per le informazioni complete su cosa può fare l’utility manage.py.

\n
\n
\n

Giocare con le APILink to this heading#

\n

Ora, andiamo nella shell interattiva di Python e giochiamo con l’API inclusa che Django ti offre. Per richiamare la shell Python, usa questo comando:

\n

Linux / macOS

Shell
$ python manage.py shell\n
\n

Windows

Windows
...\\> py manage.py shell\n
\n

We’re using this instead of simply typing «python», because manage.py\nsets the DJANGO_SETTINGS_MODULE environment variable, which gives\nDjango the Python import path to your mysite/settings.py file.\nBy default, the shell command automatically imports the models from\nyour INSTALLED_APPS.

\n

Una volta che sei nella shell, esplora le database API:

\n
Python console
# No questions are in the system yet.\n>>> Question.objects.all()\n<QuerySet []>\n\n# Create a new Question.\n# Support for time zones is enabled in the default settings file, so\n# Django expects a datetime with tzinfo for pub_date. Use timezone.now()\n# instead of datetime.datetime.now() and it will do the right thing.\n>>> from django.utils import timezone\n>>> q = Question(question_text="What's new?", pub_date=timezone.now())\n\n# Save the object into the database. You have to call save() explicitly.\n>>> q.save()\n\n# Now it has an ID.\n>>> q.id\n1\n\n# Access model field values via Python attributes.\n>>> q.question_text\n"What's new?"\n>>> q.pub_date\ndatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.UTC)\n\n# Change values by changing the attributes, then calling save().\n>>> q.question_text = "What's up?"\n>>> q.save()\n\n# objects.all() displays all the questions in the database.\n>>> Question.objects.all()\n<QuerySet [<Question: Question object (1)>]>\n
\n

Aspetta un attimo. <Question: Question object (1)> non è una rappresentazione utile di questo oggetto. Mettiamolo a posto modificando il modello Question (nel file polls/models.py) ed aggiungendo un metodo __str__() sia a Question che a Choice:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\n\nclass Choice(models.Model):\n    # ...\n    def __str__(self):\n        return self.choice_text\n
\n

È importante aggiungere il metodo __str__() ai tuoi modelli, non solo per tua convenienza quando hai a che fare con il prompt interattivo ma anche perché le rappresentazioni degli oggetti sono utilizzate nell’admin auto-generato di Django.

\n

Aggiungiamo anche un metodo personalizzato a questo modello:

\n
polls/models.py
\n
Python
import datetime\n\nfrom django.db import models\nfrom django.utils import timezone\n\n\nclass Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)\n
\n

Nota l’aggiunta di import datetime e from django.utils import timezone per fare rispettivamente riferimento al modulo standard datetime ed alle utility di Django relative alle time-zone in django.utils.timezone. Se non hai familiarità con la gestione delle time zone in Python, puoi saperne di più consultando la documentazione di supporto per le time zone.

\n

Save these changes and start a new Python interactive shell. (If a\nthree-chevron prompt (>>>) indicates you are still in the shell, you need to\nexit first using exit()). Run python manage.py shell again to reload\nthe models.

\n
Python console
# Make sure our __str__() addition worked.\n>>> Question.objects.all()\n<QuerySet [<Question: What's up?>]>\n\n# Django provides a rich database lookup API that's entirely driven by\n# keyword arguments.\n>>> Question.objects.filter(id=1)\n<QuerySet [<Question: What's up?>]>\n>>> Question.objects.filter(question_text__startswith="What")\n<QuerySet [<Question: What's up?>]>\n\n# Get the question that was published this year.\n>>> from django.utils import timezone\n>>> current_year = timezone.now().year\n>>> Question.objects.get(pub_date__year=current_year)\n<Question: What's up?>\n\n# Request an ID that doesn't exist, this will raise an exception.\n>>> Question.objects.get(id=2)\nTraceback (most recent call last):\n    ...\nDoesNotExist: Question matching query does not exist.\n\n# Lookup by a primary key is the most common case, so Django provides a\n# shortcut for primary-key exact lookups.\n# The following is identical to Question.objects.get(id=1).\n>>> Question.objects.get(pk=1)\n<Question: What's up?>\n\n# Make sure our custom method worked.\n>>> q = Question.objects.get(pk=1)\n>>> q.was_published_recently()\nTrue\n\n# Give the Question a couple of Choices. The create call constructs a new\n# Choice object, does the INSERT statement, adds the choice to the set\n# of available choices and returns the new Choice object. Django creates\n# a set (defined as "choice_set") to hold the "other side" of a ForeignKey\n# relation (e.g. a question's choice) which can be accessed via the API.\n>>> q = Question.objects.get(pk=1)\n\n# Display any choices from the related object set -- none so far.\n>>> q.choice_set.all()\n<QuerySet []>\n\n# Create three choices.\n>>> q.choice_set.create(choice_text="Not much", votes=0)\n<Choice: Not much>\n>>> q.choice_set.create(choice_text="The sky", votes=0)\n<Choice: The sky>\n>>> c = q.choice_set.create(choice_text="Just hacking again", votes=0)\n\n# Choice objects have API access to their related Question objects.\n>>> c.question\n<Question: What's up?>\n\n# And vice versa: Question objects get access to Choice objects.\n>>> q.choice_set.all()\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n>>> q.choice_set.count()\n3\n\n# The API automatically follows relationships as far as you need.\n# Use double underscores to separate relationships.\n# This works as many levels deep as you want; there's no limit.\n# Find all Choices for any question whose pub_date is in this year\n# (reusing the 'current_year' variable we created above).\n>>> Choice.objects.filter(question__pub_date__year=current_year)\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n\n# Let's delete one of the choices. Use delete() for that.\n>>> c = q.choice_set.filter(choice_text__startswith="Just hacking")\n>>> c.delete()\n
\n

Per avere più informazioni sulle relazioni dei modelli, vedi Accesso agli oggetti collegati. Per saperne di più su come usare il doppio underscore per fare field lookup con le API, vedi Field lookups. Per tutti i dettagli sulle API del database, vedi la nostra Database API reference.

\n
\n
\n

Presentazione dell’Amministrazione di DjangoLink to this heading#

\n\n
\n

Creazione di un utente amministratoreLink to this heading#

\n

Per prima cosa dobbiamo creare un utente che possa accedere al sito di amministrazione. Esegui il seguente comando:

\n

Linux / macOS

Shell
$ python manage.py createsuperuser\n
\n

Windows

Windows
...\\> py manage.py createsuperuser\n
\n

Inserisci lo username e premi enter.

\n
Text
Username: admin\n
\n

Ti verrà quindi chiesto di inserire l’indirizzo email desiderato:

\n
Text
Email address: admin@example.com\n
\n

Il passaggio finale è inserire la tua password. Ti verrà chiesto di inserire la tua password due volte, la seconda come conferma della prima.

\n
Text
Password: **********\nPassword (again): *********\nSuperuser created successfully.\n
\n
\n
\n

Avvia il server di sviluppoLink to this heading#

\n

Il sito di amministrazione di Django è attivato di default. Avviamo il server di sviluppo ed esploriamolo.

\n

Se il server non è in esecuzione, avvialo con:

\n

Linux / macOS

Shell
$ python manage.py runserver\n
\n

Windows

Windows
...\\> py manage.py runserver\n
\n

Ora, apri un browser web e vai su «/admin/» nel tuo dominio locale – per es. http://127.0.0.1:8000/admin/. Dovresti vedere la schermata di login dell’amministrazione:

\n\"Pagina\n

Poiché translation è attivato di default, se imposti LANGUAGE_CODE, la schermata di login verrà visualizzata nella lingua indicata (se Django ha traduzioni appropriate).

\n
\n
\n

Accedi al sito di amministrazioneLink to this heading#

\n

Ora prova ad accedere con l’account superutente che hai creato nel passaggio precedente. Dovresti vedere la pagina principale di Django admin:

\n\"Pagina\n

Dovresti vedere alcuni tipi di contenuto modificabile: gruppi e utenti. Sono forniti da django.contrib.auth, il framework di autenticazione fornito da Django.

\n
\n
\n

Rendi l’applicazione Sondaggi modificabile nell’amministrazioneLink to this heading#

\n

Ma dov’è la nostra app per i sondaggi? Non viene visualizzato nella pagina principale dell’amministratore.

\n

Solo un’altra cosa da fare: dobbiamo dire all’admin che gli oggetti Question hanno un’interfaccia di amministrazione. Per fare ciò, apri il file polls/admin.py e modificalo in questo modo:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\nadmin.site.register(Question)\n
\n
\n
\n

Esplora le funzionalità disponibili nell’amministrazioneLink to this heading#

\n

Ora che abbiamo registrato Question, Django sa che dovrebbe essere visualizzato nell’indice dell’amministratore:

\n\"Pagina\n

Fare clic su «Questions». Ora sei nella pagina «elenco modifiche» per le domande. Questa pagina mostra tutte le domande nel database e ti permette di sceglierne una per cambiarla. C’è la domanda «»What’s up?» che abbiamo creato in precedenza:

\n\"Pagina\n

Fai clic sulla domanda «What’s up?» per modificarla:

\n\"Form\n

Cose da notare qui:

\n\n

La parte inferiore della pagina offre un paio di opzioni:

\n\n

Se il valore di «Data di pubblicazione» non corrisponde all’ora in cui hai creato la domanda in Tutorial 1, probabilmente significa che hai dimenticato di impostare il valore corretto per l’impostazione TIME_ZONE. Modificalo, ricarica la pagina e verifica che appaia il valore corretto.

\n

Modificare la «Data di pubblicazione» facendo clic sui collegamenti «Oggi» e «Adesso». Quindi fai clic su «Salva e continua le modifiche». Quindi fai clic su «Cronologia» in alto a destra. Vedrai una pagina che elenca tutte le modifiche apportate a questo oggetto tramite l’amministratore Django, con il timestamp e lo username della persona che ha apportato la modifica:

\n\"Pagina\n

Quando sei a tuo agio con l’API dei modelli e hai familiarizzato con il sito di amministrazione, leggi la parte 3 di questo tutorial per sapere come aggiungere più views alla nostra app per i sondaggi.

\n
\n
","rootId":"writing-your-first-django-app-part-2","toc":[{"title":"Configurazione del database","anchor":"database-setup","children":[]},{"title":"Creazione dei modelli","anchor":"creating-models","children":[]},{"title":"Attivazione dei modelli","anchor":"activating-models","children":[]},{"title":"Giocare con le API","anchor":"playing-with-the-api","children":[]},{"title":"Presentazione dell’Amministrazione di Django","anchor":"introducing-the-django-admin","children":[{"title":"Creazione di un utente amministratore","anchor":"creating-an-admin-user","children":[]},{"title":"Avvia il server di sviluppo","anchor":"start-the-development-server","children":[]},{"title":"Accedi al sito di amministrazione","anchor":"enter-the-admin-site","children":[]},{"title":"Rendi l’applicazione Sondaggi modificabile nell’amministrazione","anchor":"make-the-poll-app-modifiable-in-the-admin","children":[]},{"title":"Esplora le funzionalità disponibili nell’amministrazione","anchor":"explore-the-free-admin-functionality","children":[]}]}],"breadcrumbs":[{"docname":"intro/index","title":"Come iniziare","url":"/it/6.0/intro/"}],"prev":{"docname":"intro/tutorial01","title":"Scrivere la tua prima applicazione in Django, parte 1","url":"/it/6.0/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"Scrivere la tua prima applicazione in Django, parte 3","url":"/it/6.0/intro/tutorial03/"},"formats":{"html":"/it/6.0/intro/tutorial02/","markdown":"/it/6.0/intro/tutorial02.md","json":"/it/6.0/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/6.0.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/it/6.0/intro/tutorial02/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}