Da questa Guida in poi, presenterò diversi aspetti di Drupal utili alla costruzione delle app, svolgendo prima un minimo di teoria, applicandola poi alla app di esempio. Partiamo da come Drupal gestisce le informazioni.
Le Entità
Ogni app gestisce informazioni di varia natura, tra cui dati, documenti, video, immagini, persone, vocabolari ecc. Drupal mette a disposizione un modello generale per gestire tutti questi tipi di informazioni in modo strutturato: le Entità (entity).
Ci sono Entità che memorizzano le informazioni gestite dalla app (Entità di contenuto) ed Entità che memorizzano la configurazione di Drupal stesso (Entità di configurazione). Nel seguito, quando parleremo di Entità, salvo diversa indicazione intendiamo sempre le Entità di contenuto.
Ogni Entità è un insieme strutturato di dati che viene trattato (inserito, modificato, cancellato) come un'unità. Drupal gestisce l'Entità come l'unità elementare di informazione, nel senso che tutte le informazioni che contiene vengono gestite come un tutt'uno: ad esempio, se si cancella una Entità vengono distrutte tutte le informazioni in essa contenute e non è possibile eliminare "parzialmente" una Entità.
Drupal gestisce diversi tipi di Entità, tra cui Contenuti, Utenti, Termini di Tassonomia, File, Media, Commenti ecc. I moduli aggiuntivi di Drupal possono aggiungere ulteriori tipi di Entità, ad esempio i Gruppi. Per ogni tipo di Entità differente, Drupal mette a disposizione funzioni specializzate: ad esempio, solo le Entità di tipo Utente hanno associate informazioni sul login e funzioni per eseguirlo; solo le Entità di tipo File hanno una dimensione, espressa in KB.
Alcuni tipi di Entità prevedono una ulteriore specializzazione, chiamata Bundle. L'Amministratore non può creare nuovi tipi di Entità (perché sono definiti dai moduli installati), ma può creare nuovi Bundle e, ovviamente, nuove Entità dei tipi e dei Bundle disponibili:
| Tipo di Entità | Sottotipo di Entità (bundle) |
| Contenuto (content, node) | Tipo di Contenuto (content type) |
| Termine di tassonomia (taxonomy term, term) | Tassonomia (taxonomy, vocabulary) |
| Utente (user) | |
| Media (media) | Tipo di Media (media type) |
| Commento (comment) | Tipo di Contenuto del Commento |
| Gruppo (group) | Tipo di Gruppo (group type) |
I campi delle Entità
Le informazioni di una Entità sono memorizzate nei suoi Campi. Usando una metafora, l'Entità è una cassettiera ed ogni suo Campo è un "cassetto" in grado di memorizzare uno specifico tipo di informazione. Drupal mette a disposizione molti tipi di Campi, in grado di memorizzare diversi tipi di informazioni: testo (formattato o meno), numeri (interi, decimali...), file, immagini, date, liste di selezione, link a pagine ecc. Alcuni moduli aggiuntivi aggiungono ulteriori tipi di Campo, ad esempio coordinate geografiche.
L'Amministratore può aggiungere a tipi e sottotipi di Entità un numero illimitato di Campi. Ad esempio, è possibile aggiunge agli Utenti tre Campi testuali per memorizzare il nome, il cognome ed il codice fiscale della persona; al Tipo di Contenuto "Brano musicale" è possibile assegnare i Campi "Cantante" ed "Album". Questa caratteristica è fondamentale per la costruzione delle app in Drupal, perché permette di adattare le Entità alle specifiche esigenze della app, senza lavorare direttamente sulle tabelle del database di Drupal.
Nome interno ed nome esterno (etichetta) del Campo
Ogni Campo ha un nome esterno ed un nome interno. Il nome esterno è l'etichetta che l'Amministratore assegna al Campo e col quale il Campo viene visto dagli Utenti. Il nome interno è quello con cui Drupal identifica il Campo ed è costruito automaticamente come field_ seguito dall'etichetta in caratteri minuscoli; ad esempio, il Campo di nome (esterno) "Cognome" è identificato in Drupal col nome (interno) "field_cognome".
Mentre il nome esterno può essere lo stesso per più Campi, il nome interno è univoco e quindi non ci possono essere due Campi con lo stesso nome interno: se ciò accade, Drupal segnala un errore, invita a modificare il nome interno del nuovo Campo e non lo memorizza fino a quando il nome interno non è univoco:
![]() |
Una volta assegnato, il nome interno non può più essere modificato, mentre il nome esterno può essere cambiato in qualunque momento. L'importanza dei nomi interni dei Campi sarà evidente nella costruzione delle Viste.
Riferimenti tra Entità
Tra i tipi di Campi disponibili, ha una particolare importanza il tipo Riferimento (reference), perché permette di definire una relazione tra due tipi di Entità. Ad esempio, se creiamo un Tipo di Contenuto "Brano musicale" ed un Tipo di Contenuto "Album" ed aggiungiamo al Tipo di Contenuto "Brano musicale" un Campo Riferimento che rimanda al tipo "Album", possiamo gestire l'appartenenza di un brano musicale ad un album. Possiamo rappresentare questa relazione come Brano → Album perché, conoscendo il Brano, possiamo arrivare all'Album in cui è inserito. Quando un Utente compila il Campo Riferimento "Album" di un Brano, Drupal lo obbliga a scegliere una delle Entità di tipo Album già memorizzati nella app.
Campi predefiniti
Ogni tipo di Entità ha alcuni Campi predefiniti. Ad esempio, gli Utenti hanno i Campi predefiniti Nome utente, Password, Email. i Contenuti hanno il Campo predefinito Titolo, i Termini di Tassonomia il Campo Nome e Campi che servono a collocare il Termine nella Tassonomia (Genitore, Profondità e Peso)
Tutti i tipi di Entità hanno i seguenti Campi predefiniti, molto utili per la costruzione di una app:
- Autore: contiene il Riferimento all'Utente che ha creato l'Entità
- Data di creazione (Inserito il): memorizza data e ora di creazione dell'Entità
- Data di modifica: memorizza data e ora di ultima modifica dell'Entità
- Pubblicato: memorizza se l'Entità è visibile oppure nascosta
Questi Campi sono compilati automaticamente da Drupal, ma possono essere modificati dall'Amministratore. Di default, I Campi predefiniti non sono mostrati agli Utenti, ma vedremo come esporli con le Viste.
L'identificativo di Entità
Ad ogni Entità è associato un numero intero che lo identifica univocamente rispetto alle altre Entità dello stesso tipo. Ad esempio, l'Utente Amministratore è il numero "1" ed è l'unico Utente ad avere quel numero, mentre nulla vieta che vi sia un Contenuto o un File identificati da "1". Il numero univoco è assegnato automaticamente da Drupal all'Entità nel momento in cui viene creata e non può essere modificato, neppure dall'Amministratore. Se l'Entità viene cancellata, il suo numero univoco non viene riciclato. Il numero univoco è memorizzato in un apposito Campo predefinito; il nome di quel Campo varia leggermente col tipo di Entità: ID per i Contenuti, UID per gli Utenti, TID per i Termini di Tassonomia ecc.
I Token
La maggior parte delle informazioni gestite da Drupal in una app sono riutilizzabili in altre parti della app attraverso i Token. Un Token è una parola speciale che identifica una informazione della app e viene sostituita col valore di quella informazione (un concetto molto vicino a quello di "variabile" nei linguaggi di programmazione o di incognita o parametro in matematica). Nelle prossime Guide faremo un ampio utilizzo dei Token.
Anche se Drupal mette nativamente a disposizione un buon numero di Token, raccomando di installare sempre il modulo aggiuntivo Token perché ne estende il numero e le potenzialità.
In tutte le pagine in cui Drupal accetta Token, mette a disposizione anche un comando (il cui nome varia da contesto a contesto, dal riconoscibile Sfoglia i Token disponibili al più criptico Replacement patterns ma nelle Guide cercherò di indicarlo sempre) con cui consultare l'elenco dei Token disponibili in quel contesto. L'elenco può presentarsi nei casi più complessi come una gerarchia in cui scendere fino a trovare il Token desiderato: in questi casi, ila voce solitamente più utile è Node, sotto cui si trovano tutti i Token relativi ai Contenuti. Una volta trovato il Token desiderato, lo si copia e incolla nella casella dove serve.
I Token possono presentarsi in due forme, in base al contesto: tra parentesi quadre es: [node:title] è il Token che restituisce il titolo di un Contenuto; oppure tra parentesi graffe, es: {{ node.title.value }} restituisce lo stesso valore. Non è necessario comprendere in dettaglio questa differenza, perché Drupal provvede a mostrare solo i Token disponibili e nella forma utile al contesto.
Le Entità della app di esempio
Vediamo come utilizzare le Entità per gestire le informazioni della app di esempio.
Attrezzi: Ogni Attrezzo è memorizzato in un Contenuto di tipo "Attrezzo", caratterizzato da questi campi:
| Campo | Tipo | Descrizione |
| Nome (titolo) | testo | Descrizione breve dell'Attrezzo |
| Descrizione | testo formattato | Descrizione lunga dell'Attrezzo |
| Categoria | Riferimento a Categoria | Categoria cui appartiene l'Attrezzo (Attrezzo → Categoria) |
| Immagine | immagine | Immagine che raffigura l'Attrezzo |
| Allegati | File (più valori) | Documenti che descrivono l'Attrezzo |
| Stato | Lista di selezione | Disponibile | Sospeso | Ritirato |
Categorie: Ogni Categoria è .memorizzata in un Contenuto di tipo "Categoria" caratterizzato dai seguenti campi:
| Campo | Tipo | Descrizione |
| Nome | testo | Nome della Categoria. Es. "Falciatrice" |
| Sinonimi | testo | Altri termini che identificano la Categoria. Es. "tagliabordi estirpatore" |
| Categoria Superiore | Riferimento a Categoria | Categoria superiore. Es. Giardinaggio. Questo Campo consente di costruire una gerarchia di Categorie. (Categoria → Categoria superiore) |
| In Drupal la categorizzazione di Entità è di solito realizzata con Tassonomie, perché questo tipo di Entità fornisce una serie di funzioni molto comode per rappresentare gerarchie di qualunque livello di concetti. Per semplicità didattica, preferisco per la app di esempio utilizzare un tipo di Contenuto. |
Richieste: Ogni Richiesta è memorizzata in un Contenuto di tipo "Richiesta" caratterizzato dai seguenti campi:
| Campo | Tipo | Descrizione |
| Titolo | testo | Generato automaticamente dal Drupal come "Richiesta n. CODICE" |
| Attrezzo | Riferimento ad Attrezzo | Attrezzo chiesto in prestito (Richiesta → Attrezzo) |
| Codice | intero seriale | Codice univoco generato automaticamente |
L'Utente richiedente è memorizzato come Autore della Richiesta. Lo stato della Richiesta non è memorizzato in un Campo apposito ma è dedotta da altri Campi: la Richiesta è considerata "aperta" se il suo Campo "Prestito" è vuoto, oppure se il Campo "Restituzione" del suo Prestito è vuoto; in tuti gli altri casi è considerata "conclusa".
Prestiti: Ogni Prestito è memorizzato in un Contenuto di tipo "Prestito" caratterizzato dai seguenti campi:
| Campo | Tipo | Descrizione |
| Titolo | testo | Generato automaticamente dalla app come "Prestito n. CODICE" |
| Richiesta | Riferimento a Richiesta | Richiesta cui il Prestito risponde (Prestito → Richiesta) |
| Codice | Intero seriale | Codice univoco generato automaticamente |
| Consegna | Data | Data di consegna dell'attrezzo (se il prestito avviene) |
| Restituzione | Data | Data di restituzione dell'attrezzo (se il prestito avviene) |
Richiedente e Proprietario non sono memorizzati in Campi appositi ma desunti da altri Campi: dalla Richiesta citata nel Campo "Richiesta" si desume il Richiedente (Autore della Richiesta) ed il Proprietario (Autore dell'Attrezzo citato nel Campo "Attrezzo" della Richiesta). Il Proprietario coincide inoltre con l'Autore del Prestito. Lo Stato del Prestito non è memorizzato in un Campo apposito ma desunto dal Campo "Restituzione": se queto Campo è vuoto, il Prestito è considerato "aperto", se è compilato il Prestito è considerato "concluso".
Messaggi: Ogni Messaggio è memorizzato da un Contenuto di tipo "Messaggio" caratterizzato dai seguenti campi:
| Campo | Tipo | Descrizione |
| Titolo | testo | Generato automaticamente come "Messaggio n. CODICE" |
| Richiesta | Riferimento a Richiesta | Richiesta cui si riferisce il Messaggio (Messaggio → Richiesta) |
| Testo | testo formattato | Testo del Messaggio |
| Allegati | File | Immagini o documenti allegati al Messaggio |
| Codice | intero seriale | Codice univoco generato automaticamente |
Richiedente e Proprietario non sono memorizzati in Campi appositi ma desunti da altri Campi: dalla Richiesta citata nel Campo "Richiesta" si desume il Richiedente (Autore della Richiesta) ed il Proprietario (Autore dell'Attrezzo citato nel Campo "Attrezzo" della Richiesta). L'Autore del Messaggio coincide col Richiedente oppure col Proprietario. L'ordine di presentazione dei Messaggi è dato dalla data di creazione del Messaggio.
Valutazioni: da scrivere
