Javi Sanromán

Bastante tiempo sin escribir ya. Desde la última vez: unas cortas y merecidas vacaciones, comienzo de un proyecto muy ilusionante del que espero hablar algún dia (lo contrario sería una mala noticia), mucho trabajo, y por último una gran noticia pero que me trae en vilo últimamente. En fin que todo a su debido tiempo e intentando mantener la cabeza bien fría.

En mi macbook no tengo ningun servidor de smtp instalado, ni quiero si no es absolutamente necesario. Por ello que para hacer diferentes pruebas de envio de mail desde local utilizo servidores externos. Tengo una cuenta creada en google para este fin, en este caso concreto utilizo cakephp, y ni el componente que este trae por defecto ni phpmailer pueden conectarse con las cuentas gmail al no soportar TLS (Trasport Layer Security), protocolo de autentificación utilizado por gmail.

Buscando otras opciones me encontré con SwiftMailer, y aunque sería sencillo desarrollar un componente que haga uso de esta librería ya lo han hecho por nosotros http://bakery.cakephp.org/articles/view/swiftmailer-component.

Este componente que nos descargamos para cakephp usa sendmail por defecto, pero si lo que necesitamos (por ejemplo una vez subamos a producción) es simplemente usar la función mail() de php, SwiftMailer nos ofrece un wrapper sobre la misma mediante la clase Swift_MailTransport.

Tanto los componentes como los helpers están diseñados para extender las funcionalidades que el propio núcleo cake nos ofrece. La diferencia? bien sencilla. Mientras los componentes añaden lógica de negocio a nuestro proyecto, los helpers añaden lógica de presentación.

Componentes:
Existen multitud de componentes que podemos descargar y utilizar: Sending Email With PHPMailer, Integrate CakePHP with Kcaptcha, Google Geocoder, LastRSS CakePHP Component, Pagination Component, etc. Y otros que ya vienen incluidos con el núcleo cake: AuthComponent (Gestión y autenticación de usuarios), RequestHandler (Obtener información de las peticiones http), CookieComponent (Gestor de cookies), AclComponent (Access Control List), EmailComponent (Envio de mails), SecurityComponent (Incrementar la seguridad de tu aplicación), SessionComponent (Gestor de session). Y podemos crear nuestros propios componentes para cumplir diferentes requisitos:

Crear un nuevo componente para cakephp es muy sencillo. Basta con crear un fichero en app/controllers/components/fichero.php con una clase nombrada FicheroComponent que tendrá una variable $controller y un método:

Luego para hacer uso de un componente en uno de nuestros controladores simplemente lo añadimos al array

y ya lo tendremos disponible como

Aqui tenemos un buen ejemplo de uso del json component.

Helpers:
Respecto a los helpers también los tenemos incluidos en el núcleo cake: html (ayuda a contruir tags html), form (ayuda a contruir formularios), number (ayuda a formatear numeros), timer (ayuda a formatear fechas), xml (simplifica la construcción de documentos xml), ajax (uso de ajax mediante prototype). Su uso es tan sencillo como:

Al igual que los componentes también podemos desarrollar nuestros propios helpers, aqui tenemos un buen ejemplo donde se crea un helper para autocompletar un input text mediante ajax .

Hoy, después de pelearme con el eclipse un rato (tampoco fue como para una separación seria, solo unos días hasta que se me pase) me he dado una vuelta por netbeans y me entero de que la nueva versión 6.1 ya trae el plugin integrado para soportar php. Es mas, nos podemos descargar una versión de este ide solo con el plugin para php por la módica cantidad de 16MB.

La he instalado y las primeras impresiones son buenas pero...

El editor está bien, el autocompletado de funciones funciona!, la refactorización se reduce a renombrado de ficheros y ni siquiera lo hace bien, excelente integración con svn (igual que la versión javera), en principio parece que la integración con xdebug es bastante buena pero solo lo he usado con proyectos demo.

