🇬🇧 Read it in English, “GenList“

Anteriormente hablábamos sobre CodenerixModel para entender como se construye un modelo funcional con CODENERIX. Sin embargo, para que todo funciocune en Django, además de los modelos también hay que definir las vistas. Para permitir visualizar los contenidos webs existen a disposición del programador un conjunto de vistas heredables, todas ellas basadas en Vistas Genéricas de Django, y que siguiendo la política de CODENERIX son tan simples de usar como heredar de ellas.

En este artículo os hablaré sobre GenList, que es la vista genérica de CODENERIX que permite visualizar el listado de un modelo. GenList hereda directamente de ViewList de Django, por lo que todas las propiedades de un ViewList están disponibles en GenList. Veamos como sería el listado de un modelo “Contact”:

from codenerix.views import GenList
from app.models import Contact

class ContactList(GenList):
    model = Contact

Tan simple como eso, y el resultado visual equivaldría a algo parecido a esto (si usas los Ejemplos de CODENERIX):

Listado de contactos

De este modo hemos conseguido visualizar el modelo Contact del ejemplo “agenda” que tenéis aquí:

class Contact(CodenerixModel):
    first_name = models.CharField(verbose_name=_(u'Nombre(s)'), max_length=128)
    last_name = models.CharField(verbose_name=_(u'Apellidos'), max_length=128, blank=True, null=True)
    alias = models.CharField(verbose_name=_(u'Alias'), max_length=32, blank=True, null=True)
    organization = models.CharField(verbose_name=_(u'Organización'), max_length=64, blank=True, null=True)
    borndate = models.DateField(verbose_name=_(u'Cumpleaños'), blank=True, null=True)
    address = models.TextField(verbose_name=_(u'Dirección'), blank=True, null=True)
    created_by = models.ForeignKey(User, verbose_name=_(u'Creado por'), on_delete=models.CASCADE, related_name='contacts')

    def __fields__(self, info):
        return (
            ('first_name', _(u'Nombre(s)')),
            ('last_name', _(u'Apellidos')),
            ('alias', _(u'Alias')),
            ('organization', _(u'Organization')),
        )

Ya te habrás percatado que CODENERIX ha usado el método __fields__ del modelo para descubrir qué campos debe mostrar en el listado. Además se ha tomado la libertad de ofrecernos automáticamente un listado que permite ordenación ascendente/descendente acumulativa en cada uno de sus campos (ver columna “Last name” en la siguiente captura) y si pulsamos el icono del filtro (color celeste en la siguiente captura) incluso podremos ver que también se ha ocupado de permitirnos buscar en los campos uno por uno (ver columna “Organization” donde buscamos “Inc” limitando el listado a 2 resultados):

Listado de contactos filtrado con ordenación

En fin, que heredando de GenList hemos conseguido un gran trabajo con un resultado visual excelente para nuestros usuarios.

Pero GenList al igual que CodenerixModel permite usar los método: __fields__, __limitQ__, __searchF__ y __searchQ__. De este modo cuando se crea alguno de estos métodos en un GenList se usará el método de CodenerixModel o GenList según existan. De hecho su funcionamiento es exactamente igual que en CodenerixModel.

En las siguientes 3 tablas se muestran 3 columnas:

• La primera indica si el método está definido en CodenerixModel.
• La segunda indica si está definido en GenList.
• La tercera columna se indica cual es el resultado de aplicar dichos filtros.

Por lo tanto ahora podemos decidir que nuestra vista se comporte de forma diferente a nuestro modelo. Esto se hace porque algunas veces queremos crear más de un listado del mismo modelo donde cada listado tiene propiedades diferentes, muestra información diferente dependiendo del usuario o bien usa un template distinto.

GenList además puede contener diferentes atributos que permiten configurar el funcionamiento de este de muchas maneras diferentes. Aquí dispones de una tabla de lo que existe a día de hoy:

annotations = {
    'min_price': Min('books__price'),
    'max_price': Max('books__price')
}


def annotations(self, info):
    anot = []
    if info.user.is_superuser:
        anot['min_price'] = Min('books__price')
        anot['max_price'] = Max('books_price')
    return anot

{
    "filter": ...,
    "meta": {
            ...
            "context": {
                "var1": "value1",
            },
            ...
        },
    "table": ...,
}

extra_context = {
    "variable1": "This is a CODENERIX variable that will be ready to use in the Template's Context",
    "variable2": { "a": 1, "b": 2},
    "variable3": 3.4,
}

