Questo secondo articolo del nostro Tutorial Django mostra come creare uno "scheletro" di progetto di un sito web come base, che potrà poi essere popolato con le impostazioni specifiche del sito, con i path, con i modelli, le view, e i template.

Prerequisiti: Creare un ambiente di sviluppo Django. Visita: Django Tutorial.
Obiettivi: Essere in grado di utilizzare i tool Django per iniziare il tuo progetto web.

Panoramica

Questo articolo mostra come creare uno "scheletro" di un sito web, che potrà poi essere popolato con impostazioni specifiche del sito, con i path, con i model, le view, e i template (discuteremo di questo in successivi articoli).

Il processo è semplice:

  1. Utilizzare lo strumento django-admin per creare la cartella del progetto, i templates di file di base e lo script di gestione del progetto (manage.py).
  2. Utilizzare manage.py per creare una o più applicazioni.

    Nota: un sito Web può essere costituito da una o più sezioni, ad es. sito principale, blog, wiki, area download, ecc. Django ti incoraggia a sviluppare questi componenti come applicazioni separate, che potrebbero poi essere riutilizzate in diversi progetti, se necessario. 

  3. Registrare le nuove applicazioni per includerle nel progetto.
  4. Collegare il mapper url/path per ciascuna applicazione.

Per il sito web Local Library la cartella del sito web e la sua cartella di progetto saranno chiamate locallibrary, e avremo solo un'applicazione chiamata catalog. La struttura delle cartelle di livello superiore sarà quindi la seguente:

locallibrary/         # Cartella Sito Web
    manage.py         # Script per eseguire i tool di Django per questo progetto (creato utilizzando django-admin)
    locallibrary/     # Cartella sito web/progetto (creata utilizzando django-admin)
    catalog/          # Cartella Application (creata utilizzando manage.py)

Le sezioni seguenti illustrano in dettaglio le fasi del processo e mostrano come testare le modifiche. Alla fine dell'articolo discuteremo alcune delle altre configurazioni a livello di sito che potresti fare anche in questa fase.

Creare il progetto

Per prima cosa apri un prompt dei comandi / terminale, assicurati di essere nel tuo virtual environment, accedi a dove vuoi archiviare le tue app Django (mettile in un posto facilmente reperibile, all'interno della tua cartella documenti) e crea una cartella per il tuo nuovo sito web (in questo caso: django_projects). Poi entra nella cartella col comando cd:

mkdir django_projects
cd django_projects

Crea il nuovo progetto utilizzando il comando django-admin startproject come mostrato, poi naviga fino alla cartella.

django-admin startproject locallibrary
cd locallibrary

lo strumento django-admin crea una struttura cartella/file come mostrata sotto:

locallibrary/
    manage.py
    locallibrary/
        __init__.py
        settings.py
        urls.py
        wsgi.py

la cartella corrente dovrebbe somigliare alla seguente:

../django_projects/locallibrary/

La sottocartella del progetto locallibrary è l'entry point per il sito Web:

  • __init__.py è un file vuoto che indica a Python di trattare questa directory come un pacchetto Python.
  • settings.py contiene tutte le impostazioni del sito web. Qui è dove registriamo tutte le applicazioni che creiamo, la posizione dei nostri file statici, i dettagli di configurazione del database, ecc.
  • urls.py definisce i mapping url-to-view del sito. Mentre questo potrebbe contenere tutto il codice di mappatura dell'URL, è più comune delegare parte della mappatura a particolari applicazioni, come vedremo più avanti.
  • wsgi.py è usato per aiutare la tua applicazione Django a comunicare con il server web.

Lo script manage.py viene utilizzato per creare applicazioni, lavorare con i database e avviare il server web di sviluppo. 

Quindi, esegui il seguente comando per creare l'applicazione catalog che risiederà all'interno del nostro progetto di localibrary (deve essere eseguito nella stessa cartella di manage.py del tuo progetto):

python3 manage.py startapp catalog

Note: il comando precedente è per Linux / macOS X. Su Windows il comando dovrebbe essere:

 py -3 manage.py startapp catalog

Se stai lavorando con Windows rimpiazza python3 con py -3 in tutto questo modulo.

Se stai usando la versione di Python 3.7.0 o superiore, devi usare solo:

py manage.py startapp catalog

Lo strumento crea una nuova cartella e la popola con i file per le diverse parti dell'applicazione (mostrate in grassetto sotto). La maggior parte dei file ha un nome utile in base al loro scopo (ad esempio, le viste dovrebbero essere memorizzate in views.py, models in models.py, i test tests.py, le configurazioni per l'amministrazione in admin.py, le applicazioni in apps.py) e contenere un minimo di codice per il lavoro con gli oggetti associati.

