Acerca de la autorización (CADUCADO)

CADUCADO: La información de este post apesta por lo vieja. Es posible que ya no sea válida con las versiones más recientes de CakePHP. Se mantiene público  para vergüenza y escarnio del autor.

Autorización, permisos, privilegios... como quieras llamarle. Después de aclararme (algo) las ideas con respecto al problema de la autentificación (asegurarse en lo posible de que un usuario es quien dice ser) ahora me toca romperme los cuernos con un sistema de autorización.

CakePHP proporciona algunas herramientas, como el soporte para ACL, pero es una de las partes que al parecer está más inestable en la versión 1.2 y también de las que menos documentación hay. No es que sea especialmente complicado lo de manejar las ACL, pero la implementación concreta igual es un poco abstracta de más por lo que he podido ver echando un vistazo al API.

En algunos de los artículos que he leído al respecto de la autorización he visto ideas que me han llamado la atención. Un sistema de permisos o autorizaciones es algo que tienes que pensar bastante bien porque debería cumplir varios requisitos:

• Estar lo más aislado posible del código de la aplicación. Esto es, la aplicación no tiene que saber nada sobre el "significado" de un permiso, sino simplemente si en una situación dada un usuario puede o no hacer algo, con uno o varios objetos. Hay que buscar el equilibro entre un modelo que sea abstracto y a la vez tenga significado. Y dado que estamos trabajando con CakePHP un objetivo es que el uso del sistema sea lo menos "intrusivo" posible.
  
• Ser fácilmente escalable, o sea, que pueda manejar los permisos con soltura a medida que crece la cantidad de usuarios y objetos, y a la vez, que sea fácil actualizar la estructura de permisos según sea necesario.
• Granularidad fina: que pueda controlar qué usuario puede hacer qué acción sobre qué objeto.
• Que funcione. Ya, ya sé. Es de perogrullo, pero un sistema de autorizaciones no sólo tiene que permitir a un usuario hacer lo que se supone que puede hacer, sino también debe prohibirle hacer lo que no puede.
  

Seguro que se me quedan más cosas, pero éstos requerimientos ya llegan bien para ponerte a pensar.

Enfoques

Existen varios enfoques para diseñar sistemas de autorización. No soy experto en el tema, así que no puedo hablar en mucha profundidad. Hay tres sospechosos habituales:

• Sistemas "a la Unix", en los que los objetos tienen un propietario que define los permisos básicos (de lectura, de escritura y otros que se puedan definir) para sí mismo, para un grupo y para el resto del mundo.
• Sistemas basados en ACL (Listas de Control de Acceso). En estas listas, se definen relaciones entre los sujetos, organizados en grupos jerárquicos, y los objetos, de modo que podemos permitir o denegar acceso a un objeto para un grupo atribuyendo en cascada el mismo privilegio a todos los grupos y sujetos que incluye. Y, posteriormente, podríamos añadir reglas para "matizar" esos privilegios en cada caso necesario.
• Sistemas basados en Roles. Los roles son conjuntos de permisos o privilegios que podemos asociar a los usuarios de forma individual o grupal. Esto es, definimos un rol describiendo todo lo que puede hacer y luego asignamos roles a los usuarios.

Por supuesto, existen sistemas más evolucionados y más o menos complejos. No voy a meterme, necesito desarrollar uno que me permita un control razonable.

Un modelo conceptual

Dándole vueltas he comenzado diseñar un sistema que parece tener buena pinta. Intentaré explicarlo paso a paso. Es bastante dependiente de la forma particular de hacer las cosas en Cake y de momento es sólo teórico, pues no lo he puesto en código aún. Quedan unos cuantos flecos por resolver.

Permisos

Una característica de CakePHP es la estructura de las URL. En una aplicación Cake cualquier cosa que pueda hacer un usuario se puede caracterizar con una URL de la forma /controlador/accion/atributos. Aunque hay casos particulares, nos vale como punto de partida.

Por lo tanto, para definir lo que un usuario puede hacer o no en esa aplicación podríamos empezar estableciendo si puede o no ejecutar la acción indicada por esa URL. Esquemáticamente, podríamos definir permisos en la forma:

Permitir /controlador/accion/
Denegar /controlador/accion/

Esta idea la encontré en este artículo de ThinkingPHP: A lightweight approach to ACL, Y alguna más también.

Por ejemplo, podríamos referirnos a tener acceso a todas las acciones de un controlador concreto mediante un sistema de comodines, o incluso de expresiones regulares:

Permitir /controlador/*/

Podríamos forzar un poco las cosas y ampliar el uso de esta simple estructura con los atributos y referirnos incluso si se puede aplicar la acción a un objeto determinado, pero a la larga eso nos lleva a algunos problemas, así que nos quedaremos ahí de momento.

Roles

Por supuesto, lo anterior no nos vale de mucho si no relacionamos los permisos con alguien que los pueda utilizar o no. Pero en lugar de hacerlo directamente vamos a definir roles, es decir, vamos a agrupar los permisos en perfiles de privilegios.

Los roles pueden tener asociados varios permisos y éstos pueden pertenecer a distintos roles. (o no, este es uno de los puntos que habría que matizar). Pero espero que captes la idea. Es decir, o bien

Roles hasMany Permisos, o bien,
Roles HABTM Permisos

Lo siguiente sería asociar los Roles a los Usuarios que los pueden desempeñar. Un mismo rol se puede asociar a varios usuarios, y un usuario puede tener distintos roles. O sea que:

Usuarios HABTM Roles

De modeo que ahora podemos saber qué permisos tienen un usuario viendo sus roles.

Ámbitos

Pero hay una cosa que no hemos definido. ¿Sobre qué objetos puede actuar un usuario o se puede ejercer un rol?

Una forma simple sería definir el permiso incluyendo en la url el parámetro que define el objeto sobre el que se realiza la acción (normalmente el id). Pero probablemente tropezaremos con un problema al tratar con acciones que implican varios objetos (como un listado de posts de un blog y cosas así). ¿Cómo podemos restringir la búsqueda de objetos para que sólo devuelva los que corresponden al sujeto?

Una posibilidad que se me ocurre es definir ámbitos sobre los que se ejerce un
rol
permiso
. Los ámbitos describen los objetos a los que tendríamos acceso ejerciendo ese rol
permiso
. Se me ocurren los siguientes:

• Objetos propiedad del usuario
• Objetos propiedad del grupo o grupos al que pertenezca el usuario
• Cualquier objeto
• Objeto especificado por su id
• Objetos del usuario especificado por su id
• Objetos del grupo espeificado por su id

(podría haber otros, claro)

Esto implica que llevamos cuenta de la propiedad de los objetos creados. Volveré sobre eso más adelante, de momento nos basta con tener presente que el sistema puede saber qué objetos pertenecen a un usuario.

Definiendo roles

Para definir un rol nos bastaría con darle un nombre, especificar un ámbito y crear permisos asociados con ese rol. El rol de root podría quedar definido así (de manera informal, claro):

rol: root

permisos:
Accion: /*/*/
Permitir: Sí
ambito: Cualquier objeto
rol: root

Un rol de visitante no registrado a un blog podría definirse así para que pueda ver los posts y comentar en ellos:

rol: no registrado

permisos
Accion: /Posts/ver
ambito: objetos del grupo "cualquiera"
Permitir: Sí
rol: no registrado

permisos
Accion /Posts/comentar
ambito: objetos del grupo "cualquiera"
Permitir: Sí
rol: no registrado

Políticas

Un aspecto que nos queda pendiente es saber qué se hace cuando no hay una regla explícita para un permiso. Una forma de resolver esto puede ser estableciendo políticas que regulen la manera en que se asignen permisos por defecto. Por ejemplo, una política podría ser la de denegar cualquier acceso salvo que se indique lo contrario. En cierto modo, una política puede definirse como un permiso por defecto para una determinada acción o para un determinado patrón de acciones.

Propiedad de los objetos

Todo lo anterior nos permitiría saber qué puede hacer un usuario en nuestro sistema, pero no nos dice mucho acerca de sobre qué objetos puede actuar. Los ámbitos nos permiten describir el rango de objetos, pero con referencia a sus propietarios.

Un sistema de propiedad de los objtos es algo tan simple como asociar cada objeto con un usuario o un grupo. Esto se podría hacer en la tabla de cada modelo de objeto "apropiable" o en una tabla aparte en la que se defina el objeto (mediante su modelo y su identificador único) y el sujeto que lo posee (usuario o grupo).

Una de las cosas maravillosas de CakePHP 1.2 es que este proceso de asignar la propiedad de los objetos se podría "automatizar" mediante un behavior "apropiable" para usar en los modelos de objetos susceptibles de tener poseedor. El behavior podría utilizar los Callbacks adecuados para poblar los campos de propiedad con los datos del usuario actual y/o los grupos a los que pertenece.

Determinando los objetos accesibles

Con la información de ámbito obtenida al analizar los
roles
permisos
ejercidos por un usuario debería ser fácil establecer las condiciones que sirvan para filtrar los objetos a los que el usuario tiene acceso. Por ejemplo, el ámbito "Objetos propiedad del usuario" se puede traducir como "propietario_id = usuario.id" (creo que se me entiende).

Estas condiciones se pueden pasar a las acciones para que tenerlas en cuenta en la búsqueda de datos.

Esto nos llevaría a que el proceso de autorización tendría dos fases:

• Determinar si el usuario puede realizar o no la acción que solicita.
• En caso positivo, determinar sobre qué objetos puede realizarla, o bien si los objetos sobre los que solicita realizarla pertenecen al ámbito definido en el rol
  permiso
  .
