Hasta ahora hemos visto algunos ejemplos de uso del editor con algunos tipos de campos, como son los de tipo text (que es el tipo por defecto), los combos de tipo select y los campos de fechas (tipo date). En este artículo aprenderemos a manejar tres campos nuevos: los de tipo radio, los checkbox y las textareas.

Este artículo es una introducción a dichos campos. En artículos posteriores iremos profundizando, para no sobrecargar una sóla sesión de aprendizaje. Que lo disfrutes.

EL ESCENARIO

Para este ejercicio vamos a partir de una base de datos muy sencilla, ya que esta vez no se trata de trabajar con relaciones entre tablas, sino de ver el funcionamiento de distintos tipos de campos. De este modo, podremos centrarnos en la cuestión de este ejercicio, apartando otros aspectos que pudieran distraernos. La base de datos se llama datatables_casillas, y contiene, sólo, una tabla llamada usuarios. Esta tabla representa a los usuarios de un portal donde, por ejemplo, mediante la tenencia de cierto número de créditos, se puede tener acceso a ciertas funcionalidades. Podría ser una red social, o un portal de compras, o de acceso a juegos o películas, etc. Los campos de la tabla son los siguientes:

• id. Cómo de costumbre, empleamos un campo numérico autoincrementable, a modo de clave subrogada, para seguir con las buenas costumbres. En un artículo anterior ya te he comentado las bondades de usar siempre este tipo de campos.
• nombre. Contendrá el nombre de pila del usuario.
• apellidos. Contendrá el apellido o los apellidos del usuario.
• genero. Es un campo de tipo enum, con los posibles valores M o F (de Masculino o Femenino). El valor de este campo se establecerá, en el formulario del editor, mediante el uso de dos botones de radio.
• es_administrador. Este es un campo de tipo enum, con los posibles valores S o N (Sí o No), reflejando si el usuario tiene la prerrogativa de ser un administrador del sitio. Este campo lo gestionaremos, en el formulario del editor, mediante una casilla checkbox.
• creditos. Es un campo de tipo numérico que refleja el número de créditos que tiene el usuario disponibles para realizar operaciones en un hipotético contexto de consumo de funcionalidades y/o contenidos. Este dato se manejará en el formulario como un campo de tipo text, al que se le limitará el contenido a datos numéricos, ya que el editor de datatables no posee un campo específico de tipo number. El criterio que seguiremos para el funcionamiento es que, si el valor es -1 se considerará que el usuario tiene créditos ilimitados. Este podría ser, por ejemplo, el caso de los administradores (o de algunos de ellos).
• fecha_alta. Un campo de tipo date, que contendrá la fecha en que se registra el usuario en el portal.
• observaciones. Se trata de un campo de tipo text, El contenido de este campo se mostrará como una fila adicional desplegable en la renderización de datatables, tal cómo ya conocemos. En lo que al formulario del editor se refiere, este dato se grabará como un textarea, para que veamos el funcionamiento.

EL SCRIPT PRIMARIO

El script primario se llaman articulo_editor_07.php. Contiene, como ya es habitual, el objeto datatables, para la renderización de los datos en una tabla HTML, y el objeto editor que define el formulario para crear nuevos registros, editar los existentes, o eliminarlos. El listado es el siguiente:

Si bien el listado ya incluye suficientes comentarios para poder entender como opera cada parte del código, vamos a tratar de ser un poco más específicos en algunos puntos concretos.

En primer lugar, fíjate en la forma en que definimos un campo formado por botones de radio, entre las líneas 141 y 150. Definimos el campo como un conjunto de botones de radio. Para ello, lo declaramos así:

type: 'radio', 

Cada uno de los botones se define bajo el epígrafe options, indicando dos parámetros: label será la etiqueta que se verá en el formulario junto al botón de radio que estamos definiendo, mientras que value será el valor que recibirá el campo si ese botón está activado.

options: [
    {label: "Masculino", value: 'M'},
    {label: "Femenino", value: 'F'}
],