Pero... el mismo pero de siempre, sigue siendo muy pesado, consume una grandísima cantidad de memoria. Será momento de plantearme un cambio de equipo? mmm, no se no se, creo que aguantaremos un poquillo mas.

http://wiki.netbeans.org/PHP

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

En días como hoy es cuando se echa de menos un hombro donde desahogar las penas, un compañero al que preguntar, o simplemente al que decir "¿esta bien verdad?, ¿y pq no funciona entonces?, es que no lo entiendo, ¿enviamos un bug?...y mil cosas mas sin sentido cuando finalmente encuentras los porqués".

Volviendo al proyecto en el que ya estoy sumergido necesito además de una 4 de mysql una 4 de php, y claro en mi ubuntu estoy con la 5. Venga a buscar soluciones.

Para tener 2 versiones de php corriendo en la misma máquina, sin virtualizaciones ni nada que este cacharro no esta para esos trotes, necesitamos tener una instalada como módulo y otra como cgi. Como módulo tengo la 5.2.3 y necesito instalar una 4 como cgi.

Voy a recurrir a los repositorios de http://www.dotdeb.org/mirrors para hacerme con la 4.4.8. Edito mi sources.list y añado los repositorios de dotdeb.

Tras actualizar los repositorios hago un apt-get install php4-cgi y primera en la frente, dependencia libzzip-0.12 incumplida (paso mucho miedo, pero con suerte no es recursiva), es lo que tiene recurrir a estas versiones antiguas empaquetadas. Nos vamos a debian http://packages.debian.org/etch/i386/libzzip-0-12/download descargamos e instalamos el paquete.

Ahora si apt-get install php4-cgi y php4 instalado. Instalamos además otros paquetes que necesitaremos apt-get install php4-curl php4-domxml php4-gd php4-gmp php4-imap php4-ldap php4-mcal php4-mcrypt php4-mysql

Ahora que tenemos php4 instalado y nuestro ejecutable en /usr/lib/cgi-bin/php4, editamos nuestro virtual host de apache:

y tenemos que activar el modulo actions (a2enmod actions) o no podremos ejecutar la linea Action php-script /cgi-bin/php4 .
Y con esto ya tenemos este virtual host utilizando la 4. Ala mañana mas que hoy ya es tarde.

Este fin de semana el cake me hizo otra de las suyas. Aunque pensándolo bien siempre podemos disculparlo por trabajar en beta.

El caso es que yo necesitaba mi propio AppController para incluir una serie de acciones comunes a todas las peticiones, y que se ejecutarían en el beforeRender() (justo antes de renderizar la vista y después de ejecutar toda la lógica de los controladores).

Esto en cake 1.1 se hacía copiando el app_controller.php a la raíz de /app, sobreescribíamos los métodos necesarios y listo. Y claro antes de leer nada fue lo primero que hice en cake 1.2. Pero no tuve suerte. Resulta que no encontraba los métodos que estaba declarando. Cake no estaba cargando mi app_controller sino el por defecto en /cake/libs/controller.

De primeras acudí a google (no conozco otra forma mas rápida de encontrar solución a este tipo de problemas) y tras comprobar que era al único que le sucedía tal cosa me fuí directo a http://manual.cakephp.org/complete/3/the-manual y la sorpresa cuando me encuentro con estas líneas:

Both controllers, helpers and models have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.

Lo estaba haciendo bien!, tras navegar por el registro de bugs llegué a esta conversación en el grupo de google , que seria de mi sin la comunidad!, resulta que para extender el app_controller en cakephp 1.2 debes situarlo en /app/controllers/app_controller.php y no en /app/app_controllers.php.

No me quejo, es el riesgo que se corre por trabajar en betas, además, quitando estos dos detalles cake y yo nos llevamos bastante bien. Aunque eso si, prefiero no tener documentación a tener documentación mentirosa.

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.