• En caso de que alguno de los dos puntos anteriores falle, comunicar al usuario que no tiene permisos y redirigirlo a un lugar adecuado.

Problemas del modelo conceptual

Hay algunos temas sin resolver en el modelo o que potencialmente pueden generar problemas.

El más importante tiene que ver con los conflictos de roles, esto es, si un usuario puede tener roles que definen permisos distintos o en distintos ámbitos para la misma acción. En particular si los permisos son contradictorios. Es necesario establecer un sistema que permita definir una precedencia.

Por ejemplo, un rol de usuario normal podría tener permisos para añadir, ver y editar sus propios registros pero no para borrarlos. Esto se podría definir de forma económica:

Permitir /registros/*
Denegar /registros/borrar

Teniendo un sistema de precedencia que determine correctamente que el segundo permiso sobreescribe al primeto. Aunque también podríamos definir el mismo rol, con más reglas:

Permitir /registros/agregar
Permitir /registros/ver
Permitir /registros/editar

Y una política que deniegue cualquier permiso no explícitado.

En fin. Lo dejo por ahora. Todavía tengo que darle un par de vueltas antes de poner esto en código. Es necesario también definir un API para interrogar al sistema, que adoptará la forma de un componente para añadir a los controladores que deban tener supervisión de permisos.

También hemos dicho hace un rato que hará falta un behavior que se encargue de registrar la propiedad de los objetos, así como tal vez algunos plugins que nos permitan manejar el sistema y definir reglas, roles y políticas.

Acerca de la autentificación (CADUCADO)

CADUCADO: La información de este post apesta por lo vieja. Es posible que ya no sea válida con las versiones más recientes de CakePHP. Se mantiene público  para vergüenza y escarnio del autor.

Después de varias semanas parece que va siendo hora de empezar a escribir código de verdad y no simples ejercicios y pruebas "a ver cómo va esto del Cake".

Por supuesto, para una aplicación seria tengo que buscar un sistema de autentificación y de gestión de permisos.

CakePHP 1.1 no incorpora ningún método propio de autentificación y sí un sistema de ACL (Access Control Lists) sobre la base de que:

• No es difícil desarrollarlo usando el framework
• Cada desarrollador tienen sus necesidades

CakePHP 1.2 tiene un componente Auth con muy buena pinta pero sin documentación. De hecho, todavía no he visto ningún tutorial que te permita entrar un poco en harina. Además, incorpora una nueva implementación de la ACL sobre base de datos que tiene una pinta excelente también, pero también poco documentada.

Aparte, existen unos cuantos sistemas de autentificación que son interesantes o tienen elementos interesantes:

• DAuth
• OthAuth
• YACCA (más orientado a permisos)
  
• ObAuth
• HTTP Client Class

El problema es que ninguno de ellos me acaba de convencer totalmente por una u otra razón.

Por lo pronto, habría que separar el sistema de autentificación del sistema de permisos. O al menos eso es lo que quiero hacer yo, y en alguno de los casos señalados hay cierta interacción entre ambos.

Quizá lo mejor sea coger lo que más me guste de cada uno y hacer algún refrito.

Autentificación

Lidiar con la autentificación supone intentar que:

• Los usuarios del sistema con credenciales adecuadas puedan "entrar"
• Evitar que usuarios maliciosos puedan lograr acceso o hacerse con contraseñas legítimas

Lo explica muy bien, Dieter Plaetnick en este artículo y en este otro. Plantea los problemas que hay que afrontar y resolver. Básicamente viene a decir:

• Almacenar las contraseñas encriptadas para que no se puedan obtener en caso de acceso a la base de datos (cierto, si un atacante accede a la base de datos estás vendido de todos modos, pero Dieter se refiere, por ejemplo a los alojamientos compartidos, donde hay técnicos que podrían curiosear).
• Yo añadiría que la aplicación no permita ver las contraseñas (ni siquiera los hash) a ningún usuario, ni siquiera administrador ni el mismo propietario. Si la contraseña se pierde, se cambia por otra, no es tan difícil.
• Enviar las contraseñas encriptadas del navegador al servidor, bien sirviendo por https (http + ssl, de modo que toda la comunicación viaja encriptada) o bien encriptando con Javascript en el navegador.
• Para dificultarlo más, utilizar una "sal" que convierta cada contraseña en única para la sesión. Esto es, que exista una especie de modificación de la contraseña para una sesión en particular, de modo que incluso en el supuesto caso de que un atacante intercepte la contraseña encriptada no pueda utilizarla en otra sesión. La cosa es generar una cadena (la sal) al iniciar una nueva sesión, incorporarla en el formulario (o en una cookie) del lado el cliente y en la sesión del para que se añada de algún modo a la contraseña (por ejemplo, encriptar la contraseña en el formulario y adjuntarle la "sal" y a lo mejor encriptar de nuevo). En el servidor, hacer algo parecido con la contraseña almacenada y comparar los hash resultantes.
  
• Lidiar con los ataques de fuerza bruta ue prueban a gran velocidad miles de contraseñas hasta encontrar alguna válida. Una forma de resolver esto es limitando la cantidad de intentos que se pueden hacer en un tiempo determinado, estableciendo listas "negras" de IP bloqueadas.
• Lidiar con la SQL injection, o sea, un intento de colar código SQL en los datos del formulario de login con el que se pueden conseguir cosas tan hermosas como login sin contraseña ni nada. Simplemente, un saneamiento de datos al recibir un formulario lo previene.
  
• Yo añadiría establecer unas reglas de validación de las contraseñas que obliguen a los usuarios a elegir contraseñas sólidas, como por ejemplo, incluir caracteres en mayúscula, minúscula, números y algún signo de puntuación. Es molesto, pero más molesto es que te birlen las credenciales y hagan guarrindongadas con tu cuenta.
• Otra historia es prevenir el posible "secuestro de sesión", es decir, que un usuario malicioso nos "sustituya" en medio de una sesión en la que ya estamos autentificados. Se puede hacer algo al respecto si guardamos suficiente información sobre la sesión actual, de modo que podamos detectar cosas como que haya cambiado la IP del cliente en plena sesión y cosas así.
  

Todo lo anterior es el planteamiento del problema. Luego hay que tener en cuenta todo el proceso de autentificación:

• Si no hay usuarios conectados, presentar el login (o si el usuario activa un enlace para que le salga el login)
• Mantener la información del usuario conectado para no pedirle el login cada dos por tres.
  
• Si un usuario está conectado, que no le salga el login.
• Si una acción está reservada a usuarios conectados, actuar en consecuencia. Es decir, que le pida el login si no está conectado ya o que no se lo pida si ya está dentro.

En cuanto a cómo montar esto en CakePHP parecen claras algunas cosas.

Debe haber un componente. Puesto que la acción se lleva a cabo en los controladores, es en éstos donde debemos introducir el código que se encarga de gestionar los usuarios conectados. La mejor forma es un componente.

Por otro lado, habría que definir modelos para usuario e intentos de login, (los grupos, en su momento). El modelo de usuario podría tener una información acerca del último login o del estado de conexión. O igual es mejor tenerlo en una tabla aparte. Algo así:

Users
id
username
password
email
login_desde (para controlar si agota el tiempo de sesión, hay que definir un tiempo de timeout)
remote_ip (para controlar si cambia en algún momento)

Intentos
id
remote_ip (para controlar la IP que está intentando acceder)
status (bloqueada, lista negra..., esto nos permitiría controlar que una determinada IP sea tratada de modo especial)

Tiene que haber, lógicamente controlador y modelos para administrar los usuarios y también alguna forma de revisar los intentos de conexión para poder hacer cosas como desconectar usuarios desde el sistem, o desbloquear/bloquear manualmente direcciones, mostrar información del usuario conectado.

Un helper para generar formularios de login con los scripts de encriptación tampoco vendría mal.

Sobre este sistema, se podría montar un sistema de perfiles que nos permita tener información y preferencias del usuario conectado, y de grupos para asignar permisos en bloque. Eso sí, el tema de permisos lo dejaré para otro rato. Por hoy ya me llega.

Alguna aclaración sobre este sitio

Antes de continuar "pasteleando" y en vista de que se empiezan a recibir visitas (gracias, de verdad), me gustaría dejar claros algunos asuntos.

Este sitio no pretende ser una referencia sobre CakePHP, sino más bien el diario de aprendizaje de un tipo que ha decidido portar sus aplicaciones web a este framework.

"Yo era un desgraciado..."

Después de varios años escribiendo aplicaciones PHP he acabado, como mucha gente, creando mi propio pseudo-framework, con resultados más o menos irregulares. Llegado un punto, el nivel de desestructuración y spaghetti alcanzó cotas poco manejables, lo que aconsejaba (más bien imponía) un cambio.

Decidido a empezar desde cero, comencé a tomar nota de las características y necesidades que tenía que cubrir el nuevo planteamiento. Mi idea era reescribir mi framework y me lo fui tomando con calma. Pero con el tiempo, me encontré con un cuaderno con un montón de notas que dejaban bastante claro por dónde quería tirar.

Llegué a la conclusión de que quería que mi framework se basase en MVC, que tuviese la suficiente inteligencia como para hacer algo parecido a ActiveRecord y scaffolding (aunque entonces no sabia ni que existía eso), que me permitiese más libertad con el HTML, que fuese más modular, más sencillo de escribir, que llevase bien las bases de datos relaciones, etc.

En algún momento, me hablaron de CakePHP y le eché un vistazo, pero aún no estaba yo lo bastante maduro como para caerme del guindo. Sin embargo, tomé nota de algunas de las ideas y las incorporé a mi lista.

Unas semanas después, una nueva conversación sobre el tema me decidió a mirar en serio CakePHP y encontré que todas las características (y más que ni sabia que necesitaba) estaban ya contempladas. Me leí el manual de cabo a rabo un par de veces, brujuleé por la Bakery y hasta eché un vistazo a un par de frameworks más.

Desde hace un mes y medio o así la decisión ya está tomada. Me siento cómodo con lo que CakePHP ofrece y a partir de ahora mis aplicaciones web van a migrar como está mandado.

El blog

El blog viene a cuento de lo anterior. No hay muchos recursos sobre CakePHP en castellano, y menos si has optado como es mi caso por la versión 1.2 (no tiene documentación oficial). Por otro lado, pensé que sería buena idea ir recogiendo aprendizajes, recursos y código en un sitio donde pudiese tenerlo todo a mano.

De ahí la idea del blog. Además, necesitaba la práctica de crearlo por otra razón y me venía bien trastear un sistema de blog más o menos popular (entre otras cosas porque aún es pronto para crear el mío encima de CakePHP...).

Por tanto, lo que se recoge aquí no es precisamente un manual, más bien es un diario de aprendizaje. El código, los ejemplos y las explicaciones pueden ser útiles, aunque si eres experto en Cake puede que sean más interesantes las aportaciones que puedas hacer en forma de comentarios que mis propios posts.

Acerca del código

El código que voy publicando puede no estar del todo completo pero he decido documentarlo lo más posible. Sobre todo por mí mismo, no veas el palo que resulta mirar una función que escribiste hace meses y ahora no saber ni qué parámetros se le pasan.

Suele pasar que cuando pongo un post aquí, se produce una reordenación de los bits en Internet relacionados con el tema y, de repente, aparecen varios artículos excelentes sobre el mismo, enseñando técnicas más simples, elegantes y eficaces, que el día anterior "no estaban" (más bien yo no supe encontrarlas). Por eso, a veces cambio mucho el código, incluso varias veces al día.

En fin, como puedes ver, se trata de un "blog de notas", más que otra cosa.

Manipulacion de arrays

Un artículo en ThinkingPHP sobre cómo se manipulan arrays usando la clase set, que resulta ser una herramienta estupenda para extraer información de arrays complejos (como los resultados de FindAll y así).

La clase Set tiene una variedad de métodos que voy a ponerme a explorar en cuanto pueda. Ya contaré.

Componente para mantener la información de paginado

Después de darle como muchas vueltas se me ha ocurrido escribir un componente para gestionar la información de paginado entre vistas. La idea es la siguiente:

Supongamos que estoy en una típica vista index que muestra una tabla de registros paginada y que me encuentro en la página "p" de la misma.

Entonces voy y pulso un botón o enlace para editar un registro cualquiera de esa página. Al terminar de editar ¿a dónde vuelvo? En principio a la vista de index (si lo he especificado así), pero ¿a qué página?.

Si no especifico la página de origen normalmente volveré a la página 1 y no a la "p" que es en la que estaba, lo cual es un engorro, por muchas razones que te puedes suponer.

El componente paging que he escrito básicamente permite a la acción index "acordarse" de qué página estaba mostrando la última vez.

Instrucciones de uso

1. Copiar el código al archivo /app/controllers/components/paging.php
2. En el controller, añadir Paging a la lista de components
3. En la acción en que queremos usarlo, llamar al método $this->Paging->manage()
4. Opcionalmente puedes pasarle el nombre del modelo al que debe referirse la información de paginación

Por si no queda claro, la cosa es así

class MiControlador extends AppController {

var $components = array ('Paging');

function index () {
   $this->Paging->manage();
}

}

Cómo funciona

Básicamente, el componente comprueba si hay información de paginación almacenada en la sesión y la lee si es así.

Seguidamente, comprueba si hay información en la URL. Esta información tiene prioridad porque Controller::paginate() la utiliza si está disponible para definir los límites de la búsqueda.

Finalmente, el componente combina la información procedente de todas las fuentes para determinar el nuevo contenido de la variable Controller::paginate y también lo guarda en la sesión.

La información se guarda de forma específica para cada controlador.

El código

He puesto el código en CakeBin, pero como no sé si durará, intento copiarlo aquí:

<?php
/**
 *  Component to manage paging info between reloads
 *
 *  Created by Fran Iglesias on 2007-06-17.
 *  @version: 0.1
 *  Copyright (c) 2007 Fran Iglesias. All rights reserved.
 **/