La directory del progetto aggiornata dovrebbe essere così ora:

locallibrary/
    manage.py
    locallibrary/
    catalog/
        admin.py
        apps.py
        models.py
        tests.py
        views.py
        __init__.py
        migrations/

Inoltre abbiamo:

  • Una cartella migrations, usata per memorizzare le "migrazioni" — file che ti permettono di aggiornare automaticamente il tuo database mentre modifichi i tuoi models.
  • __init__.py — un file vuoto creato qui in modo che Django / Python riconoscerà la cartella come un file Python Package e ti permette di usare i suoi oggetti all'interno di altre parti del progetto.

Note: Hai notato cosa manca nella lista dei file sopra? Mentre c'è un posto per le tue viste e modelli, non c'è nessun posto per te per mettere i tuoi mapping url, templates e file statici. Ti mostreremo come crearli più avanti (non sono necessari in tutti i siti Web ma sono necessari in questo esempio).

Registrare l'applicazione catalog

Ora che l'applicazione è stata creata, dobbiamo registrarla nel progetto in modo che venga inclusa quando vengono eseguiti tutti gli strumenti (ad esempio per aggiungere modelli al database). Le applicazioni vengono registrate aggiungendole alla lista INSTALLED_APPS in project settings. 

Aprire il file di project settings django_projects/locallibrary/locallibrary/settings.py e cerca la definizione della lista INSTALLED_APPS. Quindi aggiungi una nuova riga alla fine dell'elenco, come mostrato in grassetto sotto.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'catalog.apps.CatalogConfig', 
]

La nuova riga specifica l'oggetto di configurazione dell'applicazione (CatalogConfig) che è stato generato per te in /locallibrary/catalog/apps.py quando hai creato l'applicazione.

Nota: Noterai che ci sono già molti altri INSTALLED_APPS (e MIDDLEWARE, più in basso nel file delle impostazioni).. Questi abilitano il supporto per il sito  Django administration e, di conseguenza, molte delle funzionalità che utilizza (incluse sessioni, autenticazione, ecc.).

Specificare il database

Questo è anche il punto in cui normalmente si specifica il database da utilizzare per il progetto - è logico utilizzare lo stesso database per lo sviluppo e la produzione laddove possibile, al fine di evitare piccole differenze di comportamento.  Per le differenti opzioni si rimanda a Databases (Django docs). 

Useremo il database SQLite per questo esempio, perché non ci aspettiamo di richiedere molti accessi simultanei su un database dimostrativo, e anche perché non richiede lavoro aggiuntivo per impostarlo! Puoi vedere come è configurato questo database in settings.py (ulteriori informazioni sono incluse anche di seguito):

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

Poichè usiamo SQLite, non abbiamo bisogno di altri setup. Andiamo avanti!

Altre impostazioni per il progetto

Il file settings.py viene anche usato per configurare un certo numero di altre impostazioni, ma a questo punto probabilmente si desidera solo modificare TIME_ZONE — che dovrebbe essere impostato uguale ad una delle stringhe standard presenti nella lista List of tz database time zones (la colonna TZ contiene i valori da sostituire). Cambia la tua TIME_ZONE con una di queste stringhe, per esempio:

TIME_ZONE = 'Europe/Rome'

Queste altre due impostazioni invece non le cambierai ora, ma dovresti comunque conoscerle:

  • SECRET_KEY. Questa è una chiave segreta utilizzata come parte della strategia di sicurezza del sito web di Django. Se non stai proteggendo questo codice in fase di sviluppo, dovrai utilizzare un codice diverso (magari letto da una variabile o file di ambiente) quando lo metti in produzione.
  • DEBUG. Consente di visualizzare i log di debug in caso di errore, piuttosto che le risposte del codice di stato HTTP. Questo dovrebbe essere impostato su False in produzione in quanto le informazioni di debug sono utili per gli aggressori, ma per ora possiamo tenerlo impostato su True.

Collegare il mapper URL

Il sito Web viene creato con un file di mappatura URL (urls.py) nella cartella del progetto. Sebbene sia possibile utilizzare questo file per gestire tutti i mapping degli URL, è più frequente rinviare i mapping all'applicazione associata.

Aprite locallibrary/locallibrary/urls.py, notare il testo istruttivo che spiega alcuni modi per utilizzare il mappatore URL.

"""locallibrary URL Configuration


L'elenco "urlpatterns" indirizza gli URL alle viste. Per maggiori informazioni vedi:
    https://docs.djangoproject.com/en/2.1/topics/http/urls/
Esempi:
Views basate su funzioni
    1. Aggiungere un import:  from my_app import views
    2. Aggiungere un URL a urlpatterns:  path('', views.home, name='home')
Views basate su classi
    1. Aggiungere un import:  from other_app.views import Home
    2. Aggiungere un URL a urlpatterns:  path('', Home.as_view(), name='home')
Includere un altro URLconf
    1. Importare la funzione include(): from django.urls import include, path
    2. Aggiungere URL a urlpatterns: path('blog/', include('blog.urls'))
"""
from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]

