Javi Sanromán

Ayer un compañero de trabajo me habló de propel el cual no conocía (gracias Juanjo :-)). Es un orm para php basado en torque competencia directa del conocido hibernate en el mundo j2ee.

Propel está disponible en los repositorios de pear por lo que su instalación puede llegar a ser de lo mas sencillo si utilizamos estos repositorios:

o igualmente sencilla al estilo tradicional, descargamos paquetes, descomprimimos paquetes :-).

Propel depende de otros paquetes pear que necesitamos tener instalados (phing, creole y opcionalmente Log):

También necesitaremos el modulo php5-xls si no lo tenemos ya, un simple apt-get install php5-xls bastará en ubuntu.

En el directorio propel/generator/projects tenemos un proyecto "bookstore" que utilizaremos para nuestra primera toma de contacto. Tenemos 3 ficheros:
- build.properties: Definimos las propiedades de nuestro proyecto necesarias para generar nuestros modelos a partir de las definiones xml.
- runtime-conf.xml: Definimos las propiedades de nuestro proyecto, nombre, conexión con BD, paquetes de clases a generar, etc, a utilizar en nuestro proyecto, este xml se trasformará una vez construido el modelo de clases en un array de datos definido en nuestro próximo fichero de configuración.
- shema.xml: La definición de nuestro modelo de datos a partir del que generar el modelo de clases y los scripts .sql necesarios para generar nuestra BD.

Una vez tenemos los ficheros anteriores correctamente configurados simplemente necesitaremos ejecutar:

Script que encontramos en propel/generator/bin y que nos genera dentro de nuestro proyecto un directorio build con:
- clases: Todas las clases que representan a nuestro modelo de datos y a través de las cuales nos comunicaremos con nuestra BD.
- conf: Nuestros ficheros de configuración, aquel generado a partir del anterior runtime-conf.xml.
- sql: Los scripts *.sql para contruir nuestra BD.

El que para generar una entidad necesite crear 5 ficheros me resulta engorroso, creo que muchas de las funcionalidades escritas en estas clases deberían estar incluidas en el núcleo propel:
- Entidad.php: Clase vacía que deberemos utilizar para extender la funcionalidad de esta entidad.
- EntidadPeer.php: Clase vacía que deberemos utilizar para extender las operaciones de consulta y actualización contra la tabla a la que representa esta entidad.
- om/BaseEntidad.php: Clase generada con todos los atributos getters&setters y demás operaciones de nuestro modelo definido en el xml.
- om/BaseEntidadPeer.php: Operaciones básicas de consulta y actualización contra la BD a la que representa esta entidad.
- map/EntidadMapBuilder.php

No creo que lo utilice por ahora, me gustaría que tuviera un nivel abstracción mayor sin tener que recurrir a la generación de código, y por otro lado el proyecto al que podría aplicarlo ahora mismo estimamos que deberá soportar una gran cantidad de tráfico y creo que nuestros DAOS serán mas eficientes, de todas formas lo seguiré de cerca.

Os dejo una presentación de Hans Lellelid (uno de los directores del proyecto):

Cuantas veces este ha sido motivo de debate. ¿Merece la pena utilizar un sistema de plantillas estilo smarty para php?. ¿Acaso no es php un lenguaje de script suficientemente limpio y potente como para poder valerse por si solo como motor de plantillas?. ¿Que diferencia encontráis entre estas 2 lineas?:

¿De verdad creéis que la primera es mas sencilla?.

Como ya habréis intuido yo nunca estuve de acuerdo en utilizar un lenguaje añadido de plantillas, básicamente porque no me aporta nada. Por supuesto que estoy de acuerdo en separar las capas de presentación y lógica pero esto lo podemos hacer tanto con php como no hacerlo con cualquier motor de plantillas. Todo depende de como lo utilicemos.

Pero yo prefiero esto:

y no esto:

Por cierto tanto cakephp como zend framework han adoptado la primera opción de forma nativa, lo que no quiere decir que no existan plugins para poder utilizar algún lenguaje propio de plantillas.