[php]<br /><br /> public function duplicate()<br /> {<br /> // duplicar object<br   /> $ap = clone $this;<br /><br /> $values = $ap->toArray( );<br /><br /> $values2 = array();<br /><br />   // crear array de campos para forzar el isModified<br /> foreach( $values as $idx => $v )<br /> {<br /> $values2[ $idx ] = null;<br /> }<br /><br /> $ap->fromArray( $values2 );<br /> $ap->fromArray( $values );<br /><br /> $ap->setIsActive(false);<br /> $ap->setId(null);<br /> $ap->setNew(true);<br /> $ap->save();<br /><br /> return $ap;<br /> }<br /><br />[/php]

Aquí está el link del anuncio.

Es importante leer el documento que explica como “upgradear” proyectos de 1.0.

El mismo dia, también fue lanzado Symfony 1.0.17.

Para correr Symfony en un cluster de servidores web es necesario guardar la sesión en un lugar centralizado. Para esto se puede utilizar Mysql.

Es necesario crear una tabla para guardar los datos. El schema es el siguiente:

CREATE TABLE IF NOT EXISTS `session` (
`id` VARCHAR(32) NOT NULL ,
`sess_time` INT NULL ,
`data` TEXT NULL ,
PRIMARY KEY (`id`) )

Luego, hay que configurar Symfony para utilizar esta tabla. Primero, debemos crear la conexión a la base de datos para la sesión . En el archivo config/databases.yml ponemos:

session:
class: sfPDODatabase
param:
dsn: mysql:dbname=mydb;host=localhost
username: myuser
password: mypass

Recuerden reemplazar los datos de dbname, host, username, y password con sus datos de conexión.

Luego, en la configuración de la aplicación es necesario definir la clase para guardar la sesión utilizando PDO. En el archivo config/factories.yml de la aplicación debemos agregar lo siguiente:

all:
class: sfPDOSessionStorage
param:
db_table: session
database: session
session_name: session
db_id_col: id
db_time_col: sess_time
db_data_col: data

Luego de limpiar el cache con symfony cc la sesión deberia ser guardada en la tabla.

También es posible utilizar la conexión de propel existente, pero al momento de escribir este artículo tengo algun problema con este método. Luego comentaré la solución.

Links para más información:

• http://www.symfony-project.org/snippets/snippets/tagged/session/order_by/date
• http://www.symfony-project.org/book/1_0/06-Inside-the-Controller-Layer#User%20Session

mebelipropel.mysql.tableType = InnoDB

Luego, ejecutando “symfony propel-build-sql” generará el archivo .sql en data/sql con el correspondiente tipo.

Luego de convertir el modelo a un schema.yml con propel, y generar un admin con propel-init-admin descubrí que el sorting usando columnas que son BIGINT no estaba correcto. El orden era calculado usando strings en vez de números.

Así fue como descubrí que propel convierte BIGINT a strings y no INT.

Para solucionar el problema, hay que reemplazar BIGINT por INTEGER y generar el modelo nuevamente.

Por su parte, Symfony tiene un feature muy bueno: cuando uno crea un admin basado en un modelo, si encuentra una columna BOOLEAN, lo presenta con un checkbox, pero si es TINYINT pone un INPUT TEXT.

Como a mi me gusta generar el modelo usando el MySQL Workbench cuando genero el schema para el symfony utilizando la base de datos creada, symfony encuentra la columna como TINYINT.

Para resolver esto, utilizo el comando sed para hacer el reemplazo en un script de bash:

#!/bash/sh

symfony clear-cache

symfony propel-build-schema

mv config/schema.yml config/schema_bak.yml

sed s/TINYINT/BOOLEAN/ config/schema_bak.yml > config/schema.yml

symfony propel-build-model

Luego de generar el admin con symfony propel-init-admin, editando el archivo generator.yml del modulo en cuestión:

list:
peer_method: doSelectJoinDestinatario
display: [mensaje, destinatario]

Pero hace unas semanas comencé un proyecto con una base de datos con muchas tablas, que requiere de un sistema de administración completo. A esta altura, lo que menos me gusta de desarrollar aplicationes web es el trabajo monótono y repetitivo de crear listas y forms para un backend. El Zend Framework todavia no tiene todos los utilitarios para la generación de código, ya sea de objetos relacionados con el modelo (las tablas) o menos aún la generación automática de un sistema de administración de dicha información.

El framework Symfony si lo tiene. Por este motivo, estas ultimas semanas estuve introduciendome a dicho proyecto, que por cierto, tiene una madurez y una calidad considerable, no por nada Yahoo lo eligió para alguno de sus sistemas.

Gracias a esto, ire comentando alguna de mis experiencias con Symfony, algunas serán muy basicas y otras no tanto. Espero sus comentarios.

En estos dias he tenido la necesidad de instalar una copia de Symfony en un host compartido.
Yo ya había instalado dicho software en un par de máquinas pero de forma totalmente libre y standard, cosa que no
ocurre en los hosting compartidos donde, normalmente, existe una estructura fija que no responde a las necesidad del framework.

En este caso, mi proyecto Symfony consistía en una estructura “de manual”:

myproject
+—apps
¦ +—backend
¦ ¦ +—config
¦ ¦ +—i18n
¦ ¦ +—lib
¦ ¦ +—modules
¦ ¦ +—templates
¦ +—frontend
¦ +—config
¦ +—i18n
¦ +—lib
¦ +—modules
¦ +—templates
+—batch
+—cache
¦ +—frontend
¦ +—dev
¦ ¦ +—config
¦ ¦ +—i18n
¦ ¦ +—apps
¦ +—prod
¦ +—config
¦ +—i18n
¦ +—apps
+—config
+—data
¦ +—model
¦ +—sql
+—doc
+—lib
¦ +—model
¦ +—map
¦ +—om
+—log
+—plugins
+—test
¦ +—bootstrap
¦ +—functional
¦ ¦ +—backend
¦ ¦ +—frontend
¦ +—unit
+—web
+—css
+—images
+—js
+—uploads
+—assets
+—thumbnail

Al acceder al hosting me encuentro con una estructura donde:

1. No existí­a Symfony.
2. Existía un directorio httpdocs al que apuntaba el virtual host y donde debía dejar toda mi aplicación

El primer paso fue tomar conciencia de que era imposible instalar mi aplicación de esa forma.
Symfony tiene un directorio web al que debe apuntar el virtual host y todo el resto de la
aplicación debe estar por detrás de este.

En la empresa de hosting (servergrove) fueron muy gentiles, comprendieron el problema
y me habilitaron un directorio por debajo de httpdocs para instalar mi aplicación. De esa
forma, solo deberí­a hacer que Symfony entendiera que su directorio web, normalmente
dentro del árbol de la aplicación, estaba fuera de este, en httpdocs, algo que era posible
por configuración.

Ahora el problema pasaba a ser la instalación de Symfony.

Primero intenté instalarlo a mano, descargando un tarball y poniéndolo en un directorio
del host. Luego de muchas pruebas me rendí­ ya que no logré que eso funcionara.

La instalación normal y recomendada es utilizando PEAR y, dado que el hosting tení­a PEAR
instalado, imaginé que no vendrí­a mal que hicieran la instalación ellos. Nuevamente
la gente de servergrove me solucionó el problema y Symfony quedó instalado de forma
standard en un directorio accesible por Apache y en el path.

Ahora ya podía ejecutar comandos de Symfony (por ejemplo limpiar el cache con symfony cc)
dentro del directorio de mi aplicación. Y funcionaba !.

El siguiente paso consistí­a en indicarle a Symfony que el directorio web pasarí­a a ser httpdocs.
Para hacer esto, es necesario ir al archivo index.php de nuestra aplicación y modificar lo siguiente:

define(’SF_ROOT_DIR’, dirname(__FILE__).’/../myproject’);

De forma tal que SF_ROOT_DIR apunte a nuestra aplicación.

Luego, en el archivo config/config.php de nuestra aplicación hay que modificar dos paths:

sfConfig::add(array(
’sf_web_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’www’,
’sf_upload_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’www’.DIRECTORY_SEPARATOR.
sfConfig::get(’sf_upload_dir_name’),
));

De forma tal que quede así:

sfConfig::add(
array(
’sf_web_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’..’.DIRECTORY_SEPARATOR.
’httpdocs’,
’sf_upload_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’..’.DIRECTORY_SEPARATOR.
’httpdocs’.
DIRECTORY_SEPARATOR.sfConfig::get(’sf_upload_dir_name’),
));

Cabe destacar que el archivo config a modificar es el de cada aplicación (por ej: myproject/apps/frontend/config.php) y no el del proyecto (myproject/config/config.php)
porque el objeto sfConfig no esta disponible en el config del proyecto.

La instalación de Symfony tambien requiere establecer un alias en la definición del virtual
 host para algunos scripts y librerías que utiliza. Dado que esto es imposible en un hosting
 compartido, una solución sencilla es copiar el directorio sf de PEAR/symfony/ al directorio
web de nuestra aplicación, en este caso httpdocs.

Con estos pasos, la aplicación esta lista para funcionar.