Múltiples botones submit en un formulario

Necesitaba conseguir lo que dice el título, o sea, disponer de varios botones de submit en un formulario, de modo que, además del envío normal del formulario, pudiese detectar qué botón concreto se ha pulsado para realizar ciertas operaciones en función del mismo.

Lo que no sabía era cómo hacerlo "a la Cake".

Bueno, pues es sencillo:

1. En el formulario, añade un control $form->submit con opciones para indicarle un nombre y un valor que luego podrás capturar en el controller. Por ejemplo:

$form->submit(__('Reset Filter', true), array('value' => true, 'name' => 'resetFilter'))

Ahora, para comprobar si el botón ha sido pulsado, no tienes más que mirar en la propiedad params del controlador, de esta manera:

$this->params['form']['resetFilter']

Que contendrá el valor del botón que hayas pulsado. Es decir, puedes tener varios botones con el mismo "name" y distinto valor, o bien simplemente botones con distintos "name" y chequear si dentro de $this->params['form'] existen las claves correspondientes.

Selector de minutos

Al usar el método input del FormHelper para un campo de hora y, en general, cualquier método de este Helper para generar campos de horas y/o minutos es posible especificar el intervalo en minutos entre cada opción. Por defecto, este intervalo es 1, l que produce uno de esos largos e incomodísimos desplegables con los minutos de 0 a 59.

En la mayor parte de los casos, un desplegable con opciones cada 5 ó 15 minutos funciona estupendamente. ¿Cómo se consigue?

Pasa la opción 'interval' => 15 (o el valor que necesites) en el array de opciones o atributos del campo. En el caso de un input, aquí tienes un ejemplo:

<?php echo $form->input('Evento.hora_inicio', array('timeFormat' => '24', 'empty' => true, 'interval' => 5)); ?> 

En este ejemplo, para un sitio sobre actividades y eventos diversos, hemos usado un intervalo de 5 minutos, que da 12 opciones.

Más diversión con el Form Helper: campos de fecha (actualización)

El método input de FormHelper está muy bien para resolver los problemas generales de creación de formularios, pero si por alguna razón nos resulta insuficiente tenemos más recursos a nuestra disposición.

Por ejemplo. Cuando se trata de un campo para fechas, el método no resulta muy flexible (al menos en su versión actual) ya que siempre nos fuerza a un determinado formato. FormHelper tiene un método dateTime que se usa precisamente para crear este tipo de campos y que de hecho es llamado desde input. Sin embargo, si lo usamos nosotros directamente podemos personalizarlo a gusto.

Lo único que tenemos que saber es cómo trabaja Input para generar el código y reproducirlo con nuestras preferencias.

$campoPublicacion = $form->label ('Circular.publicacion', 'Fecha de publicación');
$campoPublicacion .= $form->datetime ('Circular.publicacion', 'DMY', null, null, null, true);
echo $html->div('input', $campoPublicacion);

La explicación del código anterior es bastante sencilla: lo primero que hacemos es generar la etiqueta del campo (label). Después, generamos el control mediante el método dateTime, indicando el formato y como queremos mostrarlo por defecto. Finalmente, empaquetamos eso en un DIV con la clase input.

El resultado es el mismo código que se generaría con input. Sólo que esta vez con el formato deseado. Puedes consultar la API del método dateTime, que es bastante clarita para saber cómo pasar los argumentos.

Actualización 22-1-2008

Con la salida de la versión 1.2 beta ya se ha corregido el asunto del formato de los campos de fecha y es posible pasar un formato en el método input, lo anterior se puede escribir así:

echo $html->input('Circular.publicacion', array('label' => 'Fecha de publicación', 'dateFormat' => 'DMY'));

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.