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

<?php
//Archivo ubicado en: SYMFONY_ROOT/apps/mi_aplicacion/lib/myUser.class.php
 
class myUser extends sfGuardSecurityUser
{
    public function signOut()
    {
        $this->dispatcher->notify(new sfEvent(
                $this,
                'user.logout',
                array('user_id' => $this->getGuardUser()->id)
        ));
 
        parent::signOut();
    }
}

Con esto estamos notificando al objeto sfEventDispatcher la ocurrencia del evento user.logout desde la clase myUser (primer parámetro del constructor de sfEvent) y estamos pasando como información el identificador del usuario. Posteriormente, debemos asociar un listener a ese evento, el cual lo podemos definir en la clase que configura nuestra aplicación:

1
2
3
4
5
6
7
8
9

<?php
// Archivo ubicado en: SYMFONY_ROOT/apps/mi_aplicacion/config/mi_aplicacionConfiguration.class.php
class mi_aplicacionConfiguration extends sfApplicationConfiguration
{
  public function configure()
  {
      $this->dispatcher->connect('user.logout', array('Eventos','test'));
  }
}

Con esto cada vez que un usuario cierre sesión, se ejecutará el método test de la clase Eventos, el cual deberá recibir como parámetro un objeto de la clase sfEvent. La misma implementación aplicará para el método signIn, para el caso en que el usuario inicie sesión. Espero sea de utilidad.

• Necesitamos enviar un correo electrónico al usuario cuando se registra
• Es necesario registrar las acciones que ejecutan los usuarios (creación y actualización de información)
• Cada vez que un usuario sube un archivo o califica algún contenido (imagen, artículo, etc.) se debe registrar la calificación junto con la hora y el usuario.

y se pueden seguir listando muchas otras situaciones (dependiendo del tipo de aplicación). Una de las más usuales y cuya implementación es poco recomendable (desde mi punto vista) es cuando queremos registrar qué usuario creó y/o actualizó determinado registro en nuestra base de datos y el procedimiento a seguir es la sobrecarga del método save() de las clases (generadas por Doctrine o Propel) que componen nuestro modelo, agregando código que no corresponde con la responsabilidad de la clase. Otra posible implementación es agregar código en las acciones (actions.class.php) que se encargue de hacer el registro de los datos mencionados, haciendo más extensos los métodos y más complicados de leer.

Bien, para tratar de una mejor manera estos eventos existe un componente llamado Event Dispatcher (el cual viene integrado en Symfony desde su versión 1.1) y que hace parte de una serie de componentes que proveen los desarrolladores de Symfony. Este componente es una implementación ligera del patrón Observador y que permite de forma muy flexible definir y notificar eventos en nuestra aplicación.

El objeto Dispatcher y los eventos

El Event Dispatcher se compone de dos objetos fundamentales: Dispatcher (clase sfEventDispatcher) y eventos (clase sfEvent). El Objeto Dispatcher es el objeto central encargado de recibir todas las notificaciones y registros de los eventos y disparar los listeners asociados a dichos eventos.   Los eventos (instancias de la clase sfEvent) se describen a través de una cadena (por ejemplo: usuario.login), no es necesario implementar interfaces o crear nuevas clases que hereden de sfEvent para crear un evento.  Es importante saber que el constructor de un objeto sfEvent toma tres argumentos:

• El subject (quien notifica el evento)
• El nombre del evento
• Un arreglo de parámetros (que se pasarán al listener y puede ser nulo)

Bien,  una vez creado nuestro evento es necesario hacerle saber al objeto Dispatcher la existencia del mismo a través del método connect  y posteriormente notificar su ocurrencia. Ahora veamos esto en la práctica.

Implementando el evento

Tomaremos como referencia que tenemos un proyecto con el plugin de sfGuard para el control básico de usuarios y que queremos registrar en una tabla de auditoria cada vez que un usuario crea un producto. A continuación la descripción del esquema de las tablas de producto, tipo de producto y auditoria:

