Entradas sobre "plantillas":

Templatetag {% if %} con más comparaciones

Este snippet reemplaza la funcionalidad del templatetag {% if %} permitiendo realizar comparaciones con operadores >, <, >=, <=, != además de las comparaciones que permite hacer {% if %} por defecto. Por ejemplo una comparación con el operador mayor-igual-que para mostrar algo si hay más de 5 artículos sería:

{% if articulos|length >= 5 %} ... {% endif %}

Para utilizarlo en nuestro proyecto nos basta con seguir los siguientes pasos:

1. Descargamos smart_if desde djangosnippets.
2. Lo guardamos como smart_if.py en la carpeta templatetags de alguna de las aplicaciones de nuestro proyecto.
3. Añadimos el tag {% load smartif %} en las plantillas que queramos utilizarlo y listo.

También hay otro snippet, elif for smart if tag, que permite utilizar el tag {% elif %} para realizar otras comparaciones dentro de un bucle if con nuestro tag smart_if. Este snippet incluye sólo la función smart_if para que la reemplacemos en nuestro smart_if.py original.

Representar campos con choices en nuestras plantillas

Cuando usamos un campo con diferentes opciones (choices) en nuestro modelo utilizamos una lista de elementos cada uno con el valor real que se almacenará en la base de datos seguido por la representación legible del dato. Un ejemplo es el siguiente modelo:

ESTILOS_CHOICES = (
   ('soul', 'Soul'),
   ('jazz', 'Jazz'),
   ('hiphop', 'Hip-Hop'),
)

class Artista(models.Model):
   estilo=models.CharField(maxlength=10, choices=ESTILOS_CHOICES)

Suponiendo que tenemos una plantilla que recibe un objeto Artista en la variable {{ artista }} normalmente accedemos al valor de sus campos mediante {{ artista.campo }}. Pero al estar usando choices con {{ artista.estilo }} obtendremos el valor almacenado en la base de datos en vez de su representación legible definida en ESTILOS_CHOICES. ¿Cómo acceder a la forma legible del dato? Para ello tenemos la función get_FOO_display() que nos permite acceder al valor legible de cualquier campo del modelo que utilice choices.Basta con usar {{ artista.get_estilo_display }} en nuestra plantilla para mostrar la representación legible del campo.

La información sobre get_FOO_display() se encuentra en la referencia de modelos.

Idiomas en nuestras URLs gracias a django-localeurl

django-localeurl es una aplicación que permite el uso de códigos de idiomas en las URLs de nuestro proyecto. Esto trae la ventaja de que cada página en cada idioma tiene una URL propia. Gracias a ello los buscadores indexan cada página en los distintos idiomas disponibles y nuestros usuarios pueden compartir las URLs de una página en el idioma que deseen. Además funciona a la perfección con el LocaleMiddleware que viene con Django y que sirve para hacer la "negociación" para descubrir el idioma del usuario en función de si ya ha seleccionado un idioma previamente, si por el contrario debe utilizar el idioma de su navegador o como último recurso el idioma por defecto de nuestro proyecto.

django-localeurl nos permitirá cambiar nuestras URLs de http://mi-proyecto.com/noticias a URLs del tipo http://mi-proyecto.com/es/noticias, http://mi-proyecto.com/de/noticias, etc. No hará falta cambiar nada en nuestra URLconf para hacerlo funcionar.

import re
LOCALE_INDEPENDENT_PATHS = (
    re.compile('^/aviso-legal/'),
    re.compile('^/privacidad/'),
)

{% load localeurl_tags %}

<a href="{% url ver-articulo articulo.id %}">Ver artículo</a>

<a href="{% locale_url "en" ver-articulo articulo.id %}">Ver artículo en inglés</a>

<p>Haz <a href="{{ mi_url|chlocale:"de" }}">click aquí</a> para cambiar a alemán.</p>
<p>La url {{ otra_url }} sin código de lenguaje es {{ otra_url|rmlocale }}</p>

Settings accesibles desde las plantillas

Muchas veces deseamos acceder a los settings de nuestro proyecto desde alguna de nuestras plantillas. Lo ideal es crear un context processor que nos permita acceder a ellos desde cualquier plantilla de cualquier aplicación de nuestro proyecto.

Para ello en la carpeta de nuestro proyecto creamos un nuevo archivo context_processors.py con el siguiente código:

# importamos los settings del proyecto
from django.conf import settings as _settings

def settings(request):
    # los devolvemos en la variable de contexto "settings"
    return {'settings': _settings}

A continuación tenemos que añadir nuestro procesador de contexto a TEMPLATE_CONTEXT_PROCESSORS en nuestros settings (archivo settings.py). Recuerda que Django habilita los procesadores de contexto auth, debug e i18n por defecto. Al sobreescribir TEMPLATE_CONTEXT_PROCESSORS estaremos invalidándolos, por lo que deberemos añadirlos manualmente:

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'mi_aplicacion.context_processors.settings',)

Ahora podemos acceder fácilmente a nuestros settings desde cualquier plantilla utilizando el nombre del setting cuyo valor queremos obtener. Por ejemplo:

<html>
    <body>
        <p>Todos los archivos de media están en {{ settings.MEDIA_URL }}.
        La zona horaria para nuestro proyecto es {{ settings.TIME_ZONE }}</p>
    </body>
</html>

Importante: Recuerda que para que las variables de contexto sean accesibles desde las plantillas tus vistas tienen que utilizar RequestContext(request, diccionario_de_contexto) para instanciar un contexto en lugar de Context(dicionario_de_contexto). Si utilizas vistas genéricas no tienes de qué preocuparte, las vistas genéricas utilizan RequestContext por defecto. Ejemplo de vista utilizando RequestContext:

from django.template import RequestContext
from django.shortcuts import render_to_response

def mi_vista(request):
    return render_to_response('mi_plantilla.html', context_instance=RequestContext(request))