Le mappature URL sono gestite tramite la variabile urlpatterns, che è una list Python di funzioni path(). Ogni funzione path() associa un pattern URL a una view specifica, che verrà visualizzata quando il pattern viene matchato, o con un altro elenco di codice di test pattern URL (in questo secondo caso, il pattern diventa "base URL" per i pattern definiti nel modulo target). La list urlpatterns definisce inizialmente una singola funzione che associa tutti gli URL con il pattern admin/ al modulo admin.site.urls, che contiene le definizioni di mappatura URL proprie dell'applicazione di Amministrazione.

Nota: il percorso (route) in path() è una stringa che definisce un pattern URL da matchare. Questa stringa potrebbe includere una variabile con nome (tra parentesi angolari), ad es. 'catalog/<id>/'. Questo pattern corrisponderà a un URL come /catalog/any_chars/ e passerà any_chars alla view come una stringa con nome di parametro id. Discuteremo ulteriormente i metodi path e i route patterns in successivi argomenti.

Aggiungi le linee qua sotto alla fine del file per aggiungere un nuovo elemento alla lista urlpatterns. Questo nuovo elemento della lista include un path() che inoltra richieste con il pattern catalog/ al modulo catalog.urls (il file con il relativo URL /catalog/urls.py).

# Use include() to add paths from the catalog application 
from django.urls import include
from django.urls import path

urlpatterns += [
    path('catalog/', include('catalog.urls')),
]

Adesso reindirizziamo il root URL del nostro sito (cioè 127.0.0.1:8000) all'URL 127.0.0.1:8000/catalog/; questa è l'unica app che useremo in questo progetto. Per fare ciò, useremo una speciale funzione (RedirectView), che prende come primo argomento il nuovo URL relativo verso cui fare il redirect (/catalog/) quando il pattern URL specificato nella funzione path() viene matchato (il root URL, in questo caso).

Aggiungere le seguenti linee di codice, sempre alla fine del file:

#Add URL maps to redirect the base URL to our application
from django.views.generic import RedirectView
urlpatterns += [
    path('', RedirectView.as_view(url='/catalog/', permanent=True)),
]

Lasciare il primo parametro della funzione path vuoto per implicare '/'. Se scrivi il primo parametro come '/' Django ti darà il seguente avviso quando avvii il server di sviluppo:

System check identified some issues:

WARNINGS:
?: (urls.W002) Your URL pattern '/' has a route beginning with a '/'. 
Remove this slash as it is unnecessary. 
If this pattern is targeted in an include(), ensure the include() pattern has a trailing '/'.

Django non utilizza file statici come CSS, JavaScript e immagini per impostazione predefinita, ma può essere utile per lo sviluppo del server Web durante la creazione del sito. Come aggiunta finale a questo mapper URL, è possibile abilitare la pubblicazione di file statici durante lo sviluppo aggiungendo le seguenti righe.

Aggiungi il seguente blocco di codice alla fine del file:

# Use static() to add url mapping to serve static files during development (only)
from django.conf import settings
from django.conf.urls.static import static

urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