Además de estos atributos debemos conocer cómo GenList intenta localizar los templates para el renderizado de la página. GenList va a intentar construir una serie de URLs basándose en el perfil del usuario y su idioma, de tal modo que si el usuario es superadmin este tendrá un perfil “admin” y en caso contrario no tendrá perfil alguno. El idioma del usuario es detectado por CODENERIX y será entregado igualmente a la función de detección de templates.

Las posibles rutas para los templates serán (siguiendo este orden de prioridad):

1. <ruta>/<fichero>.admin.<idioma>.html
2. <ruta>/<fichero>.admin.html
3. <ruta>/<fichero>.<usuario>.<idioma>.html
4. <ruta>/<fichero>.<usuario>.html
5. <ruta>/<fichero>.<idioma>.html
6. <ruta>/<fichero>.html

De este modo si el usuario es “luis“, sí es superuser y su idioma en el momento de la consulta es el Español con código “es“, y la ruta al fichero es “base/home“, el sistema probará la existencia de los siguientes ficheros:

1. base/home.admin.es.html
2. base/home.admin.html
3. base/home.luis.es.html
4. base/home.luis.html
5. base/home.es.html
6. base/home.html

GenList también soporte la detección automática de ficheros estáticos para la carga de parciales y ficheros de AngularJS como lo son el fichero de aplicación, los controladores o los filtros. Para ello GenList intentará localizar estos ficheros en la carpeta de la aplicación dentro de “/static” (o cual sea la ruta de ficheros estáticos en disco según la constante STATIC_ROOT de settings de Django). Para esta detección usará el mismo algoritmo que usa la detección de templates. De este modo probará para cada fichero estático la posible existencia de este en disco y cargará estos en vez de los que existen por defecto en CODENERIX. Para la generar las rutas el sistema usará:

1. La ruta: será la ruta de los ficheros estáticos, más el nombre de la APP donde se encuentre el modelo, más el nombre del modelo terminado en “s”.
2. Tipo de fichero: podrá ser:
   1. <ninguno>: para el parcial que declara los filtros que se mostrarán por encima de la tabla del listado y generalmente para incluir la tabla con nginclude.
   2. rows: para el parcial de las filas
   3. header: para el parcial de la cabecera de la tabla (por debajo de la declaración de las columnas y por encima de las filas).
   4. summary: para el parcial del pie de la tabla (por debajo de las filas y por encima de las etiquetas de cierre de la tabla).
   5. app: para los ficheros de la aplicación.
   6. controllers: para los controladores.
   7. filters: para los ficheros de filtros de AngularJS.
3. La extensión: será la de cada tipo de fichero:
   1. html: para los parciales
   2. js: para el resto
4. El resultado final será el de concatenar:
   1. La ruta
   2. “_” más tipo de fichero
   3. La extensión.
5. Para una app llamada “base“, con un modelo llamado “Contact“, para obtener el parcial de filas, de un usuario “luis“, que sí es superuser y visita el sitio en español, el sistema intentaría las siguientes rutas:
   1. static/base/contacts_rows.admin.es.html
   2. static/base/contacts_rows.admin.html
   3. static/base/contacts_rows.luis.es.html
   4. static/base/contacts_rows.luis.html
   5. static/base/contacts_rows.es.html
   6. static/base/contacts_rows.html
   7. static/codenerix/partials/rows.html (si las anteriores fallan)

Por último debemos hablar largo y tendido sobre el método json_builder() dado que es un método de GenList que permite controlar el resultado que se va a ofrecer al usuario. El método se define con 2 parámetros:

• answer: contiene la respuesta pre-calculada por GenList a la que solo le falta el “body” que deberá situarse en answer[“table”][“body”].
• context: contiene el contexto que estaría disponible para el render el generador del JSON en este caso. Dentro del contexto está el “object_list” que contiene el QuerySet resultado de la aplicación de los filtros y de lo que teóricamente GenList debería responder.

Existen varias técnicas para trabajar con json_builder():

Técnica 1: “Body building on your own” en la que tú mismo construyes el cuerpo completo de la respuesta:

def json_builder(self,answer,context):

    # El body es un listado de registros (body o cuerpo del listado)
    body=[]

    # Procesamos cada elemento del object_list del contexto a fin de procesar todas las filas
    for o in context['object_list']:
        t={}
        t['name']=o.name
        t['surname']=o.surname
        phones=[]
        for o2 in o.phone.all():
            phone={}
            phone['country']=o2.country
            phone['prefix']=o2.prefix
            phone['number']=o2.number
            phones.append(t2)
        t['phone']=phones
        t['address']=o.address
        body.append(t)

    # Introduce el body en el cuerpo de la respuesta
    answer['table']['body']=body

    # Devuelve la respuesta ya lista
    return answer

