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:

1. Obtiene el numero de versión por el comando ’svn info’
2. Reduce las llamadas al comando ubicando la información en cache durante un día
3. Es totalmente desacoplado del proyecto y se puede reutilizar fácilmente
4. Se puede adaptar para otros sistemas de control de versiones

Que les parece?

Antes de comenzar,  aclaro que mucha de la información aquí consignada está basada en el código generado por el generador de administración tanto de Propel como de Doctrine y desde luego en la documentación del API de Symfony 1.2.

Filtros con Doctrine

En la entrada anterior hablé del uso de los formularios con Propel de manera básica y aunque las forma de trabajar los formularios de filtros con Doctrine no es muy diferente, haré algunas aclaraciones importantes.

Al momento de generar el modelo con Doctrine, con la tarea:

1

php symfony doctrine:build-all

al igual con con Propel, se genera en el directorio  lib/filter/doctrine/ el conjunto de clases de formularios de filtro. Tomando como referencia el esquema de datos del tutorial de Jobeet (Día 3 – http://www.symfony-project.org/jobeet/1_2/Doctrine/en/03) los filtros generados son:

1
2
3
4
5
6

BaseFormFilterDoctrine.class.php
JobeetAffiliateFormFilter.class.php
JobeetCategoryAffiliateFormFilter.class.php
JobeetCategoryFormFilter.class.php
JobeetJobFormFilter.class.php
base/

Estas clases podemos modificarlas según nuestras necesidades, al igual que con los formularios. Ahora, vamos a generar el módulo que permita el CRUD de las ofertas de trabajo (Tabla Jobeet_Job):

1

php symfony doctrine:generate-module frontend job JobeetJob

Bien, ahora con el módulo generado, vamos a revisar  las acciones y hacer los ajustes para el uso de los filtros. En primera forma, debemos modificar la acción index, para que nos presente el formulario de filtros:

1
2
3
4
5
6
7
8
9
10
11
12

class jobActions extends sfActions
// apps/frontend/modules/job/actions/actions.class.php
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->jobeet_job_list = Doctrine::getTable('JobeetJob')
    $this->createQuery('a')
    $this->execute();
    $this->filtro = new JobeetJobFormFilter();
  }
 
// más código .....

Al igual que con Propel, debemos crear una instancia del filtro, para que sea visualizada en la plantilla:

1
2
3
4
5
6
7
8
9
10
11
12
13

// apps/frontend/modules/job/templates/indexSuccess.php
 
<h1>Lista de trabajos</h1>
<h1>Lista de trabajos</h1>
<form action="<?php echo url_for('job/filter'); ?>" method="post">
<?php echo $filtro ?>
 <p>
  <input class="ui-state-default ui-corner-all" type="submit" value="Filtrar" />
  <?php echo link_to('Quitar filtro', url_for('job/filter'),
     array('query_string' => '_reset', 'method' => 'post')); ?>
 </p>
</form>
<! -- más código html ... -->

Creamos nuestra acción encargada de filtrar los resultados (filter):

1
2
3
4
5
6
7
8
9

// apps/frontend/modules/job/actions/actions.class.php
 
public function executeFilter(sfWebRequest $request)
{
  $this->filtro = new JobeetJobFormFilter();
  $this->consulta = $this->filtro->buildQuery($request->getParameter('jobeet_job_filters'));
  $this->jobeet_job_list = $this->consulta->execute();
  $this->setTemplate('index');
}

Una de las diferencias importantes con Propel, es el método que se encarga de construir la consulta según el valor de los filtros,  que es buildQuery y que recibe una arreglo de valores a partir de los cuales se construirá la consulta. Este método devuelve un objeto de tipo Doctrine_Query, por eso llamamos al método execute en forma posterior.

Con lo anterior tenemos un sistema de filtros muy básico usando Doctrine como ORM.

Adaptando el filtro

Hasta el momento, ya hemos visto como establecer un filtro, tanto si usamos Propel como Doctrine. Sin embargo, la mayoría de las veces los campos por los cuales deseamos filtrar información no corresponden con todos los de la tabla. El filtro por defecto que se genera contempla todos los campos y por ello es necesario que hagamos algunas modificaciones, para filtrar por los campos deseados.

Siguiendo con el ejemplo del tutorial de Jobeet, supongamos que sólo queremos filtrar la lista de trabajos, por categoría  y tipo (campos category y type, respectivamente), para ello debemos modificar el método configure de la clase JobeetJobFormFilter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// lib/form/doctrine/JobeetJobFormFilter.class.php
 
class JobeetJobFormFilter extends BaseJobeetJobFormFilter
{
  public function configure()
  {
   $this->setWidgets(array(
    'category_id'  => new sfWidgetFormDoctrineChoice(array('model' => 'JobeetCategory', 'add_empty' => true)),
    'type'         => new sfWidgetFormFilterInput()
   ));
 
    $this->setValidators(array(
    'category_id'  => new sfValidatorDoctrineChoice(array('required' => false, 'model' => 'JobeetCategory', 'column' => 'id')),
    'type'         => new sfValidatorPass(array('required' => false))
   ));
   $this->widgetSchema->setNameFormat('jobeet_job_filters[%s]');
 }
}

Cómo se puede observar, un formulario de filtro es muy similar a un formulario, con algunas diferencias en cuanto a los widgets que se usan y algunos de los métodos.  Con esta modificación, cuando imprimamos el filtro en la plantilla, ahora sólo los campos de categoría y tipo estarán disponibles.  También podemos usar los métodos setLabel y setLabels para cambiar el nombre de las etiquetas que aparecerán al momento de imprimir el formulario de filtros, por ejemplo:

