Una idea para no redirigir tanto

Estaba escribiendo el esqueleto de unas acciones para gestionar el registro y confirmación de usuarios cuando me di cuenta de que hay situaciones en las que puede ser buena idea usar Controller->render() para dirigir al usuario a páginas que le informen sobre el resultado de sus acciones, en lugar de Controller->redirect() para hacer lo mismo.

Por ejemplo:

function register() {
if ($this->data) {
if ($this->User->register($this->data)) {
$this->render('registration_ok');
}
}
}

En esta acción, si el registro se hace correctamente, la acción muestra la vista 'registration_ok', que mostraría un mensaje explicando al usuario que su registro ha sido correcto y lo que debe o puede hacer a continuación.

En otro caso, se mostraría la vista por defecto 'register'.

Obtener el prefijo de una acción (o dividir una cadena)

Esta es una de esas cosas que siempre se me olvidan, así que voy a anotarla.

He aquí una operación típica para romper un string en dos partes, sabiendo que están separadas por un carácter concreto, en este caso el socorrido "underscore".

list($part1, $part2) = explode('_', $string);

Aplicándolo a CakePHP, vamos a imaginar que tenemos el nombre de una acción y queremos saber si tiene prefijo y cuál es. Así que en algún sitio de nuestro Controller (probablemente en el beforeFilter) hacemos:

$action = $this->params['action'];
list($prefix, $actionName) = explode('_', $action);

Sencillo, ¿verdad?

Pero, ¿qué pasa si $action no tiene prefijo y por tanto no hay separador en la cadena?

Bueno, pues en ese caso, $prefix toma el valor de la cadena y $actionName queda vacío, por lo que necesitaríamos el siguiente código para controlar la situación:

$action = $this->params['action'];

list($prefix, $actionName) = explode('_', $action);

if(!$actionName) {
    $actionName = $prefix;
   $prefix = '';
}

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