Los días 29 y 30 de octube se celebra en Barcelona la 3ª edición de la PHP Barcelona Conference. El año pasado no estuve muy atento de la fecha de celebración y finalmente, cuando me enteré, era demasiado tarde para organizar el viaje. Este año sin embargo me enteré con bastante tiempo de antelación y no me lo pensé..
Con todo reservado solo quedaba elegir las ponencias a las que asistir, ya que hay ponencias en tres salas diferentes y obviamente solo se puede asister a una por horario. La decisión no es fácil, hay una gran variedad de temáticas y ponentes de enorme nivel (Ilia Alshanetsky, Fabien Potencier, Stefan Priebsch, Lorenzo Alberton, Enrico Zimuel, etc.). Tras un difícil decisión, la lista elegida en principio, es la siguiente:
Viernes:
Sábado:
Aquí está el listado completo de ponencias y los horarios de éstas.
Tras la lectura de dos maravillosos libros acerca de métodologías ágiles de desarrollo:
Me dispongo a iniciarme en el mundo de TDD. Para los que no sepáis qué es TDD, se trata de una metodología de desarrollo basada en pruebas: "Test Driven Development" (Desarrollo guiado por pruebas).
Hace varios días que comencé a escribir pruebas unitarias y de integración en mis aplicaciones Symfony y una vez que me noto con soltura y empiezo a cogerle el ritmo (y el gustillo) he decidido que es un buen momento para iniciarme en TDD. Para ello he elegido un libro escrito por Carlos Ble: Diseño Ágil con TDD.
Aclarando conceptos iniciales:
Esto es todo por el momento. Prometo postear con lo que vaya aprendiendo sobre TDD.
Algunos enlaces de interés:
Inspirado por un buen post de Asier Marqués: Desarrolo ágil con symfony, doctrine y mysql workbench en el que nos habla de como usar Mysql workbench y un plugin que nos permite exportar nuestra base de datos a formato YAML, he decidido contar mi corta experiencia con Doctrine migrations.
Hace poco comencé a usar esta opción que nos brinda a todos el ORM Doctrine. Tras dos o tres task lanzados, ya me enteraba de como funciona, es más, empecé a cogerle el gusto...
La idea parte teniendo un schema.yml inicial, una BBDD en el servidor y la necesidad de incorporar cambios en ambos. El uso es mucho más extenso, pero me voy a centrar en los siguiente:
Teniendo el schema.yml
# config/doctrine/schema.yml
Category:
columns:
id:
type: integer(11)
notnull: true
autoincrement: true
primary: true
unsigned: true
name:
type: string(255)Y la BBDD en el servidor exactamente tal y como se declara en el schema.
Se necesita aplicar un cambio en la BBDD (añadir/eliminar columna, modificar una relación, etc.).
# config/doctrine/schema.yml
Category:
columns:
id:
type: integer(11)
notnull: true
autoincrement: true
primary: true
unsigned: true
name:
type: string(255)
Item:
columns:
id:
type: integer(11)
notnull: true
autoincrement: true
primary: true
unsigned: true
category_id:
type: integer(11)
notnull: true
unsigned: true
name:
type: string(255)
relations:
Category:
local: category_id
foreign: id
type: one
foreignAlias: ItemsCómo hacemos esto?
1. Modificar el schema.yml para aplicar el cambio.
2. Lanzar el task $ php symfony doctrine:generate-migrations-diff. Esto crea una estructura de ficheros en el directorio lib/ del proyecto:
// lib/migration/doctrine/1283537548_version1.php
class Version1 extends Doctrine_Migration_Base
{
public function up()
{
$this->createTable('item', array(
'id' =>
array(
'type' => 'integer',
'autoincrement' => '1',
'primary' => '1',
'unsigned' => '1',
'length' => '11',
),
'category_id' =>
array(
'type' => 'integer',
'notnull' => '1',
'unsigned' => '1',
'length' => '11',
),
'name' =>
array(
'type' => 'string',
'length' => '255',
),
), array(
'primary' =>
array(
0 => 'id',
),
));
}
public function down()
{
$this->dropTable('item');
}
}// lib/migration/doctrine/1283537549_version2.phpclass Version2 extends Doctrine_Migration_Base
{
public function up()
{
$this->createForeignKey('item', 'item_category_id_category_id', array(
'name' => 'item_category_id_category_id',
'local' => 'category_id',
'foreign' => 'id',
'foreignTable' => 'category',
));
$this->addIndex('item', 'item_category_id', array(
'fields' =>
array(
0 => 'category_id',
),
));
}
public function down()
{
$this->dropForeignKey('item', 'item_category_id_category_id');
$this->removeIndex('item', 'item_category_id', array(
'fields' =>
array(
0 => 'category_id',
),
));
}
}
3. Lanzar el task $ php symfony doctrine:migrate. Aplica en la BBDD los cambios que se crearon en el paso anterior. Se le pueden pasar parámetros (entorno, up / down, etc.)
4. Por último se reconstruyen las clases del modelo: $ php symfony doctrine:build --all-classes
5. No nos olvidemos de borrar la cache..
Con esto, ya tenemos los cambios que requerimos, aplicados tanto en nuestro proyecto Symfony como en nuestra BBDD. Fácil y rápido.
Enlaces:
Proyecto de prueba creado para el post
Necesitaba crear un módulo que transformase imágenes al vuelo según parámetros pasados por la URL y almacenara una cache de éstas (módulo PIC para imágenes).
Cuando me disponía a empezarlo, justo vi sfImageTransformExtraPlugin para Symfony. Que hace todo lo que necesitaba y más.
Después de instalarlo y pelearme inicialmente con el routing para conseguir llamar al módulo de forma correcta el resultado es espléndido: rápido, gestión máginifica de la cache, fácil de usar una vez conocido, fexible, etc.
Plugin sfImageTransformExtraPlugin.
Tutorial parte 1.
Tutorial parte 2.
Cuando tenemos un módulo creado a través del "Admin Generator" se crean varias acciones automáticamente como son: edit, new, delete, list... A veces, se necesitan crear acciones diferentes a éstas y que son más propias del modelo de la aplicación como por ejemplo: "mostrar en portada", "Artículo fuera de Stock".
Para ello normalmente existen dos vías diferentes: desde el generator.yml o sobreescribiendo el partial correspondiente a las acciones del form o list.
Este sería un ejemplo para una acción que pondrá un artículo en la portada de la web:
Desde el generator.yml:
generator:
class: sfDoctrineGenerator
param:
model_class: Articulos
theme: admin
non_verbose_templates: true
with_show: false
singular: ~
plural: ~
route_prefix: articulos
with_doctrine_route: true
actions_base_class: sfActions
config:
actions: ~
list: ~
filter: ~
form:
actions:
portada:
action: 'inHome'
label: 'En portada'
confirm: 'Este artículo pasará a la portada de la web. Continuar?'
_delete: ~
_list: ~
_save_: ~
edit: ~
new: ~
Sobreescribiendo _form_actions.php
<ul class="sf_admin_actions">
<?php if ($form->isNew()): ?>
<?php // Si es un objeto nuevo no se muestra el botón ?>
<?php // Aquí irían las acciones propias del Form: edit, save... ?>
<?php else: ?>
<?php if (!$articulos->getInHome()): ?>
<li class="sf_admin_action_portada">
<?php echo link_to(__('En portada', array(), 'messages'), 'articulos/inHome?id='.$articulos->getId(), array( 'conditional' => 'portada', 'conditional_value' => false,)) ?>
</li>
<?php endif; ?>
<?php // Aquí irían las acciones propias del Form: edit, save... ?>
<?php endif; ?>
</ul>
Esta última opción da más control al programador y se pueden tener en cuenta condicionales como por ejemplo que el artículo tenga el campo home=true, en cuyo caso ya no se necesita que aparezca el botón.
Pero las opciones no se acaban aquí, existe otro método de crear nuevas acciones un poco más complejas sin necesidad de sobreescribir el elemento Partial. Cómo? Haciendo uso del Helper propio del módulo creado por el Admin Generator (Articulos en este ejemplo). Este archivo se sitúa en el directorio lib del módulo: apps/backend/modules/##moduleName/lib/##moduleNameGeneratorHelper.class.php y extiende de Base##moduleNameGeneratorHelper que ha su vez extiende de la clase sfModelGeneratorHelper. Si miramos esta clase vemos que contiene los helpers linkToNew, linkToEdit, linkToList, linkToSave y linkToSaveAndAdd que se corresponden con las acciones base y que devuelven el tag li con una llamada al helper link_to configurado con los parámetros de la acción.
Si se mira el Partial de las acciones, primero se comprueba que exista el método ##actionName dentro del helper, si existe se muestra su valor, si no existe se crea la acción parametrizada según el fichero generator.yml
cache/backend/#env/modules/autoArticulos/templates/_form_actions.php
<?php
// ...
if (method_exists($helper, 'linkToPortada')): ?>
<?php echo $helper->linkToPortada($form->getObject(), array( 'action' => 'inHome', 'label' => 'En portada', 'confirm' => 'Este artículo pasará a la portada de la web. Continuar?', 'params' => array( 'conditional' => 'portada', 'conditional_value' => false, ), 'class_suffix' => 'portada',)) ?>
<?php else: ?>
<?php echo link_to(__('En portada', array(), 'messages'), 'articulos/inHome?id='.$articulos->getId(), array( 'conditional' => 'portada', 'conditional_value' => false,)) ?>
<?php endif;
// ...
?>Entonces, una forma de personalizar acciones es usando el generator.yml y el helper del módulo para pasárle parámetros, condicionales, etc. Siguiendo con el ejemplo:
generator.yml
generator:
class: sfDoctrineGenerator
param:
config:
form:
actions:
novedad:
action: 'inNew'
label: 'Novedad'
confirm: 'Este artículo será marcado como novedad. Continuar?'
params:
conditional: 'novedad'
conditional_value: falseEl parámetro 'novedad' se usará para saber qué propiedad del objeto hay que chequear y el parámetro conditional_value para saber qué valor ha de tomar el objeto para que se muestre esta acción.
articulosGeneratorHelper.class.php
<?php
class articulosGeneratorHelper extends BaseArticulosGeneratorHelper
{
public function linkToPortada($object, $params)
{
$conditional = (isset($params['params']['conditional'])) ? 'get'.ucfirst($params['params']['conditional']) : null;
$conditional_value = (isset($params['params']['conditional_value'])) ? $params['params']['conditional_value'] : true;
if ( ($conditional == null) || ($conditional != null && $object->$conditional() == $conditional_value) ) {
return link_to(__($params['label'], array(), 'sf_admin'), 'articulos/' . $params['action'] . '?id=' . $object, array('confirm' => !empty($params['confirm']) ? __($params['confirm'], array(), 'sf_admin') : $params['confirm']));
} else {
return '';
}
}
}
Tengo que decir que no he visto nada en la documentación oficial de Symfony al respecto, por lo que no se hasta qué punto es una forma correcta de hacer uso de ésto, sobre todo con el paso de parámetros no estándares (conditional y conditional_value) desde el generator.yml al helper del módulo.