A continuación, explicaré como organizar mi PROJECT_DIR/config/databases.yml para múltiples conexiones.

   all:
     propel:
       class:          sfPropelDatabase
       param:
         dsn:          mysql://USERNAME:PASSWORD@DB_HOST_1/DB_NAME

     dataBases2:
       class:          sfPropelDatabase
       param:
         dsn:          mysql://USERNAME:PASSWORD@DB_HOST_2/DB_NAME

Dada esta estructura de mi databases.yml, me obliga a modificar el archivo PROJECT_DIR/config/propel.ini para al momento de realizar symfony propel-build-schema xml con el fin de que se generen los schema.xml que necesito para los distintos modelos del proyecto. Recomiendo cambiar el nombre del esquema por cada conexión que exista, Ejemplo: dataBases2.schema.xml

Lo principal a tener en cuenta es que siempre debe existir una conexión denominada “propel”. Esto es necesario para ciertas cosas, para que funcione correctamente el comando “symfony propel-build-model”, etc especialmente desde los usos schema.yml que el nombre de conexión.

Ahora, cuando vayas a realizar una consulta, sólo tienes que decirle a Propel qué conexión va a utilizar. De forma predeterminada, Propel utiliza la conexión “propel”; Aquí es donde se usa de las dos conexiones definidas en el archivo PROJECT_DIR/config/databases.yml descrito anteriormente:

$c = new Criteria();
$articles = ArticlePeer::doSelect($c, Propel::getConnection('dataBases2'));

Organizar el modelo en una estructura de subpaquetes

La manera de organizar nuestro modelo, es con los schema.xml que generemos; es muy sencillo.

Debemos modificar el atributo package de nuestro schema.xml; este indica la ruta donde se guardan las clases generadas automáticamente. Su valor por defecto es lib/model/, pero se puede modificar
para organizar el modelo en una estructura de subpaquetes. Si por ejemplo no se quieren
mezclar en el mismo directorio las clases del núcleo de la aplicación con las clases
de un sistema de estadísticas, se pueden definir dos esquemas diferentes con los paquetes

lib.model.aberic y lib.model.matatigre

Por último ejecuta el comando symfony propel-build-model y listo.

Un Saludo Cordial

Henry Vallenilla
Desarrollador Symfony
Caracas - Venezuela
Visita - www.matatigre.com

Amigos del blog. Cuando se requiere en symfony cambiar los archivos bases que sirven para generar los CRUD, a veces se nos olvida las rutas en donde ellos se encuentran.

Para los usuarios que usan Linux (mi distribucion es Ubuntu 8.0.4) es la siguiente

carpeta symfony         /usr/share/php/symfony

carpeta data              /usr/share/php/data

Amigos del blog. Cuando se trabaja con archivos batch, creados por symfony, los cuales usan llamadas a archivos o clases externas, se presenta el dilema de, cuando son ejecutados por el cron de linux, estos no son bien interpretados por el mismo, generando la no ejecucion del mismo, adicionando que en el log de errores del cron de linux, no se guarda huella del error.

Estos archivos pueden ser cualquier libreria externa q sea necesario para el procesamiento del batch, los cuales por lo general, estan en logica de php normal.

para no enrredarnos con procesos de autocarga de clases del symfony, el cual requiere instalar la utilidad Pake, os dejo una solucion alternativa para ello, el cual le deja el trabajo a symfony:

partiendo de un directorio en batch que tiene unas librerias externas en el, sustituimos:

include_once(’nombre de la carpeta donde esten las librerias/nombre de la libreria a incluir.php’);

por:

include_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’batch’.DIRECTORY_SEPARATOR.’nombre de la carpeta donde esten las librerias’.DIRECTORY_SEPARATOR.’nombre de la libreria a incluir.php’);

si os configuraste bien, debe ser capaz de ejecutarse el archivo batch desde cualquier carpeta donde estes parado en consola

La mejor forma de construir un select->

<?php echo select_tag('id_portfolio',
objects_for_select(PortfolioPeer::doSelect(new Criteria()),
'getIdPortfolio','__toString',
$sf_request->getParameter('id_portfolio'),
array('include_custom' => 'By Company'))) ?>

Saludos,

Henry Vallenilla
Caracas - Venezuela
Visita - www.matatigre.com

Aberic Solutions, lanza al mercado una nueva versión de su sistemas de gestión web, Lynx Cms administrador de contenido. La renovada aplicación ha sido desarrollada por la empresa como una nueva plataforma en un entorno dinámico y amigable.

Entre las principales características cabe destacar que favorece el acceso a la información esencial, incrementa la eficiencia del trabajo dando valor agregado a los procesos medulares, se minimizan las interrupciones en el trabajo gracias a su sencilla y flexible implementación, y maximiza la inversión al ofrecer la capacidad de ampliar sus funciones según crecen las necesidades de la empresa.

Bajo una nueva plataforma de programación, el Lynx Cms, ofrece al cliente una herramienta más robusta, en el que se hacen perfeccionamientos a la interfaz, optimización en el manejo y funcionalidades de los módulos de administración de contenido, incrementa los niveles de seguridad, flexibilidad para la implementación de nuevas funcionalidades y aumenta la velocidad de respuesta de la plataforma. Ofrece grandes beneficios al momento de crear un nuevo contenido para su site, especialmente en la industria del entretenimiento, servicios y el sector público, mercados a los que Aberic Solutions también brinda sus productos.

A mediano plazo además de administrar su contenido, se plantea que pueda interactuar con redes sociales, visualizar sus estadísticas de visitas, hacer trabajos de mercadeo, etc.

