Enero 29, 2010 - 12:20 pm - Posted by Camilo Nova
La Paginación en django es excelente, permite una flexibilidad importante para solucionar muchos problemas que se presentan al paginar resultados, por ejemplo el problema del cacheo, que se presenta al realizar una consulta que pide todos los datos sabiendo que solo vamos a mostrar unos pocos.
Gracias a la excelente documentación podemos encontrar toda la información aquí: http://docs.djangoproject.com/en/1.1/topics/pagination/#topics-pagination
Sin embargo, cuando se trabajan volúmenes grandes de información, digamos mas de 50 paginas, se hace dispendioso pasar entre paginas hasta llegar a la que buscamos, por eso es muy útil tener una paginación al estilo Digg que muestra algunas paginas adicionales y no solo el enlace a la anterior y la siguiente.
Tomando como base este excelente trabajo: http://krisje8.com/blog/2009/jul/02/django-pagination-template-tag-digg-style/ realice algunas modificaciones para que muestre ‘…’ entre las paginas iniciales y la pagina actual, para darle una mejor ubicación al usuario sobre donde se encuentra.
Tenemos el siguiente template_tag:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| #! /usr/bin/env python
# -*- coding: utf8 -*-
# render_paginator.py
from django.template import Library
register = Library()
def render_paginator(context, first_last_amount=2, before_after_amount=4):
page_obj = context['page_obj']
paginator = context['paginator']
page_numbers = []
# Pages before current page
if page_obj.number > first_last_amount + before_after_amount:
for i in range(1, first_last_amount + 1):
page_numbers.append(i)
page_numbers.append(None)
for i in range(page_obj.number - before_after_amount, page_obj.number):
page_numbers.append(i)
else:
for i in range(1, page_obj.number):
page_numbers.append(i)
# Current page and pages after current page
if page_obj.number + first_last_amount + before_after_amount < paginator.num_pages:
for i in range(page_obj.number, page_obj.number + before_after_amount + 1):
page_numbers.append(i)
page_numbers.append(None)
for i in range(paginator.num_pages - first_last_amount + 1, paginator.num_pages + 1):
page_numbers.append(i)
else:
for i in range(page_obj.number, paginator.num_pages + 1):
page_numbers.append(i)
return {
'paginator': paginator,
'page_obj': page_obj,
'page_numbers': page_numbers
}
register.inclusion_tag('layout/pagination.html', takes_context=True)(render_paginator) |
Con la siguiente plantilla:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| {% if page_obj.has_previous %}
<a href="?page={{ page_obj.previous_page_number }}">Previous</a>
{% endif %}
{% for page in page_numbers %}
{% if page %}
{% ifequal page page_obj.number %}
<b>{{ page }}</b>
{% else %}
<a href="?page={{ page }}">{{ page }}</a>
{% endifequal %}
{% else %}
...
{% endif %}
{% endfor %}
{% if page_obj.has_next %}
<a href="?page={{ page_obj.next_page_number }}">Next</a>
{% endif %} |
Para usarlo se coloca el siguiente codigo en cualquiera de las plantillas que queramos paginar:
1
2
3
4
| {% if is_paginated %}
{% load render_paginator %}
{% render_paginator 2 3 %}
{% endif %} |
Lo que genera un código como:
1
| Previous 1 2 ... 5 6 7 8 9 10 11 ... 25 26 Next |
Lo mejor de todo es que no necesita ningún componente adicional ni interfiere con la paginación por defecto que traen las vistas genéricas en django.
Etiquetas: Codigo Fuente, Django, Python | 2 Comentarios »
Noviembre 3, 2009 - 8:31 am - Posted by Camilo Nova
En AxiaCore utilizamos subversion para llevar el control de versiones de los proyectos, junto a nuestro esquema de desarrollo ágil manejamos ciclos cortos de lanzamiento de nuevas funcionalidades, por eso para nosotros es necesario conocer el numero de revisión del SVN y publicarlo en un lugar fácilmente accesible para los usuarios, de tal forma que rápidamente nos puedan indicar la versión que están utilizando.
La aproximación inicial es tener un parámetro donde se indique un numero de versión de la aplicación, pero esta fue rápidamente descartada porque no es flexible y se tendría que cambiar la versión manualmente en cada nuevo cambio, así que decidimos manejar el numero de revisión del repositorio como el indicador de la versión. Ahora bien, se necesita una manera automática de obtener dicho numero y publicarlo en una plantilla HTML para verlo en la interfaz de usuario.
Lo resolvimos así:
Partimos de la plantilla donde básicamente django nos permite lo siguiente:
1
2
| {% load version_tag %}
<p>Version: {% get_version %}</p> |
Entonces cargamos un ‘custom tag’ que nos retorna la versión actual de la aplicación, el cual es:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| #! /usr/bin/env python
# -*- coding: utf8 -*-
import subprocess
from django import template
from django.core.cache import cache
register = template.Library()
@register.simple_tag
def get_version():
"""
Retorna el numero de version para la aplicacion y lo almacena en
cache para evitar ser llamado multiples veces y mejorar el rendimiento
de la aplicacion.
"""
if not cache.get('version'):
comando = 'svn info | grep Rev | head -1'
try:
proc = subprocess.Popen(comando, shell=True,
stdout=subprocess.PIPE, stderr=subprocess.PIPE
)
line = proc.communicate()[0]
version = line[line.find(" ")+1:].rstrip("\n")
except:
version = '---'
tiempo = 24 * 60 * 60 #Tiempo en segundos de un dia
cache.set('version', version, tiempo)
return cache.get('version') |
Este archivo (version_tag.py) debe estar dentro de una carpeta llamada ‘templatetags’ de alguna aplicación del proyecto.
Lo interesante de esta solución es:
- Obtiene el numero de versión por el comando ’svn info’
- Reduce las llamadas al comando ubicando la información en cache durante un día
- Es totalmente desacoplado del proyecto y se puede reutilizar fácilmente
- Se puede adaptar para otros sistemas de control de versiones
Que les parece?
Etiquetas: Desarrollo, Django, Python | 2 Comentarios »
Septiembre 22, 2009 - 10:14 pm - Posted by Camilo Nova
Plantillas para Django en el editor Scribes
Espero les sean utiles. Saludos
Etiquetas: Django, Scribes, Templates | Comente »
Marzo 11, 2009 - 11:16 am - Posted by Camilo Nova
Trabajando con modelos en Django para aplicaciones web de alto perfil, como las desarrolladas por AxiaCore, nos encontrábamos frecuentemente con tener que hacer cálculos aritméticos básicos manualmente sobre un conjunto de datos en particular.
Por ejemplo si necesitábamos obtener el total de ventas de un mes determinado, se tenia que iterar cada elemento del conjunto de datos (QuerySet) e ir sumando en una variable cada valor obtenido, los que hemos trabajado con aplicaciones conectadas a una base de datos sabemos que existen funciones de SQL con SUM() que efectúan esa tarea mucho mas cómodamente.
Afortunadamente para la nueva versión de Django, próxima a salir, la v1.1 existe la posibilidad de utilizar ‘Agregaciones’ y ‘Anotaciones’ que permiten efectuar este tipo de cálculos de una manera mucho mas fácil y recargando la responsabilidad de los cálculos a la base de datos y no a la lógica de la aplicación.
Factura.objects.aggregate(
Avg('precio'), Max('precio'), Min('precio'), Sum('precio')
)Mas información en la documentación oficial del proyecto.
Enlace: http://docs.djangoproject.com/en/dev/topics/db/aggregation/
Etiquetas: Desarrollo, Django | 3 Comentarios »
Enero 21, 2009 - 12:07 pm - Posted by Camilo Nova
Es posible declarar tipos ForeignKey en un modelo de datos de Django, pero puede que necesitemos filtrar los valores de esta relación, para efectuar tal cambio necesitamos recurrir al Form que muestra ese modelo y modificar el método __init__ de la siguiente manera:
1
2
3
4
| class MyModelForm(forms.Form):
def __init__(self, *args, **kwargs):
super(MyModelForm, self).__init__(*args, **kwargs)
self.fields["myFKField"].queryset = MyModel.objects.all() |
Esto permite cambiar los datos que son mostrados por el campo en el Form por unos filtrados que nosotros queramos, existe tambien la posibilidad de trabajar con limit_choices_to de ForeignKey pero esta solución me funciono de inmediato.
Etiquetas: Codigo Fuente, Django, Python | Comente »
