GaRaGeD Style

O la evidencia de que hay un ser supremo que nos ayuda a hacer las cosas bien

@login_required
def object_list(request, model, page):
    try:
        request.GET['filter']
        qry_set = model.objects.filter(
                Q(name__contains=request.GET['filter'])|
                Q(user__contains=request.GET['filter'])|
                Q(ipaddr__contains=request.GET['filter']),
                ).order_by('name')
        return list_detail.object_list(
                request,
                queryset = qry_set,
                template_name = 'base/%s_list.html' % model.__name__.lower(),
                paginate_by = 50,
                page = page,
                extra_context = { 'filter': request.GET['filter'] },
                )
    except:
        return render_to_response('base/empty_list.html')

object_list = cache_page(object_list, 300)

En realidad parte de este codigo no me gusta mucho, pero es suficientemente bonito (IMNSHO) como para comentarlo un poco (dada la escases de temas en mi cabeza).

Incluso viendo el código, antes de publicarlo logré una optimización bastante tonta (un doble try innecesario).

Básicamente esta “vista” devuelve una pantalla vacía (con un <input>) si no está definida la variable “filter” en el GET de HTTP, si está definida busca en 3 campos la cadena que viene de esa variable y devuelve una lista, que en este caso se presenta como una tabla.

Lo bonito de esta vista, es que sin grandes malabares, puros “one-liners” incluye autenticación, caché, y paginación.

Los urls que alimentan los argumentos de la funcion son:

from django.conf.urls.defaults import *
from iplist_simple.base import models, views


urlpatterns = patterns('',
        (r'^$', views.object_list, {'model': models.ipdata, 'page': 0}),
        (r'^page/(?P[0-9]+)/$', views.object_list, {'model': models.ipdata}),
)

El primero manda “page=0” dado que estamos en la primera página, el segundo manda la página correspondiente segun el URL. Y obviamente mandamos el modelo que queremos que se utilice para esta búsqueda. Podríamos lograr que la funcion “object_list” (que es una vista genérica de django), fuera mas portable si no tuvieramos que buscar sobre columnas específicas, pero en este caso particular no es posible fácilmente, por la especificidad de los campos de búsqueda.

Ya lo demás es crear una plantilla, que no tiene ningun chiste, los valores de cada columna se pueden ciclar con algo como esto: {% for entry in object_list %} … {% endfor %}

Hay detalles, como el hecho de que no hay una funcion en python para verificar si una variable o arreglo está definido, por ello el try:, y por otro lado el detalle de que no puedo hacer mas portable la funcion genérica, porque cada modelo que la tendría columnas con nombres diferentes,y querriamos buscar sobre columnas diferentes (en teoria).

Tal vez haya una forma de hacerla mas portable, si a alguien se le ocurre por favor no dude en decirmela (probablemente mandando un arreglo en el urls.py de las columnas a buscar).

In: Uncategorized | | #