/**
 * Usage:
 * 
 * 1. Put paging.php into your /app/controllers/components folder
 * 2. Add 'Paging' to your controller::components array
 * 3. Call $this->Paging->manage () into the action that retrieves data using paginate()
 */

class PagingComponent extends Object {
 var $components = array ('Session');
 var $controller = false;
 
 function startup (&$controller) {
  $this->controller = $controller;
 }
 
 /**
  * Manage pagination data retrieving and storing into session as needed,
  * Paging info passed via URL arguments takes precedence over session data
  *
  * @params string $forModel Specify a model name to manages its paging data
  * @return void
  * @author Frankie
  **/
 function manage ($forModel = null) {
  // Determines a model name to work
  if (in_array ($forModel, $this->controller->modelNames)) {
   $model = $forModel;
  } else {
   $model = $this->controller->modelNames[0];
  }
  // Check if there is paging info in the Session and read it
  $sessionVarName = $this->controller->name . '_paging_info';
  if ($this->Session->check ($sessionVarName)) {
   $pagingInfoFromSession = $this->Session->read ($sessionVarName);
  } else {
   $pagingInfoFromSession = array ();
  }
  // Check if there is paging info in passedArgs and build a paginate-like record with it
  $pagingArgs = $this->_getPagingFromArgs ();
  // Set paging info based on paging info from session and form arguments
  if (isset ($pagingInfoFromSession[$model])) {
   $paging = am($pagingInfoFromSession[$model], $pagingArgs);
  } else {
   $paging = $pagingArgs;
  }
  // Pass the new paging info to controller->paginate variable
  if (isset ($this->controller->paginate[$model])) {
   $this->controller->paginate[$model] = am($this->controller->paginate[$model], $paging);
  } else {
   $this->controller->paginate[$model] = am ($this->controller->paginate, $paging);
  }
  // Store new paging info into Session
  $this->Session->write ($sessionVarName, $this->controller->paginate);
  return true;
 }
 
 /**
  * Helper to read pagination info from URl if there is any
  *
  * @return void
  * @author Frankie
  **/
 
 function _getPagingFromArgs () {
  if (!isset ($this->controller->passedArgs)) {
   return array ();
  }
  $paginate = array ();
  if (isset ($this->controller->passedArgs['page'])) {
   $paginate['page'] = $this->controller->passedArgs['page'];
  }
  if (isset ($this->controller->passedArgs['limit'])) {
   $paginate['limit'] = $this->controller->passedArgs['limit'];
  }
  if (isset ($this->controller->passedArgs['sort']) && isset ($this->controller->passedArgs['direction'])) {
   $paginate['order'][$this->controller->passedArgs['sort']] = $this->controller->passedArgs['direction'];
  }
  return $paginate; 
 }
}

?>

Anatomía de una acción

Uno de los conceptos básicos que hay que entender cuando se empieza con CakePHP es el de cómo "funcionan" las acciones en los controladores. Como novato que soy tropiezo con esta piedra varias veces al día, por lo que me siento muy autorizado a exponer algunas ideas sobre el particular.

Cuando pedimos una URL de una aplicación CakePHP, en el clásico formato /controlador/acción, es el controlador el que la recibe, prepara lo necesario y ejecuta la acción.

La fase de preparación consiste en "averiguar" lo que ha pasado ahí fuera, en el mundo de los usuarios, y poner esa información a disposición de la acción de una manera estructurada.

Básicamente, lo que el controlador mira son dos cosas:

• Los datos que hayan sido recogidos en un formulario y enviados mediante POST (normalmente). Los encontrarás en Controller::data
• Los argumentos que hayan sido pasados por la URL. Los encontrarás en el array Controllers::passedArgs

Aparte de estos datos básicos, puedes encontrar mucha información importante en Controller::params, o detalles sobre la petición si usas RequestHandler. Pero para lo básico vamos a quedarnos sólo con los argumentos y los datos de formulario.

Datos de formulario

Si el usuario ha rellenado un formulario y apretado el botón Submit, Controller::data será poblado por los datos de Post. Nuestra acción tendrá entonces que detectar esta situación y abrir dos "modos" de trabajo según haya datos para procesar el formulario o no.

Habitualmente, si no hay datos la acción tendrá que mostrar el formulario adecuado.

Lo anterior establece algo así como dos "modos" de la acción: uno de postproceso de formulario y otro de preparación del mismo.

Argumentos pasados

Dentro de cada uno de los modos anteriores, los argumentos pasados por URL nos sirven para modular el comportamiento concreto de la acción. Por ejemplo, en el típico caso de una acción edit, normalmente pasamos un argumento con el id del registro que queremos editar. Por lo tanto, nuestra lógica será:

• Si tenemos datos del formulario se trata de una actualización y hay que tratar de guardar los datos nuevos en el registro con el id indicado.
  
• Si no tenemos datos del formulario, se trata de cargar el registro cuyo id se nos ha pasado y poner un formulario ya cubierto con esos datos para que el usuario los modifique.

CakePHP es lo bastante inteligente como para no obligarnos a leer el array Controller::passedArgs cuando ciertos argumentos sean específicos para la acción. Es el típico caso del id en acciones tipo edit o view.

