El libro de Django 1.0

17.2. Pesonalizar las plantillas de la interfaz

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.

Un formulario de edición de libros personalizado

Figura 17.1 Un formulario de edición de libros personalizado

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.