Como sale de fábrica, Django provee un número de herramientas para personalizar las plantillas de la interfaz que vienen integradas, las cuales veremos pronto, pero para las tareas detrás de ellas (por ejemplo, cualquier cosa que requiera un flujo de trabajo específico o permisos granulares), necesitarás leer la sección titulada "Creando vistas de administración personalizadas", más adelante en este capítulo.
Para ahora, miremos algunas maneras rápidas de modificar el aspecto (y en cierto grado, el comportamiento) de la interfaz de administración. El Capítulo 6 cubre algunas de las tareas más comunes: "cambiar la marca" de la interfaz de administración (para todos esos jefes raritos que odian el azul) y proveer un formulario de administración personalizado.
Pasado ese punto, el objetivo normalmente implica cambiar alguna de las plantillas para un item en particular. Cada vista de administración — las listas de cambio, los formularios de edición, las páginas de confirmación de eliminación y vistas de historial — tienen una plantilla asociada que puede ser reescrita de diferentes maneras.
Primero, puedes reescribir la plantilla globalmente. La vista de administración busca plantillas utilizando el mecanismo de carga de plantillas estándar, por lo que si creas tus plantillas en alguno de los directorios declarados para tal fin, Django cargará esas en vez de las vienen por defecto. Estas plantillas globales se describen el la siguiente tabla.
Vista | Nombre de la plantilla base |
---|---|
Lista de cambios | admin/change_list.html |
Formulario para agregar/editar | admin/change_form.html |
Confirmación de eliminación | admin/delete_confirmation.html |
Historial de un objeto | admin/object_history.html |
La mayoría de las veces, sin embargo, querrás cambiar la plantilla sólo para un único objeto o aplicación (no globalmente). Así, cada vista busca primero plantillas para modelos y aplicaciones específicas, en el siguiente orden:
admin/<app_label>/<object_name>/<template>.html
admin/<app_label>/<template>.html
admin/<template>.html
Por ejemplo, la vista del formulario de agregar/editar para un modelo Libro
en la aplicación libros
busca plantillas en este orden:
admin/books/book/change_form.html
admin/books/change_form.html
admin/change_form.html
17.2.1. Plantillas de modelos propios
La mayoría de las veces querrás usar la primer plantilla para crear una basada destinada a un modelo específico. Normalmente la mejor forma de realizar esto es extendiendo y agregando información a uno de los bloques definidos en la plantilla que se está modificando.
Por ejemplo, supongamos que queremos agregar un pequeño texto de ayuda en la cabecera de nuestra página de libros. Quizás algo parecido a lo que muestra la Figura 17-1.
Esta es una manera muy fácil de hacerlo: simplemente crea una plantilla llamada
admin/libreria/libro/change_form.html
e inserta este código:
{% extends "admin/change_form.html" %}
{% block form_top %}
<p>Insert meaningful help message here...</p>
{% endblock %}
Todas estas plantillas definen un número de bloques que puedes sobreescribir.
Como con la mayoría de los programas, la mejor documentación es el propio
código, por lo que te animamos a mirar las plantillas originales (que se
encuentran en django/contrib/admin/templates/
) para trabajar con la
información más actualizada.
17.2.2. JavaScript Personalizado
Un uso común para estas plantillas propias para modelos implica agregar código JavaScript extra a las páginas de la interfaz — posiblemennte para implementar algún widget especial o un comportamiento del lado del cliente.
Por suerte, esto no podría ser más fácil. Cada plantilla del administrador
define un {% block extrahead %}
, el cual puedes usar para incluir contenido
extra dentro del elemento <head>
. Por ejemplo, incluir la librería jQuery (
http://jquery.com/) en tu página de historia de objetos, es tan simple como
esto:
{% extends "admin/object_history.html" %}
{% block extrahead %}
<script src="http://media.ejemplo.com/javascript/jquery.js" type="text/javascript"></script>
<script type="text/javascript">
// code to actually use jQuery here...
</script>
{% endblock %}
Nota No estamos seguros porqué necesitarías jQuery en la página de historia de objetos, pero, por supuesto, este ejemplo es válido para cualquier plantilla de la interfaz de administración.
Puedes usar esta técnica para incluir cualquier tipo de controladores JavaScript que puedas necesitar en tus formularios.