Lo que hace es mapear estos argumentos de la URL en los argumentos que hayamos definido para nuestra acción. En cierto modo, esto nos define la estructura de la URL. Por ejemplo:

function accion ($id, $title= false)

espera una URL de la forma:

/controlador/accion/12/ejemplo
/controlador/accion/15

El argumento id sería obligatorio y title opcional.

Los argumentos que no sean específicos podemos leerlos en Controller::passedArgs, que es un alias a Controller::params[pass] (y a Controller::passed_Args, por cierto).

Una url con argumentos tiene la forma

/controller/accion/12/pagina:5/ordenar:id/

En este caso 12, seria pasado como argumento a la acción "accion", mientras que encontraríamos pagina y ordenar en el array Controller::passedArgs.

Por supuesto, hay muchas variedades de acciones. No todas ellas tienen que lidiar con formularios, algunas solo van a presentar un contenido estático, etc. Pero básicamente todas siguen un mismo esquema:

• Compobar si hay información procedente de ciertas fuentes (argumentos, formulario)
• Si hay información, ver qué tengo que hacer con ella y presentarla al usuario
  
• Si no hay información, presentar una vista que la solicite al usuario

Entendiendo las relaciones en CakePHP

Un artículo de Josh Benner muy clarito, aunque en inglés, sobre las asociaciones en CakePHP.

Una nota breve sobre getid3

Pues nada, que estoy recopilando material y referencias para montar mi primera aplicación real sobre CakePHP (o al menos parte de ella).

Quiero hacer un plugin para ofrecer un servicio de podcast. He estado buscando la forma de poder leer información de los archivos mp3, m4a y otros candidatos con PHP y me he encontrado esta clase: getid3.

Lo bueno es que reconoce muchos tipos de archivos, por lo que será capaz sacar la información necesaria para crear el feed del podcast.

Lo malo (o lo bueno según se mire) es que saca decenas de datos, lo que hace un poco complicado sacarle provecho.

Me imagino que trataré de hacer algún tipo de wrapper que simplifique la interacción con la clase y tendré que ver la manera de "acoplarla" en Cake.

Respecto al plugin en sí, a ver si me pongo con ello en los próximos días.

Buscando página para un registro nuevo

Llevo un rato buscando una estrategia para que al añadir un registro la tabla (paginada) donde se presentan no sólo se actulice, sino que muestre el nuevo registro para proporcionar feedback adecuado al usuario.

Se me ha ocurrido una solución un poco bruta, que por supuesto necesita ser pulida para mantener la consistencia de la aplicación web. Por lo menos funciona.

Simplemente se trata de reordenar la tabla por id descendente justo después de Model::save mediante la especificación de la variable Controller::paginate.

array ('order' => 'modelo.id', 'page' => '1')

Claro que hay que tener muchas cosas a tener en cuenta. Por un lado están otros valores anteriores de la variable. Esto es algo que tal vez se pueda solucionar mediante un array_merge, tal que así:

$this->paginate = array_merge ($this->paginate, array ('order' => 'modelo.id', 'page' => '1'))

En realidad esto no se conserva entre recargas de página, por lo que sería adecuado guardar esta información en la sesión y recuperarla antes de generar la vista..

Ejercicio para el lector

Esto me lleva a pensar que se podría crear un método beforeFilter o beforeRender (no sé exactamente) que se encargase de lidiar con el tema de conservar las páginas actuales de las vistas index, tener en cuenta algunas opciones por defecto para las aplicaciones (como por ejemplo que hubiese una preferencia de usuario o de la aplicación sobre la cantidad de items que se muestran o la ordenación por defecto o lo que sea), y esas cosas. Más o menos tendría que lidiar con:

• Opciones por defecto "hardcoded"
• Opciones por defecto de la aplicación, tal vez fijadas en un archivo de configuración u otro almacenamiento.
• Opciones del perfil de usuario, si procede.
• Opciones de la sesión de usuario, si procede.
• Información de página pasada en la sesión, teniendo en cuenta a qué Modelo hace referencia.
  

Si es lo suficientemente generalizable, se podría hacer un componente.

Más cornás da el Ajax (¿o era el hambre...?) (Muy actualizado)

Llevo todo el día dándome cabezazos contra una tontería que al final no tiene que ver con Ajax (o eso creo).

Resulta que en mi experimento de formulario + tabla, el formulario se empeñaba en mantener lo escrito con una constancia digna de mayor causa. Eso no es malo, lo malo es que se mantenía incluso cuando no lo necesitaba, o sea, cuando los datos habían sido enviados, validados y guardados. Se supone que $('formulario').reset() (una función de prototype) tendría que hacer el trabajo. Pero, ¡que si quieres arroz Catalina!

Así que me he pasado horas intentando entender ¿por qué? sin que haya conseguido una respuesta clarificadora. En algún lugar encontré una referencia a la necesidad de asegurarse de mantener el contenido tecleado en un formulario incluso entre refrescos de páginas. Es de agradecer que Cake? Ajax? (no lo sé todavía?) lo mantengan, pero no había conseguido vaciar los campos del formulario recorriendo a Ajax o Javascript.

[... Mala solución borrada por el autor ...]

¡Borra Controller::data, idiota!

La solución final viene por vía de Cake y gracias a Geoff Ford en el grupo Google de CakePHP, así que ¡gracias Geoff!

La solución, por supuesto, es trivial:

Cuando enviamos un formulario cubierto pulsando el botón Submit correspondiente, CakePHP puebla la variable Controller::data (el $this->data que le pasamos a Model::save) con los datos procedentes de POST. Esto es lo normal.

Pero resulta que yo estoy pidiendo que se vuelva a mostrar el formulario justo en el mismo ciclo que cuando salvamos los datos, por lo tanto, Controller::data sigue llevando los datos de POST y, en consecuencia, cuando se dibuja la vista ahí siguen los datos.

Tan sólo hay que vaciar Controller::data para que no se pase ningún valor al formulario. Tan simple como eso.

Dos cosas más

1. Controller::data es el mecanismo que usa Cake para que no se pierdan los datos existentes en el formulario si éstos no validan y tiene que redibujar el formulario en el mismo ciclo.
2. Hay persistencia de los datos en el formulario incluso recargando la página. Eso es muy bueno.
3. En el planteamiento "típico" en que el formulario de añadir datos se retira de la vista al enviarlo, los datos del Post se pierden una vez utilizados. Al volver a llamar al formulario, este se muestra vacío... porque estamos en otro ciclo.
   
4. Ajax no tenía nada que ver en esto.

Organizando las vistas para Ajax

Siguiendo con el ejercicio anterior he descubierto unas cuantas cosas más. Por ejemplo, los problemas que supone la validación CakePHP interaccionando con un planteamiento "ajaxiano" de la vista.

La solución que he encontrado es la siguiente:

De lo general a lo particular

Lo primero sería hacer un croquis general de lo que voy a necesitar poner en la vista. En mi caso, por ejemplo, un título, un formulario y una tabla. Hay que tener en cuenta las partes que se van a tener que actualizar solas, en un momento dado, o las que habrá que actualizar globalmente.

Lo mejor parece ser descomponer la vista en partes, valorando si necesitan ser incluidas en una div, y crear elements para generar cada una de ellas. De este modo dispondremos de piezas de construcción para generar las vistas definitivas. Procura ponerles nombres bien descriptivos a los elementos.

Preparando las vistas

Con los elements ya preparados generamos las vistas que nos haga falta, aprovechando el método This::Element ('elemento').

La idea es crear tantas vistas como podamos necesitar. Intentaré explicarlo:

Normalmente la primera petición para cierta página será una petición normal, sin Ajax ni cosas raras. Entonces tendremos que tener una vista que muestre todo lo necesario. En mi ejemplo, una vista que muestre el título, el formulario y la tabla. Esa podría ser index.ctp, si mi acción es index.

Como mi tabla tiene enlaces Ajax para ordenar los resultados y éstos piden que se actualice sólo la div que contiene la tabla, necesitaré una vista que sólo muestre la tabla. La llamaré tabla.ctp.

El formulario envía una petición Ajax al servidor para añadir entradas sin actualizar toda la página. El resultado del formulario debería actualizar la tabla, pero puede ocurrir que tenga que actualizarse también el propio formulario, por ejemplo si hay errores en la validación en CakePHP. En este caso, podría crear una nueva plantilla, aunque veo que index.ctp me sirve para esto sin tener que duplicar el trabajo.

También podría preparar una vista específica para cuando se solicita la acción con una petición no Ajax.

Y luego están las vistas para las demás acciones que programemos, por supuesto. En ellas hay que considerar los mismos aspectos acerca de si es posible que sean solicitadas a través de Ajax y qué contenido deben proporcionar.

En el controlador

Ahora bien, en el controlador tenemos que determinar qué tipo de petición está entrando y qué contenido tenemos que devolver. Tenemos dos armas:

RequestHandler->isAjax() es el método que nos permite saber si la petición es Ajax y hacer cosas diferentes en cada caso.

Controller::Render ('vista') nos permite especificar una vista concreta con la que mostrar el resultado de la acción.

Usándolas en combinación, podemos hacer que nuestra acción sepa qué contenido debe entregar a la petición Ajax (o de cualquier otro tipo) y mediante qué vista.

No te olvides de generar el contenido

Eso sí, hay que tener presente qué contenido es el que vamos a actualizar, porque las cosas pueden ser un poco diferentes que en el uso normal.

