AxiaCore Blog

Esta es una segunda entrega acerca del trabajo con los formularios de filtro en Symfony. He tenido en cuenta los comentarios y sugerencias de los visitantes del blog, así que esta entrega integrará el uso de Doctrine.

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:

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:

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="<?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):

// 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'   =&gt; new sfWidgetFormFilterDate(array(
                 'from_date' =&gt; new sfWidgetFormDate(),
                 'to_date' =&gt; new sfWidgetFormDate(),
                 'with_empty' =&gt; 0,                   // Para que no salga el checkbox
                 'template' =&gt; '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.

Etiquetas: Desarrollo, Doctrine, Symfony | 15 Comentarios »

Trabajando con filtros en Symfony (I)

Septiembre 13, 2009 - 10:12 PM - Escrito por Juan Pablo Romero Bernal

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

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

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

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.

Etiquetas: Desarrollo, Symfony | 8 Comentarios »

Backups con rsync

Agosto 13, 2009 - 1:09 PM - Escrito por Camilo Nova

Para algunos de nuestros clientes tenemos planes de copias de seguridad de sus archivos mas importantes, luego de probar muchas herramientas, hemos descubierto que hay múltiples opciones y que cada una es valida para cada necesidad. Aquellos que requieren una configuración mas especializada pueden recurrir a utilizar varias herramientas y crear un sistema en el cual estas herramientas se concatenen y formen una completa solución de backups.

Entre las herramientas que utilizamos en AxiaCore contamos con rsync, una herramienta de software libe desarrollada para sistemas unix, a modo de introducción, hacer una backup es tan fácil como:

rsync -axSRzv usuario@192.168.0.1:/home /opt/backups/

Con dicho comando tendremos una copia incremental (solamente hace copia de los archivos que cambiaron desde el ultimo backup) del directorio /home en la maquina remota en la carpeta local /opt/backups.

En conjunto con otras herramientas, para nosotros, rsync es la mejor opcion.

Etiquetas: Backups, Seguridad, Software | Comente »

« Entradas Anteriores

Entradas Siguientes »

Implementamos tecnologia y es asi como lo hacemos

Desarrollador PHP 10-2009

Django Templates Scribes

Trabajando con filtros en Symfony (II)

Filtros con Doctrine

Adaptando el filtro

Trabajando con filtros en Symfony (I)

Backups con rsync

Publicidad

Etiquetas

Nosotros Leemos

Comentarios Recientes:

Enlaces Recientes:

Archivo

Admin