Javi Sanromán

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 .

Desde que trabajo con una relativa flexibilidad de horarios necesito mas que nunca llevar un estricto control sobre el tiempo que dedico a ciertas tareas.

En otros posts pasados había hablado de rememberthemilk como un fantástico gestor de tareas online, que había mejorado considerablemente en las últimas versiones y sobre todo con su última integración con gmail. Lo mantengo y sigo utilizando. Pero ahora necesito además asignar tiempos a estas tareas, o mejor, a un conjunto de estas.

Después de unas semanas de prueba con varias utilidades: gtimer, gnotime, wmwork, worklog, gtimelog creo que finalmente he encontrado lo que buscaba: hamster. Visualmente correcto, funcionalmente sencillo pero suficiente, justo lo que necesito, alta/baja de tareas agrupadas por categorías y asignación de tiempos a cada tarea. Suficientes resúmenes estadísticos e integración con la barra de menús de gnome.

Pero como sabéis hace un tiempo que me pasé a xfce, así que he tenido que instalar el xfce4-xfapplet-plugin mediante el que podemos incluir en nuestra barra de menú de xfce cualquier applet gnome.

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.

Pues si con este inicio de mayo y un año mas encima cambiamos de proyecto y necesariamente hemos de utilizar mysql4.

En mi ubuntu gutsy (todavía no me he atrevido a actualizar) tengo instalada mediante apt la versión 5, así que no me quedaba otra que buscar la forma de tener las 2 funcionando en mi portatil ya que la opción de servidor de desarrollo en casa a día de hoy es inviable. Yo he compilado los fuentes de mysql4 para conseguirlo aunque tenemos otras opciones. En este provechoso articulo tenemos información sobre esto.

Lo primero es descargar los fuentes.
Descomprimimos y preparamos la compilación para indicar el puerto, socket y directorio de instalación, todos diferentes a la versión 5 actual claro:

Compilamos "make" e instalamos "make install".

Copiamos el fichero de configuración a la nueva instalación:

Creamos las BD (test, mysql, information_schema) necesarias para mysql ejecutando ./bin/mysql_install_db.

Iniciamos ./bin/mysqld_safe --defaults-extra-file=my.cnf indicando el fichero de configuración a utilizar.

Y listo, probamos si ha iniciado correctamente realizando una conexión: ./bin/mysql -h 127.0.0.1 -P 3308 -u root, especial atención a la ip y no "localhost" para que la conexión se realice mediante TCP/IP.

Y a currar en 5 y 4.