Producto:
  tableName: Producto
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: true
    nombre:
      type: string(255)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    tipoproducto_id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
  relations:
    TipoProducto:
      local: tipoproducto_id
      foreign: id
      type: one

TipoProducto:
  connection: doctrine
  tableName: TipoProducto
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: true
      autoincrement: true
    nombre:
      type: string(255)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
  relations:
    Producto:
      local: id
      foreign: tipoproducto_id
      type: many

Auditoria:
  connection: doctrine
  tableName: auditoria
  actAs: [Timestampable]
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: true
      primary: true
      autoincrement: true
    registro_id:
      type: integer(4)
      fixed: false
      unsigned: true
      primary: false
      notnull: true
      autoincrement: false
    entidad:
      type: string
    sf_guard_user_id:
      type: integer(4)
      fixed: false
      unsigned: false
      primary: false
      notnull: false
      autoincrement: false
  relations:
    SfGuardUser:
      local: sf_guard_user_id
      foreign: id
      type: one

Con este modelo en mente, vamos a generar los módulos para el crud de productos y tipos de productos, a través de la tarea:

php symfony doctrine:generate-module frontend productos Producto
php symfony doctrine:generate-module frontend tiposproducto TipoProducto

Ahora, vamos a crear el evento y a notificarlo al objeto Dispatcher, modificando el método que guarda el producto (método processForm) de la clase productoActions como sigue:

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

protected function processForm(sfWebRequest $request, sfForm $form)
{
    $form->bind($request->getParameter($form->getName()));
    if ($form->isValid()) {
      try
      {
          $producto = $form->save();
         // Se crea el evento y se registra en el dispatcher
          $this->dispatcher->notify(new sfEvent($this, 'producto.create',
                  array('entidad' => 'Producto', 'id' => $producto->getId())));
	      $this->getUser()->setFlash('save_ok',
                  'Registro creado/editado correctamente');
      } catch (Doctrine_Exception $pe) {
	      $this->getUser()->setFlash('exception', 
                  'Ocurrió un error al momento de agregar/editar el registro');
      }
      $this->redirect('productos/index');
    }
  }
}

Bien, la línea 9 es la importante:

 $this->dispatcher->notify(new sfEvent($this, 'producto.create',
                  array('entidad' => 'Producto', 'id' => $producto->getId())));

Cuando se crea el objeto sfEvent se le están pasando tres argumentos:

• Subject: en nuestro caso quien notifica el evento es la clase productoActions, por eso usamos $this
• Nombre del evento: hemos llamado al evento: producto.create
• Arrreglo de argumentos: pasaremos como argumentos al listener la entidad que estamos creando (entidad) y el id.

Una vez creado el evento, accedemos la instancia del objeto dispatcher y usamos el método notify (para otras formas de notificación se pueden usar los métodos notifyUntil y filter, ver más en la documentación del componente), para notificar que un producto ha sido creado.

Ahora, es necesario que asociemos un listener a ese evento (pues hasta el momento la notificación no sirve de nada). Para esto usamos el método connect del Dispatcher. Vamos a agregar esta llamada dentro de la clase que configura nuestra aplicación (en este caso en el archivo frontendConfiguration.class.php):

class frontendConfiguration extends sfApplicationConfiguration
{
  public function configure()
  {
      $this->dispatcher->connect('producto.create', array('Auditoria','registrarCreacion'));
  }
}

El método connect recibe el nombre del evento y una función o método de una clase que será llamado cuando el evento sea notificado. En este caso, estamos pasando un arreglo como segundo argumento indicando que se llamará el método registrarCreacion de la clase Auditoria, aunque también es posible pasar solamente el nombre de una función (debemos asegurarnos que el archivo donde se encuentre la definción de esta función haya sido cargado). Si utilizamos el método de una clase, este debe estar declarado como estático. Ahora bien, revisemos el código del método registrarCreacion:

class Auditoria extends BaseAuditoria
{
    public static function registrarCreacion(sfEvent $event){
        $usuario = $event->getSubject()->getUser()->getGuardUser();
        $a = new Auditoria();
        $a->setRegistroId($event['id']);
        $a->setEntidad($event['entidad']);
        $a->setSfGuardUserId($usuario);
        $a->save();
    }
}

Una vez se notifica el evento y se llama al método registrarCreacion a este se le pasa como primer argumento el objeto sfEvent correspondiente, desde el cual podemos acceder el arreglo de argumentos que se pasaron al momento de notificar el evento (en el método processForm), como se ve en:

$a->setRegistroId($event['id']);
$a->setEntidad($event['entidad']);

Listo, con este método creado, cada vez que un producto sea creado, se registrará en la tabla auditoria el usuario quien lo creó junto con la fecha y la hora. Esto mismo puede aplicarse para envio de correo (usando SwitfMailer), envio de mensajes al usuario o a otras clases, todo dependiendo el gusto del desarrollador. Espero que sea de utilidad y como siempre, los comentarios serán bien recibidos.

Of course, this functionality is offered for the php command line interface (the php-cli), that sometimes is not enough to execute some actions such as: watch the object state, perform database inserts (and the typical crud operations), call methods in a interactive way, etc,. I know that some people says: the php cli has a interactive mode (-a option), but i think it is very limited. Talking with others developers, the php interpreter needs an interactive terminal (like python) and it keeps to work with our symfony projects.

The good new is that the facebook team has released (under BSD license) an interactive shell for php interpreter (as their own creators says: ” … ironically written in python”) called phpsh and it’s a great work !. I’ve perform some tests to integrate it with Symfony and i think, it can be a great tool for support and debugging.

Some simple examples:

After we installed phpsh (see the README file), we can work with php sentences and use the common functions:

test$ phpsh
Starting php
type 'h' or 'help' to see instructions & features
php> echo "Hello world"
Hello world
php> $a = 2+3; echo $a
5
php> $f = array('one' => 1, 'two' => 2, 'three' => 3);
php> foreach ($f as $n) { echo $n; }
123
php> foreach ($f as $n) { echo $n."\n"; }
1
2
3
php> foreach ($f as $n) {
... echo $n."\n";
... }
1
2
3
php> echo count($f);
3

Well, but right now, i’ll show you something more interesting: a symfony application using the interactive shell. It not requires additional configuration, just load a file: the frontal controller of your app (in the web directory), for example:

test$ phpsh web/index.php
Starting php with extra includes: ['web/index.php']
 .......................
php>

To hide the html output, we can create a copy of this file and avoid the call to dispatch method:

require_once(dirname(__FILE__).'/config/ProjectConfiguration.class.php');
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend','prod', false);
sfContext::createInstance($configuration);

Now, load again (i’ve called shell.php):

test$ phpsh shell.php
Starting php with extra includes: ['shell.php']
type 'h' or 'help' to see instructions & features
php> $c = CityPeer::doSelect(new Criteria);
php> foreach ($c as $city) {
 ... echo $city."\n";
 ... }
Barranquilla
Bogota
Berlin
Medellin
php>

As you can see, it can be access to the model classes (i’m sorry with doctrine users) and the Symfony classes. For example, if my file app.yml looks like:

all:
 results_per_page: 15
 sf_phpmailer:
   mailer:                    true
   smtp_auth:                 true
   smtp_secure:               "ssl"
   host:                      "smtp.example.com"
   port:                      600
   username:                  "user"
   password:                  "password"
   from:                      "nobody@example.com"
   from_name:                 "NoBody"

test$ phpsh shell.php
Starting php with extra includes: ['shell.php']
type 'h' or 'help' to see instructions & features
php> $conf = sfConfig::get('app_sf_phpmailer_port');php> echo $conf;
600
php> echo sfConfig::get('app_results_per_page');
15
php>

Well, it’s easy and very interesting. I hope work in detail and make more experiments. That’s all folks !.