1
2
3
4

$this->getWidgetSchema()->setLabels(array(
   'category_id' => 'Categoria',
   'type' => 'Tipo'
));

Uno de los widgets de filtros que considero más útiles es sfWidgetFormFilterDate, ya que con él es posible filtrar información por rangos de fecha, aquí un ejemplo de su uso para el campo de expiración de la oferta de trabajo (campo expires_at):

1
2
3
4
5
6

'expires_at'   => new sfWidgetFormFilterDate(array(
                 'from_date' => new sfWidgetFormDate(),
                 'to_date' => new sfWidgetFormDate(),
                 'with_empty' => 0,                   // Para que no salga el checkbox
                 'template' => 'desde %from_date% hasta %to_date%'
                ))

Bien, hasta aquí esta segunda entrega del trabajo con filtros en Symfony 1.2. Espero que sea  de utilidad.

Bien, empecemos por saber que en Symfony existe una tarea que nos permite construir en forma automática los formularios de filtros, de la siguiente forma:

1

$ php symfony propel:build-filters

Después de la ejecución de esta tarea, en el directorio lib/filters de nuestro proyecto, se habrán creado (de acuerdo a nuestro modelo) un conjunto de clases cuyo nombre sigue la siguiente nomenclatura:

1

ClaseFormFilter.class.php

y al igual que con el modelo y los formularios, tendremos unas clases Base y unas clases que extenderán de esas clases base, las cuales podemos adaptar según nuestras necesidades. Una vez creadas nuestras clases de formularios de filtros, ya podemos usarlas dentro de nuestras acciones. Tomaré como ejemplo, que tenemos un modulo llamado clientes que permite trabajar con el CRUD normal y que cada cliente tiene un nombre, telefono y una ciudad, de modo que nuestra clase base de formulario de filtro lucirá así:

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

class BaseClienteFormFilter extends BaseFormFilterPropel
{
  public function setup()
 
  {
     $this->setWidgets(array(
      'nombre'    => new sfWidgetFormFilterInput(),
      'telefono'  => new sfWidgetFormFilterInput(),
      'ciudad_id' => new sfWidgetFormPropelChoice(array(
            'model' => 'Ciudad', 'add_empty' => true))
       ));
 
   $this->setValidators(array(
    'nombre'    => new sfValidatorPass(array('required' => false)),
    'telefono'  => new sfValidatorPass(array('required' => false)),
    'ciudad_id' => new sfValidatorPropelChoice(array('required' => false,
                                 'model' => 'Ciudad', 'column' => 'id')),
   ));
 
   $this->widgetSchema->setNameFormat('cliente_filters[%s]');
   $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);
   parent::setup();
  }
 
  public function getModelName()
  {
    return 'Cliente';
  }
 
  public function getFields()
  {
    return array(
     'id'        => 'Number',
     'nombre'    => 'Text',
     'telefono'  => 'Text',
     'ciudad_id' => 'ForeignKey',
   );
  }
}

Tengamos en cuenta que esta clase es generada automáticamente y podemos hacer las modificaciones necesarias en la clase ClienteFormFilter, como se hace con los formularios.  Ahora bien, vamos a utilizar este formulario de filtro en nuestra acción index de nuestro módulo de clientes, de la siguiente forma:

1
2
3
4
5
6
7
8
9
10
11
12

class clientesActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
     // creamos el filtro ....
     $this->filtro = new ClienteFormFilter();
     // .....
     // más código ....
     // Típica consulta  ....
     $this->clientes = CientePeer::doSelect(new Criteria());
  }
}

En nuestra plantilla: (indexSuccess.php)

1
2
3
4
5
6
7
8
9

<form action="<?php echo url_for('clientes/filtrar'); ?>" method="post">
<table>
 <tbody>
  <?php echo $filtro; ?>
 </tbody>
</table>
<input type="submit" value="Filtrar" name="filtrar"/>
</form>
// otro codigo html ....

Bien, hasta aquí nada nuevo, simplemente un formulario más, que aparecerá en nuestra acción index de nuestro módulo de clientes, pero con la diferencia que será procesado por la acción filtrar (o como decida llamarse). En este punto es importante mencionar, que para la ejecución del filtrado, se empleará el método buildCriteria, el cuál recibe como parámetro un arreglo (los campos por  los  cuales se desea hacer el filtro) y se encarga de construir las consultas:

1
2
3
4
5
6
7
8

public function executeFiltrar(sfWebRequest $request)
{
  $this->filtro = new ClienteFormFilter();
  // Construye un objeto criteria con el valor de los filtros
  $criteria = $this->filtro->buildCriteria($request->getParameter('cliente_filters'));
  $this->clientes = ClientePeer::doSelect($criteria);
  $this->setTemplate('index');
}

El método buildCriteria es el encargado de construir la consulta según el valor de los filtros (revise la clase sfFormFilterPropel y los métodos addXXXCriteria() de la misma clase). Posteriormente pasamos ese objeto criteria a el método doSelect para devolver la consulta filtrada usando la plantilla de la acción index.  Sencillo, no ??

En una próxima entrada se explicará lo referente al manejo de formularios de filtro y el mantenimiento de los resultados obtenidos por el filtro entre páginas.

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/

$ trac-admin /path/to/projenv permission add bob TRAC_ADMIN

Donde ‘/path/to/projenv’ es la ruta en donde esta Trac y ‘bob’ es el usuario al cual agregar el permiso.