Por ejemplo, en este caso de la combinación de formulario de entrada más tabla de datos, he decidido que al añadir una entrada hay que actualizar la vista que contiene tanto el formulario como la tabla. Por lo tanto, la acción add, cuando es llamada mediante Ajax, tiene que lidiar no sólo con tomar los datos y hacer lo que haga falta con ellos, sino también obtener el listado para mostrar como si fuera una acción index y enviárselos a la vista index, en vez de a la vista por defecto (add).

Alternativamente, la versión "no Ajax" de la acción podría usar una vista diferente y necesitar información diferente.

Otros beneficios

Algunas de las ideas expuestas aquí, aparte de ser útiles e incluso necesarias para integrar Ajax, tienen algunos beneficios colaterales.

Al descomponer una vista, o una familia de vistas, en elementos reutilizables es más fácil, por ejemplo tener un único formulario para añadir y editar. Estamos siguiendo eso que llaman la metodología DRY (Don't Repeat Yourself).

Otro beneficio es que si una parte de una vista es relativamente complicada, al empaquetarla en un element podemos mantener controlada esa complejidad.

Ajax... qué lío

Acabo de hacer algo intencionadamente con Ajax. Quiero decir que no es como el PaginatorHelper, que te lo hace todo. O sea: que me he planteado un pequeño ejercicio con Ajax y me ha salido.

Eso sí, con cierto esfuerzo. Voy a intentar poner aqui las ideas que han ido surgiendo, aunque no creo que ponga código, al menos de momento. Entre otras cosas, porque no está conseguido todo lo necesario para considerarlo completo.

El ejercicio

Consistía en combinar un formulario para añadir entradas en un tabla (citas o frases célebres y su autor) con la propia tabla. Al escribir una nueva frase en el formulario y pulsar el botón de enviar tendría que actualizarse la tabla.

La función de las técnicas Ajax aquí es enviar los datos del formulario al servidor, elicitar la acción add correspondiente en el controlador y recoger el nuevo contenido de la tabla

Suena bien. Hacerlo tiene truco.

Lo primero es planificar un poco la página que se va a generar y ver cuántas zonas (div) necesitamos establecer. En principio, aquí debería llegarnos con una para el formulario y otra para la tabla.

Luego habría que tener vistas para generar el contenido de cada una de estas partes, más una vista que las combine todas. Las vistas de partes serían para actualizar cada div cuando toque, la vista combinada sería para usar la primera vez.

Esta es una parte que no tengo del todo clara cómo organizar. El tutorial que he seguido está basado en la versión 1.1 de CakePHP y algunas cosas no son exactamente iguales.

Por una parte, es posible utilizar Controller::render($vista, 'ajax') para explicitar la vista que queremos mostrar usando el modo "Ajax". Combinando eso con una consulta Controller::ResquestHandler->isAjax () para ver si la petición nos la hace Ajax, podemos hacer que un mismo controlador extraiga los datos necesarios y decida si debe devolver la vista "normal" o la actualización "ajax". No sé si me explico.

Ejemplo. La acción index podría tener una view asociada, llamada también index, que genere tanto el formulario como la tabla de datos (¿me sigues?) y que usaría ante una petición normal. Por otro lado, podríamos escribir una view para actualizar sólo la parte de la tabla y que se usaría para atender una petición Ajax.

Nos quedaría algo así:

function index () {  
   $data = $this->Paginate ();
   $this->set ('frases', $data);
   if ($this->RequestHandler->isAjax()) {
 $this->render ('tabla');
   }
}

No sé si se aprecia bien. El último if nos permite indicar una view específica que genera el contenido que queremos devolver.

Recuerda que tenemos que usar el component RequestHandler y llamar a su método startup en beforeFilter para que funcionen bien estas peticiones Ajax (de otro modo, se empeña en devolverlas con layout y esto es un despiporre).

Las acciones implicadas tienen que saber qué actualizan

Esto me hizo rascarme la cabeza un montón hasta que cai de la burra. Resulta que en mi ejercicio todo funcionaba bien hasta que añadía una entrada a la tabla y trataba de ordenar ésta. Bueno, pues se añadían más entradas, y se generaba un error del layout y no salía la tabla.

Bien. Resulta que el boton de enviar el formulario llamaba a la acción add del controlador. Correcto. Pero la acción add, aparte de añadir el nuevo registro, tiene que volver a pedir los datos para mostrar la tabla. Eso por un lado.

(Nota: lo que no he mirado es si sería más adecuado y económico llamar a la acción index...).

Por otro lado, hay que controlar que la acción add dibuje la vista que genera el contenido de la tabla (en el ejemplo de arriba, es tabla.ctp, en lugar de su add.ctp que dibujaría normalmente), al menos cuando es llamada por Ajax. Si no es llamada por Ajax debería dibujar su vista normal, o hacer algo que le explique al usuario qué pasa o qué puede hacer.

Y, por último...

Más cosillas a las que prestar atención

Al generar enlaces o botones que hagan llamadas Ajax hay que asegurarse de que llaman a la acción adecuada del controlador adecuado. Es posible que tengas que especificar explícitamente la acción y no dejar que sea CakePHP el encargado.

Esto es así porque si dibujamos una vista desde una acción que no es la "propia" (como en el apartado anterior que dibujábamos tabla desde index, pero también desde add, Cake interpreta que esos enlaces se dirigen a la acción "generadora", si no hemos indicado otra.

En mi ejemplo, debo especificar en las opciones del paginador de la tabla, que la acción a la que llaman los enlaces Ajax que ordenan la tabla ha de ser siempre index.

Ya puestos, vamos con Ajax

Un artículo recopila enlaces sobre Ajax y CakePHP. Ya contaré cómo me va.

Cache de elementos

Un tutorial de Tane Piper sobre cache de elementos. Hasta yo lo he entendido. Este otro también explica el uso de la clase cache, para cacheado específico que quieras hacer.

(Lo que no acabo de ver que funcione es el cache de vistas del que habla el manual.)

La cosa es sencilla: cuando quieres incluir un elemento y cachearlo para no volver a pedir los datos, añade un array con la clave 'cache' y el tiempo en segundos (o en un formato apto para strtotime).

echo $this->element ('menu', array ('cache' => '1 day'));

Eso sí, para asegurarte de que el elemento muestra la información actualizada, tendrías que borrar esta cache cuando se haga alguna modificación de los datos implicados.

El artículo propone este método en el afterSave del modelo, implicado (aunque también debería ir en el afterDelete, creo:

@unlink (CACHE.'views'.DS.'element__nombre_del_elemento');

El ahorro de peticiones a la base de datos puede ser brutal.

Una de Axaj: haciendo que los Ajax Request no recarguen todo

CakePHP incluye un Helper para Ajax y cosas como el PaginatorHelper hacen uso de Ajax.

Yo no es que tenga mucha idea del asunto, pero al hacer mis primeros experimentos de paginación me encontré con el problema de que en vez de actualizarse los listados, se me actualizaba toda la página en el espacio del listado.

La solución es básicamente decirle al controlador que cuando reciba una petición desde Ajax que genera la vista teniendo eso en cuenta. Después de reinventar la rueda varias veces, resulta que lo único que hay que hacer es añadir esto a los controladores que tengan vistas que usan Ajax:

    var $components = array ('RequestHandler');
   
    function beforeFilter () {
        $this->RequestHandler->startup ($this);
    }

Y, si aún así, necesitas controlar peticiones Ajax en algún punto del controlador o en alguna acción, no tienes más que hacer un simple:

if ($this->RequestHandler->isAjax ()) {
  // Es Ajax
} else {
 // Es otra cosa
}

Crear un feed RSS

Me llevó todo el domingo intentar desentrañar el pequeño misterio de generar feeds RSS con CakePHP a partir de este artículo de Nate, que lo explica, pero no demasiado.

La gracia es que acabé consiguiéndolo a medias: el feed salía pero no podía controlarlo a mi gusto (¿dónde c... se pone el channel?). Más tarde (a punto de ponerme a dormir) me di cuenta de que había pasado por alto ver cómo funcionaba la plantilla por defecto para rss, la cual tendría todas las respuestas. Efectivamente. Lo malo es que, acto seguido, voy y me encuentro este breve tutorial de Jiri Kupiainen donde explica todo el proceso. :-(

Ocurrió lo de siempre, te pegas contra la documentación, el código, el API... descubres como se hace algo, y una vez que lo tienes aparecen como por encanto artículos en Google que "no estaban ayer". Lo bueno, es que el aprendizaje por la vía dura suele ser bastante eficaz.

En fin, el caso es que basándome en ambas fuentes, he aquí mi propio tutorial para generar feeds rss... ¡a partir de cualquier modelo!

Paso 1: preparar Cake

Básicamente hay que decirle a CakePHP que queremos parsear url con extensiones, de la forma: /controller/action.rss. Esto es así porque la versión 1.2 de CakePHP puede seleccionar al vuelo diferentes vistas en función de la extensión que le pasemos. Por lo tanto, en un paso posterior crearemos una vista específica para el feed y la pondremos en el sitio adecuado para que la use Cake.

En tu /app/config/routes.php tienes que añadir:

Router::parseExtensions('rss');

Esto le indica a Cake que si se encuentra una URL con la extensión 'rss' busque las vistas en la carpeta /vistas/modelos/rss.

Podemos no especificar ninguna extensión, para que parsee cualquiera, o bien dar una lista limitada de ellas 'rss', 'xml'...

Paso 2: cosas para hacer en el Controller

Hay varias, así que vayamos por partes.

Lo primero es habilitar el uso del componente RequestHandler en el controlador. Aparte de para este tema de los feeds es útil siempre que necesites obtener información sobre la petición que está recibiendo el controlador. Lo segundo es indicar que quieres utilizar el RSSHelper, claro.

var $components = array('RequestHandler');
var $helpers = array ('RSSHelper');

Una cosa opcional: El componente HandleRequest te permite comprobar si el usuario está pidiendo un RSS (u otra cosa) y actuar en consecuencia. Por ejemplo, si es para el feed obtener sólo los últimos 15 items que cumplan ciertas condiciones y si no obtener todos. En cualquier caso, usarías:

if ($this->RequestHandler->prefers('rss')) {
// Cosas para hacer si es rss
} else {
// Cosas para hacer si no lo es
}

Lo segundo es enviarle los datos a la vista del feed (que aún no hemos creado, ¡ojo!). Lo puedes hacer así:

Configure::write('debug', '0');
$data = $this->Paginate ();
$this->set('channel', array ('title' => 'Ejemplo',
  'link' => 'http://localhost:8888/micake/',
  'description' => 'Frases y citas célebres para que las puedas leer'
));
$this->set ('frases', $data);

Lo explico un poco:

La primera línea es para desactivar el Debug (en el caso de que lo tengas distinto de 0, como ocurre en un entorno de pruebas o de desarrollo). Con Debug, Cake añade cosas a la salida generada y los feeds no validarían de ninguna forma aunque estuviesen bien construidos. Opcionalmente puedes poner un if para controlar si es necesario hacerlo o no.

La segunda línea es para recabar los datos de la manera habitual.

La tercera línea ajusta los valores para el channel. El layout por defecto para feeds rss espera que definas una variable $channel como un array con claves que serán los elementos del channel (como title, link, description y los demás). Si no la defines, CakePHP se busca la vida para poner algunos.

La cuarta línea pasa el array de datos que serán los ítems del modelo. En este caso, la variable es $frases, pero se supone que esto ya sabías hacerlo. Aquí no vamos a hacer nada más.

Paso 3: preparando la vista, o cómo pasar tu modelo al feed

La vista tienes que ponerla en /views/nombre_del_modelo_plural/rss/nombre_de_la_action.ctp

Y el contenido tiene que ser más o menos así:

$items = $rss->items($frases, 'convertirRSS');

echo $items; 
function convertirRSS($data) {
  return array(
    'title' => $data['Frasecita']['frasecita'],
    'link'  => array('action' => 'view', $data['Frasecita']['id']),
    'guid'  => array('action' => 'view', $data['Frasecita']['id']),
    'description' => $data['Frasecita']['frasecita'],
    'author' => $data['Frasecita']['autor'],
    'pubDate' => $data['Frasecita']['usado']
 );
}

La explicación es como sigue:

Usamos el método rssHelper::items () para convertir el array de datos en elementos items del feed. Para convertir los campos del modelo en los items con sus correspondientes subelementos, usamos una función callback que, en este caso, hemos llamado convertirRSS.

La función tiene que tomar un array asociativo simple, cuyas claves son los nombres de los campos del modelo (y cuyos valores serán los de los diferentes registros, pero de eso se encarga el método items).

La función, por otra parte, tiene que devolver un array cuyas claves sean elementos válidos de item. Tarea nuestra es decidir cómo movemos los datos entre el modelo y los elementos del item.

Algunas observaciones interesantes en el ejemplo. Link y Guid piden url y entienden que se las pasemos como arrays, tal como se explica en el artículo sobre el router.

PubDate, admite campos de tiempo y los prepara en el formato adecuado.

Aparte, mirando el API, creo que hay soporte específico para enclosures, o sea, que el camino para feeds de podcasts está abierto. Aún no lo he investigado.

Paso 4: Ya está, ¿cómo suscribirse?

Pues sí, el feed ya está listo para servir. La URL para suscribirse sería:

http://exemple.com/controller/action.rss

Sustituye lo que haga falta. Supongo que se podrían hacer rutas para que ciertas url se sirvan como feeds.

El router de la 1.2 (atualizado): indicar URL como arrays

He estado leyendo un artículo de Andy Dawson sobre el router de CakePHP 1.2.

El router, entre otras cosas, es el que se encarga de gestionar las URL de Cake, permitiéndole intrepretar sus características /controlador/accion/[parametros]. Pero también, desde la versión 1.2, se puede aprovechar para generar esas mismas URL desde el código de manera inteligente, sin tener que pensar dónde estoy exactamente.

Para eso usamos un array, que en su forma completamente desarrollada viene siendo así:

$url = array (
 CAKE_ADMIN=>false,
 'plugin'=>false,
 'controller'=>'Post',
 'action'=>'view',
)

Pero que nosotros podríamos usar así:

$url = array {
 'action' = 'edit',
 12
}

Que sería el equivalente de

$url = '/controller/edit/12';

Y que podríamos emplear en un $html->link (), por ejemplo, o en otros métodos que necesiten una URL.


Ventajas

La principal, que hacemos que sea Cake quien se encargue de formar correctamente las URL.

Por otro lado, el código se hace más transportable y genérico. Ideal para helpers.

En consecuencia, he empezado a migrar mis URL internas al formato array.

Ojo con requestAction

Por lo que veo, requestAction no soporta las url en forma de array. Así no me funcionan a mí los elements.

¿Lo quiere por id o por nombre? (actualizado)

Este pequeño trozo de código permite que una acción pueda localizar un mismo modelo de dos maneras distintas, gracias a los métodos mágicos de búsqueda de Cake (Model::findBy...).

if (is_numeric ($id)) {
  // Buscar por ID
  $this->MenuBar->id = $id;
  $resultado = $this->MenuBar->Find ();
  } else {
  $resultado = $this->MenuBar->FindByMenuBar ($id);
  }

Explaneishon

Capturamos el parámetro id de una URL típica como /controller/action/parametro.
Vemos si es de tipo numérico, en cuyo caso debería ser un ID.
Y si no, será que es el nombre.

Explaneishon 2

Los métodos mágicos Model::findByCampo () nos sirven para hacer búsquedas de modelos por un campo específico (Campo) del modelo. Dispones de un método findBy por cada campo que tenga el modelo.

Efecto de volumen, con CSS, muchos colores y un sólo archivo gráfico (actualizado)

Leyendo por ahí, sobre los usos de la transparencia del formato PNG, se me ocurrió probar una técnica la mar de curiosa para dar sensación de volumen en un elemento HTML, usando sólo CSS y un único archivo gráfico.

El archivo gráfico ha de ser un gradiente color frontal a transparente.

Como éste:

A simple vista no se aprecia gran cosa, pero te cuento. Es un PNG con fondo transparente y dos capas de gradiente. Una de negro a transparente y otra de blanco a transparente. (No soy capaz de ponerle un fondo aquí en el blogger para que se vea.) Las dimensiones son 48 px x 48 px. Puedes hacerlo del tamaño que quieras. La transparencia ha de ser por canal alfa.

Esto es un ejemplo de cómo quedaría la cosa:

Ahora, cuando quieras que un elemento use este fondo, creas una regla CSS más o menos así:

selector {
background: #7CC1F6 url(relieve.png) repeat-x center left;
}

Espero que no te tenga que explicar lo que es el selector. Pero explico la regla:

En background asignamos, por este orden:

• Color de fondo del elemento.
• Imagen de fondo (la que hemos preparado)
• Repetición en el eje x (o como lo tengamos)
• Alineación al centro y a la izquierda (o como queramos)
  

¿Qué es lo que ocurre? La imagen se superpone al fondo del elemento, y como lleva transparencia por canal alfa, el resultado es que se mezcla con el color del fondo y conseguimos ese efecto de relieve.

Se puede hacer lo mismo para conseguir "marcas de agua".

Jugando con la opacidad de las capas en el programa de edición podremos matizar más o menos el efecto.

Una de recursos gráficos para la web

Un par de direcciones de las que he visto para sacar recursos como iconos, spinners y cosas de esas.

Ajax Activity Indicators en mentalized.net, es una pequeña colección de spinners y barras de progreso. Lo mejor es que puedes probarlos con un fondo de color, así averiguas los que son transparentes.

FanFanFan Silk Icons tiene una colección de 700 iconos bastante chulos para aplicaciones web. No los estoy usando todavía, pero creo que los voy a "adoptar". También tiene otra colección llamada mini, de 144 bastante bonita.

A ver si encuentro algo más.

Avances sorprendentes

He tenido un día bastante bueno con Cake. Los avances empiezan a ser significativos y algunas cosas van estando más claras.

Los cambios del behavior (antes helper, antes behavior) joinTable me han permitido desarrollar un poco más los conceptos MVC y los fat models. Voy descargando al controlador de trabajo y se lo paso al modelo. Es muy interesante, por ejemplo, cómo se programa la duplicación de registros, o la creacion de un modelo desde otro.

Por otro lado, mis vistas piden muchos helpers. :-)

El helper simpleTable (que aún no he publicado) me ha aportado mucho en trabajar con arrays para pasar parámetros complejos y también para conocer los entresijos del HtmlHelper.

Incluso he trabajado con la paginación y ya tengo en mente preparar un helper para generar navegadores de listados. Eso me ha llevado a utilizar la sesión para almacenar datos. Tengo que ver algunas cosas más sobre eso, porque hay un par de aspectos del paginator helper que me gustaría dominar mejor.

Por otro lado, he empezado a salir del nicho "una sola tabla cada vez" y me voy moviendo en el terreno de las asociaciones. Por ejemplo, en el modelo Recurso, he incluido un callBack beforeSave con el que guardar Categorías nuevas cuando al usuario no le llegan las que le ofrece el menú desplegable.

Otro aspecto que he comenzado a mirar es el de la maquetación. Creo que empiezo a entender como funciona el tema de los layouts y su relación con las vistas y, sobre todo, los elements. He estado jugando con las css y un layout para ver qué tal se presenta Cake. Y la verdad es que la pinta es buena. Una de las grandes ventajas es que se puede diseñar la presentación por un lado e integrar la aplicación en el diseño, porque los layouts no son otra cosa que páginas (X)HTML.

¡Hasta me he pasado a los PNG para iconcitos y todo!

Sobre esto de la presentación hay un tema que no tengo del todo claro, y es cómo trabajar cuando quiero que una acción no vaya a la vista principal. Por ejemplo, si un Element tiene un enlace que hace que se actualice. ¿Ajax? ¡Demasiado pronto para mí, creo! Pero ¡quién sabe!.

Quedan aún muchas cosas que aprende, eso sí. Sin embargo, parece que he pasado el punto de "no retorno".

Algo que me he dado cuenta es que CakePHP es un framework que deja mucho campo al PHP. Me explico. Muchos frameworks son como lenguajes en sí mismos, con centenares de funciones que hacen de todo. Sin embargo, Cake proporciona más bien una base de trabajo y llega hasta el límite donde no quieres que hagan las cosas por ti. Creo que es bueno que sus desarrolladores no quieran extender demasiado el API.

Es decir. Te descarga del tema del movimiento de datos, creación de formularios, gestión de "infraestructura" y todas esas cosas de rutina que hay que hacer. Sin embargo, no intenta tomar decisiones por el programador. No sé si me explico del todo.

Se nota más en las vistas. Aunque es cierto que el FormHelper hace muchísimo, la verdad es que las responsabilidad de la vista te la deja a ti, no hay funciones o helpers para cosas muy específicas. Los que hay tienen bastante fundamento y los resultados son muy buenos. Pero a la hora de presentar datos, por ejemplo, te deja las manos libres. Al principio puede parecer un poco jorobado, pero ahí entra tu habilidad para decidir cuando necesitas un helper y escribirlo.

¿Cómo se pasan parámetros? parte 2

Las URL de CakePHP también permiten pasar parámetros "con nombre". Tienen esta forma.

/controlador/accion/param1:valor1/param2:valor2

¿Bonito verdad? Se recogen en la propiedad (array) Controller:params[pass], los nombres del parámetro como claves y los valores como, bueno, valores.

¿Una forma de pasar información de paginación?

Acabo de probar una forma de pasar información de paginación desde una vista de resultados paginada a través de las sesión, para poder crear URL de regreso adecuadas en las vistas de edición o detalle de los modelos, a fin de que el usuario pueda volver a la página correcta y no se pierda por el camino, el pobre.

De momento, es simple de más, pero el esquema viene siendo el siguiente:

• En el controlador añadir Session al array de components y al de Helpers.
  
• En el controlador, capturar la información de página que debería venir en $this->params['pass']['page'] y guardar en la sesión, por ejemplo, con $this->session->write ('pagina', $this->params['pass']['page'])
• En la vista, leer el valor 'pagina' de la sesión y usarlo para construir la url de regreso. Por ejemplo: array ('action' => 'index', 'page' => $session->read ('pagina')).

Posibles fallos: hay que controlar que se guarde la variable de modo que pueda identificar qué controlador la ha guardado, así, podría llevar la pista de diferentes paginaciones.

También habría que poder usar el valor de la sesión si no se ha proporcionado otro por la URL en las vistas de index, aunque esto ya no lo tengo tan claro como hacerlo.

Otra cosa chula sería calcular en qué página tendría que verse un registro concreto, por ejemplo uno recién añadido, sobre todo si el nuevo registro provoca que se añada una página.

Luego lo pienso.

FlatTable Behavior, unifica los resultados de un modelo y sus belongsTo

Bueno, de Behavior a Helper y, de nuevo, Behavior.

Este Behavior sirve básicamente para fusionar los resultados de asociaciones belongsTo de un modelo para que "parezca" que son parte del mismo modelo.

La idea es poder pasar esos resultados a la vista y generar una tabla simple (tengo un helper para eso). Un ejemplo lo aclara:

Tengo un modelo Recurso, que guarda información de una serie de aparatos disponibles en el servicio de Nuevas Tecnologías del colegio en que trabajo. Los Recursos se organizan en Categorías, de modo que cada Recurso pertenece (belongsTo) a una Categoría.

Lógicamente los usuarios querrían ven la lista de recursos con su Categoría (no su id), por lo que a la hora de generar la vista tendría que combinar los datos. La misión de este Behavior es proporcionarme un método general para hacerlo que no me complique mucho las vistas.

El Behavior me permite, entonces, obtener la lista de Recursos y fundir los campos de Categoria de modo que se presenten en una tabla simple.

Posibles mejoras

El behavior tendría que comprobar algunos puntos que ahora mismo quedan al buen criterio a la hora de llamar.

Estoy valorando la posibilidad de que siempre haya que activarlo explícitamente mediante el flag Model::useFlatBehavior, haciendo que este se ponga en false nada más utilizarlo. De este modo me aseguro de no obtener resultados inconsistentes en según qué situaciones.

A lo mejor hay que ponerlo en otro Behavior, pero se me ocurre que otra "fusión" útil sería fundir campos de modelos asociados mediante hasMany para que se muestren como un sólo campo del modelo principal.

Instrucciones

1. Copia el código que está más abajo y ponlo en /app/models/behaviors/flat_table.php
2. En el modelo, especifica Model::actsAs para que incluya FlatTable, puedes pasarle un array con los modelos y campos que quieres fusionar.
3. Establece una variable del modelo Model::useFlatTable = false; para especificar cuándo quieres usar o no el behavior. Yo la inicializo a false para tener que activarla expresamente.
4. Antes de solicitar los datos en el Controlador, activa el flag anterior mediante $this->Model->useFlatTable = true; sustituye Modelo por el nombre de tu modelo, claro.

La forma de especificar en Model::actAs es la siguiente:

array ('FlatTable' => array ('Modelo 1 para fusionar' => array ('campos', 'del', 'modelo 1')

Si no especificas campos, se fusionarán todos. Puedes especificar solo un campo con la estructura:

array ('Modelo 1' => 'campo del modelo')

O sólo un modelo:

array ('FlatTable' =>'Modelo 1 para fusionar')

Un ejemplo de uso en el modelo:

class Recurso extends AppModel
{
var $name = 'Recurso';

var $actsAs = array (
    'Upload' => array ('imagen' => array ('ruta' => 'test')),
    'FlatTable' => array ('Categoria' => 'categoria')
);
var $useFlatTable = false;
var $belongsTo = array ('Categoria');

...
} // END class Recurso

FlatTable

Pon esto en:

/app/models/behaviors/flat_table.php

/**
 * Behavior para unir los datos de una relación belongsTo de modo que se devuelvan
 * como una sola tabla. Básicamente se pretende facilitar el uso de tablas sencillas
 * cuando realmente no se necesita más.
 *
 * This Behavior joins data from belongsTo associations returning the array as it was a single model.
 * The point here is to pass the data to a simple table view. foreign key deleted from the
 * resulting array
 *
 * @package default
 * @author Fran Iglesias
 * @version 0.1
 **/
class FlatTableBehavior extends ModelBehavior {
 // Array que especifica modelos/campos para unir
 var $queUnir = array ();
 
 /**
  * Parse settings, a list of associated models, and fields that must be merged with primary
  * Cargar e interpretar los ajustes, una lista de modelos asociados y campos que deben mezclarse con el primario
  *
  * @return void
  * @author Frankie
  **/
 
 function setup (&$model, $settings = false) {
  // Si no se pasan settings, no usar el Behavior
  // Don't use behavior if no settings passed
  if (!$settings) {
   $model->useFlatTable = false;
   return;
  }
  // Convertir la cadena en array si es necesario, se asume que se pasa un modelo
  // String to Array conversion if needed, $settings is a Model
  if (!is_array ($settings)) {
   $settings = array ($settings => array ());
  }
  // Parse settings to ensure right format
  // Revisar settings para asegurarse de que el formato es correcto
  foreach ($settings as $modelo => $campos) {
   if (is_numeric ($modelo)) {
    $modelo = $campos;
    $campos = array ();  
   }
   if (!is_array ($campos)) {
    $campos = array ($campos);
   }
  $this->queUnir[$modelo] = $campos;
  }
 }

 /**
  * Modifica la estructura del array de datos de modo que simula que los datos
     * entregados tras una relación belongsTo son de una única tabla
     * 
     * Flatten array as it was a proper Model array
  *
  * @return void
  * @author Frankie
  **/

 function afterFind (&$model, $results, $primary) {
  
  // Comprobar el flag useFatTable
  // Check model::useFatTable
  if (empty ($model->useFlatTable) ) {
   return true;
  }
  // No hacer nada si los datos vuelven vacíos
  if (empty ($results)) {
   return true;
  }
  // No hacer nada si el modelo primaria no está
  if (!isset ($results[0][$model->name])) {
   return true;
  }  
  // Obtener los modelos que podría unir con este sistema
  // What models can we join?
  $belongsTo = array_keys ($model->belongsTo );
  $modelosEnResultado = array_keys ($results[0]);
  $unir = array_intersect ($belongsTo, $modelosEnResultado);
  // 
  $recordSet = array ();
  foreach ($results as $clave => $fila) {
   $record = $fila[$model->name];
   foreach ($unir as $modelo) {
    // Quitar las foreignKeys, strip foreignkeys (¿Settings for this?)
    $foreignKey = strtolower ($modelo).'_'.'id';
    unset ($record[$foreignKey]);
    if (!empty ($this->queUnir[$modelo])) {
     foreach ($this->queUnir[$modelo] as $campo) {
      $record[$campo] = $fila[$modelo][$campo];
     }
    } else {
     // Strip associated model id key
     unset ($fila[$modelo]['id']);
     $record = array_merge ($record, $fila[$modelo]);
    }
   }
  $recordSet[][$model->name] = $record;
  }
  return $recordSet; 
 }
 
} // END class FlatTableBehavior extends Behavior

?>

¿Cómo recibe datos una acción de un controlador? (parte 1)

Es bastante sencillo.

Supongamos que tienes una accion en un controlador que necesita algunos parámetros:

class ControladoresController extends AppController {
    var $name = "Controladores";

    function Accion ($param1 = null, $param2 = null) {
        // ... el código
    }
}

Vale, pues para invocarla y pasarle los parámetros necesitamos una url tal que así:

/Controladores/Accion/param1/param2

Que en el formato array, debe ser algo así:

$url = array (
    'controller' = 'Controladores',
    'action' = 'Accion',
    'param1',
    'param2'
)

Aparte de que la acción reciba los datos de esta manera, es posible acceder a los parámetros pasados a través de la propiedad Controller::params['pass'], que devuelve un array con los parámetros pasados.

Ahora tengo que ver eso de pasar parámetros con nombre...

De Behavior a Helper

Llevo todo el día peleandome con lo que iba a ser un Behavior y ha acabado siendo un Helper.

En principio, yo quería hacer un Behavior capaz de "unificar" los resultados de un modelo con una asociacion BelongsTo. En concreto, se trata de unos Recursos que pueden pertenecer a una Categoría. Lógicamente Recursos tiene un campo categoria_id como foreign key.

De cara al usuario lo que tiene sentido, lógicamente, es que aparezca la etiqueta de la categoría en el listado de recursos o en la ficha, y no su id.

Por otra parte, había escrito un Helper para generar tablas (bastante flexible, ya lo colgaré cuando lo pula un poco más y le haga una documentación) a partir del resultado de un FindAll para un único modelo.

Sin embargo, la cosa se complica un poco si hay asociaciones, por lo que me interesaba "aplanar" el resultado. Es decir, que la etiqueta de la categoria apareciese como si fuese un campo de Recurso.

Empecé como behavior que se ejecutaba en afterFind, pero cuando conseguí que funcionase me dí cuenta de que daba más problemas que soluciones. Sobre todo porque, como comenté en el post sobre las precauciones con los callbacks, cualquier operación de Find lo llamaba.

Sin embargo, reflexionando un poco pensé que no tenía mucho sentido transformar los datos en el modelo para lo que era básicamente un problema de presentación. Es decir, que lo mejor sería crear un helper que tome el array de datos pasados a la vista y los reorganice en la forma deseada.

Ahora tengo dos Helpers:

• joinTable: toma un array de modelos generado por un FindAll y fusiona los modelos en uno solo, para simplificar la visualización de los datos. Le puedo indicar qué campos de los modelos asociados tiene que unir, así controlo los datos que pasan.
• simpleTable: toma un array de modelos (pasado directamente o preparado por joinTable) y genera una tabla con ellos, pudiendo configurar cosas como el orden de columnas, columnas para ordenar, etiquetas, acciones, y otras cosas.

La verdad es que no funcionan mal, aunque hay que pulir el código para que sea más legible y elegante y también para que haga un par de cosas que me faltan, como poder poner la columna acciones en el sitio que yo quiera.

Precauciones con los Callbacks

¿Callbacks? ¿Qué es eso?

Una posible definición de "callback" podría ser que se trata de una función "A" que es llamada desde una función "B", con la particularidad de que esta última es una "caja negra", es decir, que no podemos tocar su código o sobreescribirla. De este modo, se nos permite modificar su comportamiento sin alterar su funcionalidad básica.

En CakePHP los modelos y controladores tienen varios CallBacks correspondientes a diversos "eventos", como beforeSave, afterFind, etc. Esto nos permite añadir lógica específica para esos momentos, sin tener que reescribir cosas como el método Save para un modelo concreto. Es un buen lugar para cambiar el formato de datos, recolectar estadísticas, borrar archivos asociados a un modelo cuando borramos éste, y muchas cosas más.

No sólo eso, sino que los behaviors, components y helpers también tienen sus CallBack que son llamados por sus modelos, controladores y vistas respectivos en el momento adecuado.

Esto nos permite tener una organización del código bastante buena, así como seguir un proceso de trabajo relativamente seguro.

Por lo que respecta a la organización, podemos separar la lógica principal "de negocio" de la lógica, digamos, "burocrática" de preproceso y postproceso.

Por ejemplo, acabo de escribir un behavior "upload" que se encarga de guardar en el lugar adecuado un archivo recién subido desde un formulario de modelo y rellenar el campo con la ruta al archivo. De este modo, las acciones add y edit del controlador no hacen más que lo que tienen que hacer (obtener los datos del POST y crear o actualizar el modelo), mientras que el behavior se encarga del trabajo "sucio" de mover el archivo en el callback beforeSave, dejándolo todo listo para guardar.

En cuanto al proceso de desarrollo, una de las ventajas de trabajar con los CallBacks es que puedes ir creando la lógica básica de la aplicación y dejando para una segunda fase los detalles relativos a filtros de entrada y salida de datos. De este modo se aislan esas partes de código y es más fácil depurar los posibles problemas, que quedan bien localizados.

¿Y las precauciones?

Del mismo modo que los CallBacks resultan muy prácticos a la hora de organizar el código, también es cierto que hay que tomar algunas medidas para asegurarnos de que las cosas van a funcionar correctamente.

Por ejemplo, model::beforeSave se va a ejecutar cada vez que hagas un model::Save (normalmente en acciones del controlador omo add o edit, pero también en otras partes) o un model::saveField. En cualquier caso tienes que asegurarte de que tu CallBack sabe lidiar con los datos que va a recibir. He aquí un caso práctico:

Caso práctico moderadamente vergonzante para el autor

Acabo de pasar unas horas intentado averiguar por qué un simple model::saveField no guardaba los datos de un campo. Pues todo "por culpa" de un CallBack en un Behavior (el upload que citaba antes). Lo que yo quería hacer era borrar el campo que contenía la ruta a un archivo mediante una llamada model::saveField ('archivo', null). Por supuesto, ese campo en concreto era procesado por el behavior. El modelo llama al beforeSave del behavior desde model::saveField, como acabo de decir más arriba, y justamente trata de procesar ese mismo campo. Al no haber programado un control para esa situación (que el campo 'archivo' no tuviese valores o éstos no tuviesen la estructura de datos para subir archivos) el resultado no tiene sentido y el intento de guardar falla.

Al principio resultaba muy extraño porque la lógica básica era muy sencilla: para borrar el archivo, lee su ruta con el modelo, localiza y elimina el archivo en el sistema de archivos y borra el campo del modelo.

Sólo después de varias horas he acabado dándome cuenta de que ese "error" en el behavior no era consecuencia del problema de no poder guardar el nuevo valor en el modelo, sino justamente al revés: era la causa.

Moraleja(s)

A la hora de depurar, lleva un registro de los Callbacks que puedan afectar a tus datos (tanto en los modelos y controladores, como en los Behaviors, Components y Helpers). Así podrás ir descartando ubicaciones del problema.

Asegúrate de que identifican correctamente el tipo de datos que pueden/deben manejar y que saben cómo actuar si los datos vienen con otra estructura, aunque sea válida.

Modulariza todo lo que puedas. Nunca se tiene bastante RAM ni se modulariza el código lo suficiente.

Progresos

Poco a poco voy consiguiendo progresos en el aprendizaje de CakePHP. Hace más o menos una semana que comencé a intentar desarrollar algo concreto y lo cierto es que va funcionando. No está terminado, pero me ha servido para aprender unas cuantas cosas.

La imagen de arriba muestra un típico "index" de una tabla del modelo paginada. Lo más complejo ha sido crear la vista y tengo que probar algunas estrategias para ver qué hacer cuando no hay datos que mostrar. Sin embargo, ahí tengo botones de acciones personalizados, etc. A ver si encuentro iconos mejores, por cierto. ¡Ah! Y alguna manera de dar un mejor aspecto al paginador.

Como se puede ver, hay imágenes en los registros. Esto me ha servido para aprender a incluir Behaviors. En concreto uno "bastante bueno" para subir archivos, con algunas características curiosas, como la capacidad de autoenrutar el archivo en función de su tipo mime. También funciones para validar por tipo o subtipo mime y otras cosillas. Tengo todavía un problema con la sobreescritura de archivos, que ahí peta. También quiero añadirle la posibilidad de guardar los archivos (o referencias a ellos) en una tabla común.

También he aprendido a crear elements y algo sobre usar requestAction. Esto es útil para acceder a resultados de (otras) acciones de (otros) controladores, aunque hay quien sugiere algunos enfoques menos cargantes para la base de datos. Supongo que eso es matizar mucho para alguien que apenas lleva una semana escribiendo sobre CakePHP.

Entre otros próximos objetivos tengo la posibilidad de crear algún Helper para las tablas de datos, al menos para los tipos más comunes de acciones, seleccionar columnas que quiero mostrar/no mostrar/ocultar, etc. Aún me quedan un montón de historias para aprender, pero lo bueno es que lo que va saliendo... pues va saliendo. El scaffolding de Cake es como una red de seguridad.

Otro tema, es que tengo que ver cómo añadir en la acción delete algo que se encargue de borrar las imágenes asociadas a un recurso. Supongo que en BeforeDelete del modelo o algo así. Tengo que verlo.