{"title":"Scrivere la tua prima applicazione in Django, parte 7","version":"4.2","locale":"it","docname":"intro/tutorial07","url":"/it/4.2/intro/tutorial07/","canonical":"https://djangodocs.dev/it/4.2/intro/tutorial07/","summary":"Questo tutorial inizia dove si è interrotto Tutorial 6 . Stiamo proseguendo con l’applicazione web per i questionari e ci concentreremo sul sito generato…","html":"

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

\n

Questo tutorial inizia dove si è interrotto Tutorial 6. Stiamo proseguendo con l’applicazione web per i questionari e ci concentreremo sul sito generato automaticamente per l’amministrazione di Django che abbiamo esplorato in prima battuta nel Tutorial 2.

\n\n
\n

Personalizzare il modulo di amministrazioneLink to this heading#

\n

Registrando il modello Question con admin.site.register(Question), Django è stato in grado di costruire un form di default. Spesso, vorrai personalizzare il modo in cui il form di amministrazione appare e funziona. Lo farai dicendo a Django quali opzioni vuoi quando registrerai l’oggetto.

\n

Vediamo come funziona riordinando i campi nel modulo di modifica. Sostituisci la riga admin.site.register(Question) con:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fields = ["pub_date", "question_text"]\n\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

Seguirai questo pattern – crea una classe del modello di amministrazione, poi passala come secondo argomento a admin.site.register() – ogni volta che vuoi cambiare le opzioni nel panello di amministrazione del modello.

\n

Questa particolare modifica qui sopra fa sì che la «Data di pubblicazione» venga prima del campo «Domanda»:

\n\"I\n

Questo non è impressionante con solo due campi, ma per i moduli di amministrazione con dozzine di campi, la scelta di un ordine intuitivo è un dettaglio importante per l’usabilità.

\n

E parlando di moduli con dozzine di campi, potresti voler dividere il modulo in gruppi di campi:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fieldsets = [\n        (None, {"fields": ["question_text"]}),\n        ("Date information", {"fields": ["pub_date"]}),\n    ]\n\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

Il primo elemento di ogni tupla in fieldsets è il titolo del fieldset. Ecco come il nostro form appare adesso:

\n\"I\n
\n\n
\n

Personalizzazione della lista per la modifica dell’interfaccia di amministrazioneLink to this heading#

\n

Ora che la pagina di amministrazione del modello Question sembra buona, facciamo qualche modifica alla pagina di «change list» – quella che mostra tutte le domande nel sistema.

\n

Ecco come appare a questo punto:

\n\"Pagina\n

Di default, Django mostra la str() di ogni oggetto. Qualche volta però può essere più utile se potessimo mostrare campi individuali. Per fare questo, usa l’opzione di amministrazione list_display, che è una tupla di nomi di campi da mostrare, come colonne, sulla pagina della lista dei cambiamenti per l’oggetto:

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ["question_text", "pub_date"]\n
\n

Di buona norma, aggiungiamo il metodo was_published_recently() da Tutorial 2:

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ["question_text", "pub_date", "was_published_recently"]\n
\n

Ora la pagina di elenco delle domande ha questo aspetto:

\n\"La\n

Puoi fare click sull’intestazione delle colonne per ordinare quei valori – eccetto nel caso di was_published_recently perchè l’ordinamento dell’output di un metodo non è supportato. Nota anche che l’intestazione di colonna per was_published_recently è, di default, il nome del metodo (con gli underscore a rimpiazzare gli spazi), e che ogni linea contiene la rappresentazione in stringa dell’oggetto.

\n

Puoi migliorarlo usando il decoratore display() su quel metodo (in polls/models.py), come segue:

\n
polls/models.py
\n
Python
from django.contrib import admin\n\n\nclass Question(models.Model):\n    # ...\n    @admin.display(\n        boolean=True,\n        ordering="pub_date",\n        description="Published recently?",\n    )\n    def was_published_recently(self):\n        now = timezone.now()\n        return now - datetime.timedelta(days=1) <= self.pub_date <= now\n
\n

Per più informazioni sulle proprietà configurabili attraverso il decoratore, vedi list_display.

\n

Modifica nuovamente il tuo file polls/admin.py e aggiungi un miglioramento alla pagina dell’elenco di modifiche Domanda: i filtri usando list_filter. Aggiungi la seguente riga in QuestionAdmin:

\n
Code
list_filter = ["pub_date"]\n
\n

Questo aggiunge una sidebar «Filtra» che permette all’utente di filtrare la lista per il campo pub_date:

\n\"La\n

Il tipo di filtro visualizzato dipende dal tipo di campo su cui stai filtrando. Poiché pub_date è un DateTimeField, Django sa fornire le opzioni di filtro appropriate: «Qualsiasi data», «Oggi», «Ultimi 7 giorni», «Questo mese», «Quest’anno».

\n

Sta venendo su bene. Aggiungiamo alcune funzionalità di ricerca:

\n
Code
search_fields = ["question_text"]\n
\n

Ciò aggiunge una casella di ricerca all’inizio dell’elenco delle modifiche. Quando qualcuno inserisce i termini di ricerca, Django cercherà nel campo question_text. Puoi utilizzare tutti i campi che desideri – anche se poiché utilizza una query LIKE dietro le quinte, limitare il numero di campi di ricerca a un numero ragionevole renderà più facile per il tuo database fare la ricerca.

\n

Adesso è anche un buon momento per notare che le liste dei cambiamenti ti danno la paginazione gratis. Di default, mostra 100 elementi per pagina. Change list pagination, search boxes, filters, date-hierarchies, e column-header-ordering lavorano tutti assieme come pensi che dovrebbero.

\n
\n
\n

Personalizza l’aspetto dell’amministrazioneLink to this heading#

\n

Chiaramente, avere «Django administration» nella parte superiore di ogni pagina di amministrazione è ridicolo. È solo testo segnaposto.

\n

Puoi comunque cambiarlo, usando il sistema di template di Django. L’admin di Django è costruita su Django stesso, e dunque le sue interfacce usano il sistema di template di Django.

\n
\n

Personalizzare i template del tuo progettoLink to this heading#

\n

Crea una directory templates nella directory del tuo progetto (quella che contiene manage.py). I modelli possono risedere ovunque sul tuo filesystem purché Django vi possa accedere. (Django viene eseguito come qualsiasi utente venga eseguito dal server.) Tuttavia, mantenere i modelli all’interno del progetto è una buona convenzione da seguire.

\n

Apri il tuo file delle impostazioni (mysite/settings.py, ricorda) e aggiungi un’opzione DIRS nell’impostazione TEMPLATES:

\n
mysite/settings.py
\n
Python
TEMPLATES = [\n    {\n        "BACKEND": "django.template.backends.django.DjangoTemplates",\n        "DIRS": [BASE_DIR / "templates"],\n        "APP_DIRS": True,\n        "OPTIONS": {\n            "context_processors": [\n                "django.template.context_processors.debug",\n                "django.template.context_processors.request",\n                "django.contrib.auth.context_processors.auth",\n                "django.contrib.messages.context_processors.messages",\n            ],\n        },\n    },\n]\n
\n

DIRS è una lista di directory su disco da controllare quando si caricano i template di Django; è un percorso di ricerca.

\n\n

Now create a directory called admin inside templates, and copy the\ntemplate admin/base_site.html from within the default Django admin\ntemplate directory in the source code of Django itself\n(django/contrib/admin/templates) into that directory.

\n\n

Quindi, modifica il file e sostituisci {{ site_header|default:_('Django administration') }} (comprese le parentesi graffe) con il nome del tuo sito come meglio credi. Dovresti finire con una sezione di codice tipo:

\n
Django template
{% block branding %}\n<h1 id="site-name"><a href="{% url 'admin:index' %}">Polls Administration</a></h1>\n{% endblock %}\n
\n

Usiamo questo approccio per insegnarti come sovrascrivere i modelli. In un progetto reale, probabilmente useresti l’attributo: django.contrib.admin.AdminSite.site_header per realizzare più facilmente questa particolare personalizzazione.

\n

Questo file di template contiene molto testo come {% block branding %} e {{ title }}. I tag {% e {{ sono parte del linguaggio di template di Django. Quando Django mostra admin/base_site.html, questo linguaggio di template sarà valutato per produrre la pagina HTML finale, come abbiamo visto in Tutorial 3.

\n

Nota che qualsiasi template predefinito del pannello di amministrazione di Django può essere sovrascritto. Per sovrascrivere un template, fai la stessa cosa che hai fatto con base_site.html – copialo dalla directory predefinita nella tua directory personalizzata e apporta le modifiche.

\n
\n
\n

Personalizzare i template della tua applicazioneLink to this heading#

\n

I lettori più attenti chiederanno: Ma se: l’impostazione: DIRS <TEMPLATES-DIRS> era vuota per impostazione predefinita, come ha fatto Django a trovare i modelli di amministrazione predefiniti? La risposta è che, poiché APP_DIRS è impostato su True, Django cerca automaticamente una sottodirectory templates/ all’interno di ogni pacchetto dell’applicazione, da usare come fallback (non dimenticare che django.contrib.admin è un’applicazione).

\n

La nostra applicazione per i sondaggi non è molto complessa e non necessita di modelli di admin personalizzati. Ma se diventasse più sofisticato e richiedesse la modifica dei modelli di amministrazione standard di Django per alcune delle sue funzionalità, sarebbe più sensato modificare i modelli nell’applicazione, piuttosto che quelli nel progetto. In questo modo, potresti includere l’applicazione sondaggi in qualsiasi nuovo progetto e avere la certezza che troverà i modelli personalizzati di cui ha bisogno.

\n

Vedi la documentazione sul caricamento dei template per ulteriori informazioni su come Django trova i suoi template.

\n
\n
\n
\n

Personalizza l’indice dell’amministrazioneLink to this heading#

\n

In modo simile, potresti voler personalizzare l’aspetto della pagina dell’indice di amministrazione di Django.

\n

Di default, mostra tutte le app in INSTALLED_APPS che sono state registrate con l’applicazione di admin, in ordine alfabetico. Potresti voler apportare modifiche significative al layout. Dopotutto, l’indice è probabilmente la pagina più importante dell’amministratore e dovrebbe essere facile da usare.

\n

Il modello da personalizzare è admin/index.html. (Fai lo stesso di admin/base_site.html nella sezione precedente - copialo dalla directory predefinita alla directory del tuo modello personalizzato). Modifica il file e vedrai che utilizza una variabile di modello chiamata app_list. Quella variabile contiene tutte le app Django installate. Invece di usarlo, puoi codificare link a pagine di amministrazione specifiche degli oggetti nel modo che ritieni migliore.

\n

When you’re comfortable with the admin, read part 8 of this\ntutorial to learn how to use third-party packages.

\n
","rootId":"writing-your-first-django-app-part-7","toc":[{"title":"Personalizzare il modulo di amministrazione","anchor":"customize-the-admin-form","children":[]},{"title":"Aggiunta di oggetti correlati","anchor":"adding-related-objects","children":[]},{"title":"Personalizzazione della lista per la modifica dell’interfaccia di amministrazione","anchor":"customize-the-admin-change-list","children":[]},{"title":"Personalizza l’aspetto dell’amministrazione","anchor":"customize-the-admin-look-and-feel","children":[{"title":"Personalizzare i template del tuo progetto","anchor":"customizing-your-project-s-templates","children":[]},{"title":"Personalizzare i template della tua applicazione","anchor":"customizing-your-application-s-templates","children":[]}]},{"title":"Personalizza l’indice dell’amministrazione","anchor":"customize-the-admin-index-page","children":[]}],"breadcrumbs":[{"docname":"intro/index","title":"Come iniziare","url":"/it/4.2/intro/"}],"prev":{"docname":"intro/tutorial06","title":"Scrivere la tua prima applicazione in Django, parte 6","url":"/it/4.2/intro/tutorial06/"},"next":{"docname":"intro/tutorial08","title":"Writing your first Django app, part 8","url":"/it/4.2/intro/tutorial08/"},"formats":{"html":"/it/4.2/intro/tutorial07/","markdown":"/it/4.2/intro/tutorial07.md","json":"/it/4.2/intro/tutorial07.json"},"source":"https://github.com/django/django/blob/stable/4.2.x/docs/intro/tutorial07.txt","official":"https://docs.djangoproject.com/it/4.2/intro/tutorial07/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2"],"inLocales":["en","zh-hans","fr","ja","id","it","pt-br","ko","es","el","pl"]}