Desde luego, todo esto es gracias a la interfaz en línea de comandos del ínterprete php (más conocido como php-cli), que en algunos casos se queda corto para ejecutar algunas pruebas: ver el estado de un objeto, insertar datos en la base de datos,  probar métodos de manera interactiva, etc,. Sé que algunos dirán que php-cli tiene un modo interactivo, pero en realidad desde mi punto de vista es muy limitado.  Sería muy interesante contar con algo similar a la terminal interactiva de python y desde luego que se pueda trabajar con nuestros proyectos en Symfony.

Lo mejor de todo, es que la gente de facebook liberó bajo licencia BSD una shell interactiva para php y como sus mismos credadores dicen: “… irónicamente escrita en python ….”; se llama phpsh y realmente es un gran trabajo. He realizado algunas pruebas de integración con Symfony y creo que puede ser de gran apoyo para pruebas y aún más para las personas que están aprendiendo a trabajar con el framework.

A continuación van algunos de los sencillos experimentos realizados:

Una vez se haya instalado phpsh (leer el README), podemos trabajar  con sentencias de php y usar las funciones:

test$ phpsh
Starting php
type 'h' or 'help' to see instructions & features
php> echo "Hola mundo"
Hola mundo
php> $a = 2+3; echo $a
5

php> $f = array('uno' => 1, 'dos' => 2, 'tres' => 3);
php> foreach ($f as $n) { echo $n; }
123
php> foreach ($f as $n) { echo $n."\n"; }
1
2
3

php> foreach ($f as $n) {
... echo $n."\n";
... }
1
2
3
php> echo count($f);
3

Bien, pero ahora viene algo un poco más interesante: usar a través del shell interactivo nuestra aplicación hecha en Symfony.

No requiere ninguna configuración especial, simplemente cargar un archivo y listo; se trata del controlador frontal de nuestra aplicación (alguno de los que se encuentra en web), así:

test$ phpsh web/index.php
Starting php with extra includes: ['web/index.php']
 
  .......................
 
php>

Para obviar la salida html, podemos crear una copia de ese archivo y evitar la llamada al método dispatch(), así:

require_once(dirname(__FILE__).'/config/ProjectConfiguration.class.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend','prod', false);
sfContext::createInstance($configuration);

Ahora, de nuevo lo cargamos (ese archivo lo he llamado shell.php):

test$ phpsh shell.php
Starting php with extra includes: ['shell.php']
type 'h' or 'help' to see instructions & features
php> $c = CiudadPeer::doSelect(new Criteria);
 
php> foreach ($c as $ciudad) {
 ... echo $ciudad."\n";
 ... }
Barranquilla
Bogota
Constantinopla
Medellin
 
php>

Como se puede ver, puedo acceder a las clases de mi modelo (disculpas a los usuarios de Doctrine) y desde luego a las clases que nos proporciona Symfony, por ejemplo si mi archivo apps/frontend/config/app.yml es:

all:
 resultados_por_pagina: 15
 sf_phpmailer:
   mailer:                    true
   smtp_auth:                 true
   smtp_secure:               "ssl"
   host:                      "smtp.mihost"
   port:                      600
   username:                  "miusuario"
   password:                  "miclave"
   from:                      "nosesabe@example.com"
   from_name:                 "Anonimo"

test$ phpsh shell.php
Starting php with extra includes: ['shell.php']
type 'h' or 'help' to see instructions & features
php> $conf = sfConfig::get('app_sf_phpmailer_port');
 
php> echo $conf;
600
php> echo sfConfig::get('app_resultados_por_pagina');
15
php>

Bueno, esos han sido los experimentos que he alcanzado a realizar. Espero trabajar más en detalle y publicar los resultados. Hasta una próxima.

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:

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:

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):

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:

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:

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

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

// 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:

// 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:

$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):

'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:

$ 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="&lt;?php echo url_for('clientes/filtrar'); ?&gt;" 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.