{"title":"Escribiendo su primera aplicación Django, parte 7","version":"3.1","locale":"es","docname":"intro/tutorial07","url":"/es/3.1/intro/tutorial07/","canonical":"https://djangodocs.dev/es/3.1/intro/tutorial07/","summary":"Este tutorial comienza donde quedó el Tutorial 6 . Continúamos con la aplicación Web encuestas y nos vamos a enfocar en personalizar el sitio administrativo de…","html":"

Escribiendo su primera aplicación Django, parte 7Link to this heading#

\n

Este tutorial comienza donde quedó el Tutorial 6. Continúamos con la aplicación Web encuestas y nos vamos a enfocar en personalizar el sitio administrativo de Django generado automáticamente que estudiamos primero en el Tutorial 2.

\n\n
\n

Personalice el formulario del sitio administrativoLink to this heading#

\n

Al registrar el modelo Question con admin.site.register (Question)`, Django pudo construir una representación del formulario predeterminado. A menudo, usted querrá personalizar el aspecto y el funcionamiento del formulario del sitio administrativo. Usted hará esto indicándole a Django las opciones que desee cuando registre el objeto.

\n

Veamos cómo funciona esto reordenando los campos en el formulario de edición. Reemplace la línea 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\nadmin.site.register(Question, QuestionAdmin)\n
\n

Usted seguirá este patrón - cree una clase de modelo del sitio administrativo y luego pásela como el segundo argumento a admin.site.register() - cada vez que necesite cambiar las opciones del sitio administrativo para un modelo.

\n

Esta modificación concreta citada anteriormente hace que la «Publication date» se anteponga al campo «Question»:

\n\"Fields\n

Esto no es tan impresionante con sólo dos campos, pero para los formularios del sitio administrativo con docenas de campos, elegir un orden intuitivo es un detalle importante de usabilidad.

\n

Y hablando de formularios con docenas de campos, es posible que desee dividir el formulario en grupos de campos:

\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\nadmin.site.register(Question, QuestionAdmin)\n
\n

El primer elemento de cada tupla en fieldsets es el título del grupo de campos. Así es como se ve el formulario ahora:

\n\"Form\n
\n\n
\n

Personalice la lista de cambios del sitio administrativoLink to this heading#

\n

Ahora que la página de administración Question se ve bien, vamos a hacer algunos ajustes a la página «change list» – la que muestra todas las preguntas en el sistema.

\n

Así es como se ve en este momento:

\n\"Polls\n

Por defecto, Django muestra el str() de cada objeto, pero a veces sería más útil si pudiéramos mostrar los campos individuales. Para hacerlo, utilice la opción del sitio administrativo :attr::~django.contrib.admin.ModelAdmin.list_display, que es una tupla de nombres de campos para que se muestre como columnas en la página de lista de cambios para el objeto:

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

For good measure, let’s also include the was_published_recently() method\nfrom 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

Ahora la página de lista de cambios de preguntas se ve así:

\n\"Polls\n

Usted puede hacer clic en las cabeceras de las columnas para ordenar por esos valores ,excepto en el caso de la cabecera was_published_recently, porque ordenar por la salida de un método arbitrario no está soportado. También tenga en cuenta que la cabecera de la columna was_published_recently es, por defecto, el nombre del método (con guiones bajos reemplazado con espacios), y que cada línea contiene la representación de cadena de la salida.

\n

Usted puede mejorar eso al darle a ese método (en el archivo polls/models.py) algunos atributos, de la siguiente manera:

\n
polls/models.py
\n
Python
class Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        now = timezone.now()\n        return now - datetime.timedelta(days=1) <= self.pub_date <= now\n    was_published_recently.admin_order_field = 'pub_date'\n    was_published_recently.boolean = True\n    was_published_recently.short_description = 'Published recently?'\n
\n

Para obtener más información sobre estas propiedades del método, consulte list_display.

\n

Edite de nuevo su archivo polls/admin.py y añada una mejora a la página Question en la lista de cambios: filtre utilizando el list_filter. Agregue la siguiente línea a QuestionAdmin:

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

Eso añade una barra lateral «Filter» que le permite a los usuarios filtrar la lista de cambios mediante el campo pub_date:

\n\"Polls\n

El tipo de filtro que se muestra depende del tipo de campo que está filtrando. Debido a que la pub_date es una DateTimeField, Django sabe dar opciones de filtro apropiadas: «Any date», «Today», «Past 7 days», «This month», «This year».

\n

Esto se perfila bien. Vamos a añadir un poco de capacidad de búsqueda:

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

Eso añade un cuadro de búsqueda en la parte superior de la lista de cambios. Cuando alguien introduce los términos de búsqueda, Django buscará el campo question_text. Usted puede utilizar tantos campos como desee, sin embargo, ya que utiliza una petición LIKE detrás de bastidores, limitar el número de campos de búsqueda a un número razonable le facilitará la búsqueda a su base de datos.

\n

Ahora también es un buen momento para señalar que las listas de cambios le dan paginación libre. El modo predeterminado muestra 100 items por página. Paginación de la lista de cambios, cuadros de búsqueda, :attr:`filtros, jerarquías de fecha y orden de la cabecera de columnas todos trabajan juntos como usted piensa que deberían.

\n
\n
\n

Personalice el aspecto del sitio administrativoLink to this heading#

\n

Está claro que tener «Django administration» en la parte superior de cada página del sitio administrativo es ridículo. Es sólo texto del marcador de posición.

\n

You can change it, though, using Django’s template system. The Django admin is\npowered by Django itself, and its interfaces use Django’s own template system.

\n
\n

Personalizando las plantillas de su proyectoLink to this heading#

\n

Cree un directorio templates en el directorio de su proyecto (el que contiene manage.py). Las plantillas se pueden ubicar en cualquier parte de su sistema de archivos al que Django pueda acceder. (Django ejecuta como cualquier usuario ejecuta su servidor.) Sin embargo, una buena práctica a seguir es guardar sus plantillas en el proyecto.

\n

Abra el archivo de configuraciones (mysite/settings.py, recuerde) y añada una opción DIRS en la opción 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 es una lista de directorios del sistema de archivos utilizada para comprobar cuando se cargan las plantillas de Django; es una ruta de búsqueda.

\n\n

Ahora cree un directorio llamado admin dentro de templates y copie la plantilla admin/base_site.html desde dentro del directorio de plantillas predeterminado del sitio administrativo de Django en el código fuente de Django (django/contrib/admin/templates) en ese directorio.

\n\n

Then, edit the file and replace\n{{ site_header|default:_('Django administration') }} (including the curly\nbraces) with your own site’s name as you see fit. You should end up with\na section of code like:

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

Utilizamos este método para enseñarle cómo reemplazar las plantillas. En un proyecto real, usted probablemente utilizaría el atributo django.contrib.admin.AdminSite.site_header para hacer este ajuste particular con mayor facilidad.

\n

Este archivo de plantillas contiene una gran cantidad de texto como {% block branding%} y {{title}}. Las etiquetas {% y {{ son parte del lenguaje de plantillas de Django. Cuando Django crea admin/base_site.html, este lenguaje de plantilla será evaluado para generar la página HTML definitiva, como vimos en el Tutorial 3.

\n

Note that any of Django’s default admin templates can be overridden. To\noverride a template, do the same thing you did with base_site.html – copy\nit from the default directory into your custom directory, and make changes.

\n
\n
\n

Personalizando las plantillas de su aplicaciónLink to this heading#

\n

Los lectores agudos preguntarán: ¿Pero si DIRS estaba vacío por defecto, ¿Cómo Django estaba buscando las plantillas del sitio administrativo predeterminado? La respuesta es que, ya que APP_DIRS <TEMPLATES-APP_DIRS está fijado como True, Django busca automáticamente un subdirectorio templates/ dentro de cada paquete de la aplicación, para su uso como una solución alternativa (no olvide que django.contrib.admin es una aplicación).

\n

Nuestra aplicación encuestas no es muy compleja y no necesita las plantillas personalizadas del sitio administrativo. Pero si se hiciera más sofisticada y requiriera la modificación de las plantillas convencionales del sitio administrativo de Django para algunas de sus funciones, sería más sensato modificar las plantillas de la aplicación, en lugar de las que están en el proyecto. De esa manera, usted podría incluir la aplicación encuestas en cualquier nuevo proyecto y estaría seguro de que esta encontraría las plantillas personalizadas que necesitaba.

\n

Consulte la documentación sobre la carga de plantillas para obtener más información sobre cómo Django encuentra sus plantillas.

\n
\n
\n
\n

Personalice la página del índice del sitio administrativoLink to this heading#

\n

En este sentido, es posible que desee personalizar la apariencia de la página de índice del sitio administrativo de Django.

\n

Por defecto, muestra todas las aplicaciones que se encuentran en INSTALLED_APPS que han sido registradas en la aplicación del sitio administrativo en orden alfabético. Es posible que desee realizar cambios significativos en el diseño. Después de todo, el índice es probablemente la página más importante del sitio administrativo y debería ser fácil de usar.

\n

La plantilla a personalizar es admin/index.html. (Haga lo mismo que hizo con admin/base_site.html en la sección anterior: cópiela desde el directorio predeterminado en el directorio de plantillas personalizadas). Edite el archivo y verá que utiliza una variable de plantilla llamada app_list. Esa variable contiene todas las aplicaciones instaladas de Django. En lugar de utilizar esa, usted puede predeterminar enlaces a páginas del sitio administrativo específicas de objeto de la manera que le parezca mejor.

\n
\n
\n

¿Qué sigue?Link to this heading#

\n

El tutorial para principiantes finaliza aquí. Mientras tanto, es posible que desee ver algunos consejos sobre a dónde ir a partir de ahora.

\n

Si está familiarizado con el empaquetado Python e interesado en aprender cómo convertir la aplicación encuestas en una «aplicación reutilizable», consulte el tutorial avanzado: Cómo escribir aplicaciones reutilizables.

\n
","rootId":"writing-your-first-django-app-part-7","toc":[{"title":"Personalice el formulario del sitio administrativo","anchor":"customize-the-admin-form","children":[]},{"title":"Agregando objetos relacionados","anchor":"adding-related-objects","children":[]},{"title":"Personalice la lista de cambios del sitio administrativo","anchor":"customize-the-admin-change-list","children":[]},{"title":"Personalice el aspecto del sitio administrativo","anchor":"customize-the-admin-look-and-feel","children":[{"title":"Personalizando las plantillas de su proyecto","anchor":"customizing-your-project-s-templates","children":[]},{"title":"Personalizando las plantillas de su aplicación","anchor":"customizing-your-application-s-templates","children":[]}]},{"title":"Personalice la página del índice del sitio administrativo","anchor":"customize-the-admin-index-page","children":[]},{"title":"¿Qué sigue?","anchor":"what-s-next","children":[]}],"breadcrumbs":[{"docname":"intro/index","title":"Empezando","url":"/es/3.1/intro/"}],"prev":{"docname":"intro/tutorial06","title":"Escribiendo su primera aplicación en Django, parte 6","url":"/es/3.1/intro/tutorial06/"},"next":{"docname":"intro/reusable-apps","title":"Tutorial Avanzado: Cómo escribir aplicaciones reutilizables","url":"/es/3.1/intro/reusable-apps/"},"formats":{"html":"/es/3.1/intro/tutorial07/","markdown":"/es/3.1/intro/tutorial07.md","json":"/es/3.1/intro/tutorial07.json"},"source":"https://github.com/django/django/blob/stable/3.1.x/docs/intro/tutorial07.txt","official":"https://docs.djangoproject.com/es/3.1/intro/tutorial07/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","zh-hans","fr","ja","id","pt-br","ko","es","el","pl"]}