En este ejemplo construimos una lista de forma manual donde nosotros somos responsables de rellenar cada fila o registro del body. Al terminar de procesar las filas que queremos enviar al navegador del usuario, cargamos estas filas (listado) en la respuesta y devolvemos esta.

Técnica 2: “Body building with bodybuilder()” en la que usas el método bodybuilder() para ayudarte a construir el cuerpo de la respuesta:

def json_builder(self,answer,context):

    # Rellenamos directamente usando bodybuilder
    answer['table']['body']=self.bodybuilder(context['object_list'],{
        'id:user__register__id':None,
        'name':None,
        'surname':None,
        'phone': {
            'country':None,
            'prefix':None,
            'number':None,
            },
        'address':None,
        })

    # Answer the new context
    return answer

Cuando se usa bodybuilder() este espera recibir el listado de objetos a procesar y la forma de los registros que debe construir este. Lo que hace bodybuilder() es que por cada registro del object_list genera un entrada en el body, donde cada una de esas entradas son diccionarios que tienen la forma del segundo parámetro de la llamada, de este modo cada registro de este ejemplo tendría 5 claves en el diccionario:

• id: sería el resultado de extraer del objeto el campo “user” y de este el campo “register” y de este el campo “id“. Si no se especificara como un alias “id:…”, la key contendría la ruta completa que sería “user__register__id“.
• name: resultado de extraer del objeto el campo name o bien el resultado de llamar al método name().
• surname: resultado de extraer del objeto el campo surname o bien el resultado de llamar al método surname().
• phone: será un diccionario con 3 claves:
  • contry: resultado de extraer del objeto el campo phone, y de este el campo country o bien el resultado de llamar al método country().
  • prefix: resultado de extraer del objeto el campo phone, y de este el campo prefix o bien el resultado de llamar al método prefix().
  • number: resultado de extraer del objeto el campo phone, y de este el campo number o bien el resultado de llamar al método number().
• address: resultado de extraer del objeto el campo address o bien el resultado de llamar al método address().

Técnica 3: “Body building with autorules() and bodybuilder()” en la que usas autorules() y bodybuilder() para construir la respuesta:

def json_builder(self,answer,context):

    # Solicita las reglas a autorules
    rules=self.autorules()
    # Saca una de las claves del autorules (campo que no queremos en la respuesta)
    rules.pop('id')
    # Añade otra clave (campo que deseamos en la respuesta, en este caso un alias de user->id)
    rules['id:user__id']=None
    # Llama a bodybuider el nuevo conjunto de reglas
    answer['table']['body']=self.bodybuilder(context['object_list'],rules)

    # Devuelve el resultado
    return answer

En este caso lo que hacemos es pedir a GenList el conjunto de reglas que deberíamos usar, adaptamos ese conjunto de reglas a nuestro antojo y lo entregamos a bodybuilder() para que termine el trabajo de generar el cuerpo de la respuesta.

Notas sobre el optimizador de consultas

Debemos tener en cuenta que GenList incluye un optimizador de consultas para reducir del trabajo que se hace en Python y pasar parte de este al gestor de base de datos. Este optimizador no funciona cuando intervienen en el resultado datos que la base de datos no puede computar por si sola, esto es generalmente, cuando se incluyen métodos en los resultados y no son datos puramente almacenados en los objetos.

Otro detalle importante es que el optimizador convierte las filas del resultado en objetos de un diccionario, de tal modo que solo contiene los datos tal cual y no instancia los objetos del modelo como sería normal en Django.

Custom QuerySet o QuerySet personalizado

Finalmente cuando no podemos trabajar con los filtros o al introducir ciertas limitaciones (annotates por ejemplo) el resultado ya no funciona como deseamos….siempre nos quedará un “AS en la manga“, el método “custom_queryset(queryset, info)“. Este método debes reescribirlo en tu vista a fin de que CODENERIX lo use, dado que de otro modo operará normalmente. Este método recibe dos parámetros: el primero es el QuerySet calculado por GenList, el segundo es el objeto MODELINF que contiene información interna de la consulta, del modelo, argumentos, etc… y espera que devuelvas un QuerySet válido. Es por ello que puedes devolver el QuerySet que has recibido con algunos parámetros más aprovechando la potencia del ORM de Django o incluso podría ser un QuerySet de un modelo diferente.

Puedes leer más sobre las vistas genéricas de CODENERIX en “Como usar Codenerix GenCreate, GenUpdate, GenDetail y GenDelete“.