Nota: Ci sono diversi modi per estendere la list urlpatterns (nel nostro esempio utiliziamo l'operatore append += per separare chiaramente il codice nuovo e da quello vecchio). Avremmo potuto semplicemente includere tutto nella definizione originale della list:

urlpatterns = [
    path('admin/', admin.site.urls),
    path('catalog/', include('catalog.urls')),
    path('', RedirectView.as_view(url='/catalog/', permanent=True)),
] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

Inoltre, abbiamo aggiunto la linea di import (from django.urls import include) insieme al codice che la utilizza, ma comunemente si preferisce mettere tutti gli import all'inizio del file Python.

Come ultimo passaggio, crea un file all'interno della cartella del tuo catalogo chiamato urls.py e aggiungi il testo seguente per definire gli urlpatterns importati (vuoti). Qui è dove aggiungeremo i nostri modelli, mentre costruiamo l'applicazione.

from django.urls import path
from . import views

urlpatterns = [

]

Test del framework del sito Web

A questo punto abbiamo uno scheletro completo. Il sito Web in realtà non fa ancora nulla, ma vale la pena eseguirlo per assicurarsi che nessuno dei nostri cambiamenti abbia infranto nulla.

Prima di farlo, dovremmo prima eseguire una migrazione del database. Questo aggiorna il nostro database per includere tutti i modelli nelle nostre applicazioni installate (e rimuove alcuni avvisi di build).

Effettuare migrazioni di database

Django utilizza un Object-Relational-Mapper (ORM) per mappare le definizioni di modello nel codice Django alla struttura dati utilizzata dal database sottostante. Quando cambiamo le definizioni dei nostri modelli, Django tiene traccia delle modifiche e può creare script di migrazione del database (in /locallibrary/catalog/migrations/) per migrare automaticamente la struttura dati sottostante nel database in modo che corrisponda al modello.

Quando abbiamo creato il sito Django ha aggiunto automaticamente un numero di modelli per l'uso da parte della sezione admin del sito (che vedremo in seguito). Eseguire i seguenti comandi per definire le tabelle per tali modelli nel database (assicurarsi di essere nella directory che contiene manage.py):

python3 manage.py makemigrations
python3 manage.py migrate

Importante: Avrai bisogno di eseguire i suddetti comandi ogni volta che i tuoi modelli cambiano in modo tale da influenzare la struttura dei dati che devono essere memorizzati (inclusi sia l'aggiunta che la rimozione di interi modelli e singoli campi).

Il comando makemigrations crea (ma non applica) le migrazioni per tutte le applicazioni installate nel progetto (puoi anche specificare il nome dell'applicazione per eseguire semplicemente una migrazione per un singolo progetto). Questo ti dà la possibilità di controllare il codice per queste migrazioni prima che vengano applicate - quando sei un esperto di Django puoi scegliere di modificarle direttamente!

Il comando migrate applica effettivamente le migrazioni al tuo database (Django tiene traccia di quelli che sono stati aggiunti al database corrente).

Nota: Consulta Migrations (Django docs) per info aggiuntive sui comandi meno usati nelle migrazioni.

Testare il sito web

Durante lo sviluppo è possibile testare il sito Web utilizzando il server web di sviluppo e quindi visualizzandolo sul browser web locale.

Nota: Il web server di sviluppo non è abbastanza robusto o performante per l'uso in produzione, ma è un modo molto semplice per far funzionare il tuo sito Django durante lo sviluppo per testarlo in modo rapido. Per impostazione di default il sito si troverà sul tuo computer all'indirizzo (http://127.0.0.1:8000/), ma puoi anche specificare altri computer sulla tua rete su cui hostare il sito. Per ulteriori informazioni, vedere django-admin and manage.py: runserver (Django docs).

Eseguire il server Web di sviluppo chiamando il comando runserver (nella stessa directory di manage.py):

python3 manage.py runserver

 Performing system checks...

 System check identified no issues (0 silenced).
 August 15, 2018 - 16:11:26
 Django version 2.1, using settings 'locallibrary.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.

Una volta attivato il server, puoi vedere il sito visitando il seguente indiriizzo sul browser web locale http://127.0.0.1:8000/. Dovresti vedere la seguente pagina di errore:

Django Debug page for Django 2.0

Non preoccuparti! Questa pagina di errore è prevista perché non abbiamo alcuna pagina/URL definita nel modulo catalogs.urls (a cui siamo reindirizzati quando otteniamo un URL alla radice del sito).

Nota: La pagina sopra mostra una grande funzionalità di Django - registrazione automatica del debug. Verrà visualizzata una schermata di errore con informazioni utili ogni volta che non è possibile trovare una pagina o qualsiasi errore viene generato dal codice. In questo caso possiamo vedere che l'URL che abbiamo fornito non corrisponde a nessuno dei nostri pattern URL (come elencato). Il logging verrà disattivato in produzione (quando mettiamo il sito sul Web), nel qual caso verrà pubblicata una pagina meno informativa ma più user-friendly.

Ora sappiamo che Django sta funzionando! 

Nota: Dovresti rieffettuare le migrazioni ogni volta che fai dei cambiamenti significativi, non richiedono molto tempo!

Sfida te stesso

La cartella catalog/ contiene file per le views, models, e altre parti dell'applicazione. Apri questi file e studiali. 

Come hai visto sopra, una mappatura URL per il sito di amministrazione è già stata aggiunta nella urls.py del progetto. Passa all'area di amministrazione nel tuo browser e vedi cosa succede (puoi dedurre l'URL corretto dalla mappatura sopra).

Sommario

Abbiamo creato uno scheletro completo del nostro progetto web, che potremo ora popolare con urls, models, views e templates.

Ora che lo scheletro per Local Library website è completo e funzionante, è ora di scrivere del codice per far fare al nostro sito cosa vogliamo fargli fare. 

Consulta anche

In this module

Tag del documento e collaboratori

Hanno collaborato alla realizzazione di questa pagina: paco80, mdnwebdocs-bot, mattiatoselli
Ultima modifica di: paco80,