Este tipo de botones, por su propia naturaleza, son adecuados para campos de tipo enum, que pueden tener un número discreto de posibilidades. Debe haber un botón de radio por cada posible valor que pueda tener el campo enum y el atributo value de dicho botón debe coincidir con uno de los posibles valores del campo enum. Así, tenga el campo el valor que tenga, se activará el correspondiente botón de radio cuando abramos el formulario para editar. Dicho de otro modo: en nuestro ejemplo, el campo genero de la tabla usuarios siempre tendrá el valor M o el valor F. Así pues, cuando abramos el formulario del editor para modificar los datos de un registro, aparecerá activado el correspondiente botón de radio. Si tuvieran unos valores distintos de los posibles valores del campo enum (por ejemplo, si a los botones de radio les hubiéramos aplicado los valores, digamos, masc y fem) no sería posible que se activará el adecuado de forma automática, y aparecerían los dos desactivados, lo que no nos conviene.

Además, tenemos el parámetro def, que permite establecer que botón de radio se activará por defecto cuando estemos creando un nuevo usuario. El que escojamos es irrelevante. El hecho es que haya siempre uno activado por defecto, para evitar tener que comprobarlo al enviar el formulario. Así, ya estamos forzando al usuario a escoger una opción. Es una forma de decirle: “si no escoges tú, escojo yo, pero hay que escoger”.

En las líneas de la 160 a la 167 vemos como definimos un campo de tipo casilla de texto. Estos campos son adecuados cuando se refieren a un campo de la base de datos, de tipo enum, que puede tener dos posibles valores, y sólo dos. En el caso de nuestro ejemplo, es claramente una buena opción. Un usuario es administrador, o no lo es. Hay que escoger una opción y sólo una. También serían adecuados si hubiera una colección de estas casillas, y se refiriesen a distintos campos de este tipo. Es decir, en general, un campo de tipo checkbox es adecuado en las mismas circunstancias que lo usaríamos en un formulario HTML convencional.

En el epígrafe options se puede establecer una etiqueta para cada casilla, aunque, en este ejemplo, la hemos dejado en blanco. El valor establecido en value debe coincidir con uno de los dos posibles valores en el campo enum de la tabla. Así, si el campo tiene ese valor, aparecerá la casilla marcada por defecto. Si tiene el otro valor, aparecerá desmarcada.

En las líneas 180 a 184 ves cómo se define un campo de tipo textarea, de una forma simple. En posteriores artículos veremos como configurar interesantes opciones de este tipo de campos.

Quiero llamar tu atención a la finalidad que le damos aquí al evento preOpen del formulario. El uso de este evento ya no es nuevo. Aquí lo hemos empleado para ajustar la altura de las etiquetas de los botones de radio y checkbox, para mejorar el aspecto visual, como puedes ver en las líneas 192 y 193.

El evento preSubmit lo hemos usado para que, antes de enviar un formulario de edición o de nuevo registro, se compruebe que en el campo créditos hay un valor numérico válido. Esto es -1 (lo que, como hemos acordado, significa créditos infinitos), 0 (ningún crédito) o un valor positivo. Ya hicimos algo parecido en artículos anteriores de esta serie con los salarios de una tabla de personal, así que, realmente, tampoco nada nuevo por aquí.

EL SCRIPT DE CRUD

El script destinado a responder al formulario del editor se llama crud_editor_07.php y su listado es el siguiente:

Realmente, donde tenemos que fijarnos es en las líneas que aparecen resaltadas. Cuando nuestro formulario incluye (como es el caso de este ejercicio), casillas de checkbox, estas llegan como una matriz. Así por ejemplo, en nuestro listado primario el campo es_administrador va a llegar como una matriz de un solo elemento (ya que sólo tiene una casilla). Pero es que, además, si la casilla no está checada, el elemento, simplemente, no es enviado. Así pues, debemos determinar si el elemento ha llegado (lo que implicaría casilla checada) o no (lo que implicaría casilla no checada). Con una sola casilla checkbox es difícil comprender esta operativa. En un artículo posterior veremos ejemplos con más de una casilla checkbox por campo, lo que nos permitirá analizar a fondo la forma en que se transmiten este tipo de datos.

Por lo demás, el resto del script es cómo ya lo conocemos.

CONSIDERACIONES FINALES

En cuanto al  script que lee los datos para el datatables, no hay nada de nuevo. Su operativa es ya de sobra conocida. En este enlace tienes los scripts y la base de datos que hemos empleado en este ejercicio.