De esta manera el sistema ofrece, tanto al administrador de la página web como al autor, un entorno sólido y fiable con una arquitectura diseñada para cumplir las demandas en tiempo real del negocio empresarial.

El valor que esta nueva plataforma de gestión de contenidos puede aportar a su negocio es vital y sólo puede conseguirla en Aberic Solutions.

[Show as slideshow]

Entre el día a día del symfoneo, estuve trabajando en la integración de un FCKEditor en un formulario ajax (form_remote_tag) , para la sorpresa de que cuando se hacía POST, el valor de este campo de texto enriquecido llegaba en blanco.

La solución es conseguir que el contenido de entrada del FCKEditor. para esto agregar la siguiente linea en los parametros del submit_tag.

onclick="('campo').value=FCKeditorAPI.GetInstance('campo').GetXHTML();
return true;"

Importante: No aplica para submit_remote_tag.

Espero les sirva de mucha ayuda.
Saludos.

Esta es otra manera de actualizar uno o varios registros usando Propel:

$con = Propel::getConnection();

// select from...
$c1 = new Criteria();
$c1->add(CommentPeer::POST_ID, $post_id);

// update set
$c2 = new Criteria();
$c2->add(CommentPeer::RATING, 5);

___________________________________________________________________________________________________

Si estas una clase Peer:

$con = Propel::getConnection();

// select from...
$c1 = new Criteria();
$c1->add(self::POST_ID, $post_id);

// update set
$c2 = new Criteria();
$c2->add(self::RATING, 5);

BasePeer::doUpdate($c1, $c2, $con);

BasePeer::doUpdate($c1, $c2, $con);

Recientemente estuve trabajando en la modificación del generador crud (propel-generate-crud) de symfony para que me incluyera codificaciones propias. En el camino me encontré que el generador de symfony no agregaba las carpetas validate para incluir archivos validadores .yml, revisando un poco el código fuente de symfony, me topo con las clases sfCrudGenerator.class.php y sfGenerator.class.php, aunque estoy algo nuevo en esto, por descarte encontré que la clase sfCrudGenerator.class.php es la que se ejecuta cuando corremos el comando symfony propel-generate-crud desde nuestra consola, esta clase hereda los métodos de sfGenerator.class.php. Ahora bien ¿por que? explico todo esto.

La solución que para que symfony se me creara la carpeta validate y sus respectivos archivos, fue modificar ambas clases de la siguiente forma:

1.- En la clase sfGenerator.class.php en el método
generatePhpFiles($generatedModuleName, $templateFiles = array(), $configFiles = array()):
Debemos incluir $validateFiles = array() como parametro del métodos quedando de la siguiente forma
generatePhpFiles($generatedModuleName, $templateFiles = array(), $configFiles = array(), $validateFiles = array()).
Posteriormente agregamos las siguiente lineas antes de terminar el metodo:
// generate validate files
foreach ($validateFiles as $validate)
{
// eval validate file
$retval = $this->evalTemplate(’validate/’.$validate);
// save validate file
$this->getGeneratorManager()->getCache()->set($validate,      $generatedModuleName.DIRECTORY_SEPARATOR.’validate’, $retval);
}

2.- Luego desde la clase sfCrudGenerator.class.php en el método generate($params = array()) le enviamos el parámetro para que tenga efecto lo agregado en la clase sfGenerator.class.php:
Agregamos
$validateFiles = sfFinder::type(’file’)->ignore_version_control()->name(’*.yml’)->relative()->in($themeDir.’/validate’);
Posteriormete modificamos la linea
$this->generatePhpFiles($this->generatedModuleName, $templateFiles, $configFiles);, quedando
$this->generatePhpFiles($this->generatedModuleName, $templateFiles, $configFiles, $validateFiles);

No se realmente si existe otra manera para que las carpetas validate se agreguen en el momento de generar el CRUD, pero realmente fue muy excitante navegar por los códigos de symfony y modificar su codificacion, por codificación esto lo hice en la versión 1.0.17 desconozco si ya fue incluido en las nuevas versiones.

En la nueva version que se instala del sfPrototypeWindowPlugin, se produce un error de Javascript (Prototype.Browser is undefine), para corregirlo:

Sustituir todos los
“Prototype.Browser”.
con los sucesos
“Prototype.BrowserFeatures”.
en el archivo window.js ubicado en el directorio plugins/dwPrototypeWindowPlugin/web/js/

Fuente: http://forum.symfony-project.org/index.php/m/47871/

Fuente Original: http://symfoniac.wordpress.com/2007/05/28/how-to-fix-a-manually-deleted-plugin-directory

Al momento de desinstalar un plugin, no es simplemente eliminar el directorio, hay que usar el comando plugin-uninstall

Si después de borrar el directorio se ejecuta symfony plugin-list , el plugin sigue apareciendo como instalado. Además, tampoco se puede volver a instalar el plugin porque PEAR indica que ese plugin ya está instalado.

La razón es que cada plugin que se instala, crea un archivo de tipo .reg en  el registro de PEAR. Por tanto, para desinstalar completamente un plugin, no solo se debe borrar su directorio, sino que también es necesario eliminar el archivo de registro que se encuentra en  plugins/.registry/.channel.pear.symfony-project.com/[nombre_plugin].reg

El comando sería (Ejemplo: sfThumbnailPlugin)

rm plugins/.registry/.channel.pear.symfony-project.com/sfthumbnailplugin.reg