Trabajando con filtros en Symfony (I)
Juan Pablo Romero
Software EngineerEsta es una entrada bastante rápida, pero que busca mostrar la forma básica en que se pueden usar los formularios de filtros en Symfony (versión 1.2) para facilitar a los usuarios la clasificación y consulta de información. El manejo de formularios de filtros es muy similar a los formularios que se usan para el ingreso y/o edición de información, con algunas variaciones. Hago claridad que las pruebas que he realizado han sido usando Propel como ORM.
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:
$ 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:
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í:
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:
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)
<form action="<?php echo url_for('clientes/filtrar'); ?>" method="post">
<table><tbody></tbody></table>
<input name="filtrar" type="submit" value="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:
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.
Written by Juan Pablo Romero
Juan Pablo designs and builds robust software solutions with a focus on performance and usability. His problem-solving skills and attention to detail ensure high-quality and efficient applications.