Nella prima puntata abbiamo visto come installare un ambiente virtuale di Python, dove al suo interno abbiamo caricato Django ed attivato la prima pagina di benvenuto. Ora cominciano a fare qualche piccolo passo in avanti.
Per prima cosa dobbiamo cominciare a distinguere il progetto dalle applicazioni, o App.
Il progetto è quello che abbiamo creato la volta scorsa attraverso il comando “startproject“. Si tratta dell’equivalente di un contenitore generale, al suo interno possiamo creare tante App quante ce ne servono. Facciamo un esempio realistico che rende meglio l’idea.
Immaginiamo di voler fare il sito per l’Azienda in cui lavoriamo, ci servirà una Home Page, un Catalogo dei prodotti o servizi, un Portfolio dei lavori realizzati, un modulo di contatto, un blog per le news, eccetera.
Ognuna di queste sezioni può essere una App che poi andrà a dialogare con quelle successive. È come costruire qualcosa a mattoncini, espandibile ad ogni esigenza, anche futura.
Quindi, come si fa a creare una applicazione? Django ci viene in aiuto con una fase di precompilazione che andrà ad agevolare la fase iniziale. Partiamo con l’esempio classico, quello del blog. Da terminale andremo ad impartire il comando:
python manage.py startapp blog
dove chiaramente “blog” è la discriminante da noi scelta, ci verrà creata una cartella omonima nella radice del progetto, con all’interno il classico set di file python predisposti e dal nome autoesplicativo.
In questa guida andiamo molto sul pratico, non entro nella descrizione di questo o quello, le parti discretamente ovvie le salto.
A questo punto è necessario sporcarsi le mani, per prima cosa dobbiamo ragionare su cosa ci serve, immaginando o se vi è utile anche disegnandolo su carta, quali modelli di dato ci servono.
Ci servirà qualcosa di simile:
ID o identificativo univoco (tipo chiave primaria)
Titolo (tipo testo),
Autore (tipo dato esterno),
Post (tipo testo esteso),
“slug” per comporre le url (tipo testo),
Stato di pubblicazione (tipo testo),
Data di creazione (tipo data e ora),
Data di aggiornamento (tipo data e ora).
Essendo un modello, quanto sopra lo andremo a scrivere nel file models.py dentro la cartella blog.
Per prima cosa in alto nel file definiamo, come è buona norma, quali metodi andiamo ad importare:
from django.db import models
from django.utils import timezone
from django.contrib.auth.models import User
Ovvero abbiamo importato “timezone” per gestire la data, e “User” per gestire gli utenti. Models sono già imporati da Django ed è la base di partenza per usare i classici “charfiled, double, boolean”.
Quindi sotto andiamo a creare la nostra prima Classe, che sarà appunto Post.
class Post(models. Model):
STATUS_CHOICES = (
('draft', 'Draft'),
('published', 'Published'),
)
id = models.BigAutoField(primary_key=True)
title = models.CharField(max_length=250)
slug = models.SlugField(max_length=250,
unique_for_date='publish')
author = models.ForeignKey(User,
on_delete=models.CASCADE,
related_name='blog_posts')
body = models.TextField()
publish = models.DateTimeField(default=timezone.now)
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
status = models.CharField(max_length=10,
choices=STATUS_CHOICES,
default='draft')
class Meta:
ordering = ['-publish']
def __str__(self):
return self.title
Le righe 2-5 impostiamo un elenco di stati, che fungeranno da tendina nel momento in cui si scrive il post per scegliere se l’articolo deve essere nello stato di bozza o pubblicato.
Seguono i vari campi, che sono abbastanza parlanti, title è assegnato il modello “Charfield” con una lunghezza massima di 250 caratteri.
Per “Author” essendo un dato esterno (ForeignKey), facciamo riferimento alla tabella User che Django ha creato in fase di progetto. Di questo si occuperà lui, avremo modo di capire meglio gli utenti in un prossimo articolo, faccio notare invece l’argomento “on_delete”, ovvero se cancelleremo l’utente, tutti i suoi post saranno cancellati di conseguenza. Ovviamente l’argomento può essere cambiato.
Per le date di aggiornamento, Python stesso viene in aiuto con comodi comandi in cui occupa di fissare la data.
La Classe Meta ci serve per dare un ordine di pubblicazione in base alla data (campo publish) dove di restituirà i titoli.
Ok, abbiamo abbozzato la nostra prima applicazione, ma Django non lo sa, dobbiamo informarlo… Andiamo nella cartella di “miosito” (quella superiore a Blog) e nel file “settings.py” andiamo ad aggiungere la nostra applicazione tra quelle già note. All’interno del file cerchiamo la sezione INSTALLED_APPS
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'blog.apps.BlogConfig',
]
l’ultima riga, blog.apps.BlogConfig è quella che andremo ad aggiungere. Da dove salta fuori questa definizione? dal file “apps.py” dentro Blog che Django ha creato per noi all’inizio.
Ci siamo quasi, avendo aggiunto Modelli per il database dobbiamo effettuare una migrazione per renderli effettivi dentro SQLite3. Django si occuperà di creare il codice per la migrazione:
python manage.py makemigrations blog
Otteniamo un output simile a questo:
Migrations for 'blog':
blog/migrations/0001_initial.py
- Create model Post
Salto la parte di Migrations, dove è possibile vedere il codice SQL che Django ha creato per aggiornare il DataBase, in questa fase a mio avviso genera confusione. Sappiate che è possibile intervenire al suo interno. Per il progetto in essere non serve. Quando ha terminato possiamo dare il comando che già conosciamo:
python manage.py migrate
Con l’output simile al primo migrate, ma più ristretto a quanto abbiamo modificato in models.
Operations to perform:
Apply all migrations: admin, auth, blog, contenttypes, sessions
Running migrations:
Applying blog.0001_initial... OK
Perfetto, per questa puntata ci fermiamo qui, nella prossima vediamo di creare un utente e interagire con la nostra applicazione.