Entradas sobre "settings":

Rutas relativas en los settings

Utilizar rutas relativas en nuestro settings.py en lugar de rutas absolutas permite que el proyecto no dependa del lugar en el que se encuentra en el sistema de archivos. Esto es ideal cuando utilizamos el proyecto en distintos entornos y las rutas absolutas del proyecto son distintas en cada uno de ellos, o si la ruta del proyecto puede variar en algún momento.

Hay dos settings que dependen de rutas del sistema: MEDIA_ROOT y TEMPLATE_DIRS. Para ellos podemos utilizar la propia ruta del proyecto de la siguiente manera con el fin de que las rutas sean relativas. El siguiente ejemplo asume que templates y media se encuentran dentro de la ruta del proyecto:

# settings.py
import os

# ruta del proyecto
PROJECT_PATH = os.path.realpath(os.path.dirname(__file__))

TEMPLATE_DIRS = (
    os.path.join(PROJECT_PATH, 'templates'),
)

MEDIA_ROOT = os.path.join(PROJECT_PATH, 'media')

Publicado por Antonio Melé el Martes 15 d Febrero d 2011 | 4 comentarios | Categorías: settings, trucos

Expires headers lejanos y versiones de media

Un buen truco para mejorar el tiempo de carga de nuestras páginas es añadir a los archivos de media (imágenes, css, js) el header Expires (ver headers de HTML) con una fecha lejana (por ejemplo un año de diferencia). Este header define cuándo expira el archivo, es decir, hasta cuando el navegador puede considerar la respuesta del archivo válida. Esto significa que cuando el navegador descarga un archivo con header Expires puede almacenarlo en caché y utilizarlo sin tener que volver a descargarlo otra vez cuando el usuario visite de nuevo el sitio web, hasta que llegue la fecha descrita en el header Expires.

Utilizar un header Expires lejano nos ahorrará tráfico y disminuirá el tiempo de carga de nuestro sitio web para aquellos usuarios que nos vuelven a visitar. El problema se nos presenta cuando modificamos alguno de los archivos de media: Los navegadores de muchos visitantes seguirán utilizando los archivos almacenados en caché en vez de los nuevos. Para solucionar este problema conviene utilizar versiones en nuestros archivos de media.

Podríamos renombrar los archivos de media cada vez que los modificáramos, pero tendríamos que hacerlo a su vez en las plantillas que los utilizan. Por ello vamos a utilizar otro método que consiste en añadir un parámetro de versión a todos los archivos media independientemente de cuando hayan sido modificados. Vamos a crear un templatetag que nos permita cambiar de versión fácilmente y sin necesidad de renombrar nuestros archivos.

Dentro de la carpeta templatetags de nuestar aplicación añadimos un archivo media.py con el siguiente contenido:

from django.conf import settings
from django import template

register = template.Library()

def media_url(url):
    return '%s%s?%s' % (settings.MEDIA_URL, url, settings.MEDIA_VERSION)

register.simple_tag(media_url)

En este archivo hemos definido el templatetag media_url. Nuestro templatetag utiliza el setting MEDIA_URL, una URL que recibe como argumento y el setting MEDIA_VERSION para generar una URL del tipo http://misitio.com/media/base.css?001. Debemos editar el settings.py de nuestro proyecto para añadir el setting MEDIA_VERSION con el que llevaremos el control de versiones de media. De esta forma nuestro settings.py incluirá tanto MEDIA_URL como MEDIA_VERSION definiendo la URL de media de nuestro proyecto como la versión actual de nuestros archivos de media:

# ...
MEDIA_URL = 'http://misitio.com/media/'
MEDIA_VERSION = '001'

Cuando modifiquemos alguno de los archivos de media bastará con modificar el setting MEDIA_VERSION para que los navegadores no sigan utilizando la versión de los archivos que mantienen caché.

En nuestras plantillas bastará con utilizar el templatetag que hemos creado cada vez que necesitemos incluir una URL de media:

<html>
    <head>
        {% load media %}
        <link rel="stylesheet" href="{% media_url 'css/base.css' %}" type="text/css" />
    </head>
    ...
</html>

Publicado por Antonio Melé el Viernes 22 d Mayo d 2009 | 2 comentarios | Categorías: media, settings, templatetags, trucos

Enviar e-mails con Django y GMail

Personalmente siempre he utilizado mi propio servidor SMTP para el envio de e-mails con Django, pero hoy me he topado con este post en español sobre el post original de Nathan Ostgard que explica fácilmente qué settings debes añadir a tu proyecto para que Django envíe e-mails a través de GMail. Muy útil cuando no disponemos de un servidor SMTP propio.

Los settings a añadir son los siguientes:

EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'mi-usuario@gmail.com'
EMAIL_HOST_PASSWORD = 'mi-password'
EMAIL_PORT = 587
EMAIL_USE_TLS = True

Si utilizas Google Apps para tu dominio o has añadido otras cuentas de e-mail de otros dominios a tu cuenta de GMail también podrás utilizar éstas en el setting EMAIL_HOST_USER. Para que sea la cuenta de e-mail remitente por defecto puedes añadir DEFAULT_FROM_EMAIL a tu archivo de settings con la misma dirección de correo electrónico.

Publicado por Antonio Melé el Viernes 26 d Diciembre d 2008 | 5 comentarios | Categorías: e-mail, settings, trucos

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))

Publicado por Antonio Melé el Miércoles 26 d Noviembre d 2008 | 1 comentario | Categorías: plantillas, settings, trucos

Feed RSS

Suscríbete a nuestro feed RSS y al feed de la comunidad para estar al tanto de todo lo que ocurre entorno a Django.

Proyectos

django-thumbs te permite crear miniaturas de imágenes con Django.

Escribe en el blog

Tú también puedes escribir en éste blog. Para hacerlo basta con que nos digas sobre qué quieres escribir un artículo relacionado con Django.