El plugin DataTables (XIV). Más tipos de datos desplegables.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

En un artículo anterior en esta serie aprendimos cómo obtener datos que no estaban a la vista al renderizar las tablas, pero que podían visualizarse, en una fila desplegable, pulsando sobre un icono. En este artículo vamos a ir un paso más allá. Veremos cómo insertar imágenes en una fila desplegable. Además, seguiremos aprendiendo sobre la adaptación previa de los datos, antes de la renderización, que ya vimos, también, en otro artículo.

Este artículo presenta, cómo tales, pocas novedades. Sin embargo, a la hora de reforzar algunos conocimientos, y explotar mejor las posibilidades que ya conocemos, tiene un gran valor didáctico. Yo mismo he aprendido cosas redactándolo, y he disfrutado de ellas. Espero que este artículo sirva para compartir contigo ambas experiencias.

EL ESCENARIO

El escenario sobre el que vamos a trabajar es una base de datos de usuarios, cada uno de los cuales, además de sus propios datos, puede tener (o no tener), una o más imágenes asociadas. Podría ser la base de una rudimentaria red social, o un portal de contactos, o alguna otra estructura similar. Para las imágenes, no emplearemos fotos de personas, sino imágenes obtenidas en la Red, libres de derechos. En Internet existen gran cantidad de sitios donde se puede encontrar este tipo de material.

Nuestro escenario cuenta con una base de datos con dos tablas: una con los datos de los usuarios. Otra con los nombres de las imágenes, y una columna con el id del usuario al que pertenece cada una. Todo el materíal (base de datos, scripts e imágenes) te lo he dejado para descargar en este enlace.

La tabla de usuarios sólo cuenta con los campos relativos al nombre, apellidos, fecha de ingreso en el portal, y su género (masculino o femenino), además, por supuesto, del identificador autoincrementable de la tabla. Si bien para un portal real estos datos serían insuficientes, para este artículo cubren nuestras necesidades, y no quiero dispersarme en contenidos innecesarios.

La tabla de imágenes tiene el nombre del archivo de imagen, el id del usuario al que pertenece, y su propio id.

Un pequeño inciso. Cuando crees tablas en MySQL ponles siempre una clave primaria autoincrementable, incluso si, al modelar los datos, piensas que no es necesaria. Esta cumple dos misiones de vital importancia. Puede ser un campo para relacionar tu tabla con otra. Esta función no siempre existe. Por ejemplo, en nuestro escenario, en la tabla de usuarios sí existe, ya que se usa el id para relacionar a los usuarios con las imágenes. En la tabla de imágenes, en cambio, el id de cada imagen no se relaciona con nada.

La otra función es que una clave primaria autoincrementable constituye un índice muy eficiente y rápido cuando queremos obtener los datos de una tabla sin usar un criterio de ordenación específico. Además, en ciertos entornos de trabajo (como phpMyAdmin), si no existe esta clave, al examinar la tabla no se pueden borrar o editar registros.

Por cierto. Estas claves primarias, que no son parte de los datos propios de cada registro, y que sólo (?) cumplen la función de ser claves primarias se conocen, en el mundillo SQL, con el nombre de claves subrogadas.

Y vale ya de charla. Vamos al tajo.

EL SCRIPT PRIMARIO

Este script presenta importantes detalles (y alguna novedad) que vamos a conocer. Lo he llamado artículo_14.php y su listado es el siguiente:

Lo primero que nos llama la atención es lo que hay en el primer bloque resaltado, entre las líneas 81 y 93. El uso de columnDefs en sí no es ya nuevo para nosotros. Es la forma en que lo hemos empleado, permitiéndonos el procesado de dos columnas, previo a la renderización, lo que quizá nos llame un poco la atención. Por un lado, en la columna del nombre incluimos este junto a los apellidos. Por otra parte, el género, que en la base de datos está como M o F lo hacemos aparecer cómo Masculino o Femenino. De este modo logramos un resultado más amigable al usuario.

ATENCIÓN. Si quieres comprender realmente cómo funciona render en columnDefs te sugiero que introduzcas, durante las pruebas, un volcado en consola para ver los valores de los parámetros incluidos en las correspondientes funciones. Así, el bloque entre las líneas 80 y 82 pasa de ser esto:

"render": function (data, type, row) {
    return row['nombre']+' '+row['apellidos'];
}

a esto otro:

"render": function (data, type, row) {
    console.log (data, type, row);
    return row['nombre']+' '+row['apellidos'];
}

Y lo mismo haríamos con el bloque entre las líneas 86 y 88.

Ahora, antes de cargar el script en el navegador, despliega la consola de JavaScript (CTRL-MAYS-J, si usas Chrome) y observa lo que se muestra cuando cargues la página. Si quieres conocer más sobre la consola de JavaScript te sugiero este artículo y este otro.

Por otra parte, fíjate en el segundo bloque resaltado, entre las líneas 130 y 149. En realidad, con los conocimientos de JavaScript que tiene cualquier usuario medio, enseguida ves lo que hacemos. Si el usuario tiene imágenes, se muestran las que hay en la carpeta miniaturas en una tabla. Si no, se muestra un literal notificando este hecho.

En realidad, este script no tiene novedades dignas de mención. Con lo que hemos aprendido en los artículos anteriores y los comentarios del código, no creo que haya lugar a ninguna duda.

EL SCRIPT SECUNDARIO

Este script presenta alguna curiosidad que nos llama la atención. El listado se llama datos_externos_14.php:

En lo que quiero que te fijes es en la forma en que leemos los datos. Estamos trabajando con dos tablas que están relacionadas entre sí. La tabla de usuarios, que es la que podríamos llamar principal, ya que es donde están los datos que se van a mostrar, al inicio, en la página, tiene una clave primaria llamada id. La tabla de imágenes (secundaria) relaciona cada imagen con un usuario.

Sin embargo, al hacer la consulta, no podemos leer las dos tablas relacionadas, ya que, si por ejemplo, hay algún usuario (y los hay) que no tiene imágenes, no se recuperaría en el dataset este usuario. Así, lo que hacemos es leer la tabla de usuarios, en un dataset previo. Después, a cada usuario le leemos las imágenes que tiene (si es que las tiene), y formamos el dataset definitivo que usaremos para entregar datos al DataTables.

Esta manera de trabajar es la primera vez que la vemos, pero, desde luego, te aseguro que no será la última. De hecho, en la mayoría de escenarios reales en un dataset se ven implicadas dos o más tablas relacionadas, ya sea en 1-n o en m-n. Si lees el código, verás que, en realidad, es bastante simple. Presta especial atención a los comentarios.

LA METEDURA DE PATA

El código que hemos visto hasta ahora no está mal del todo, pero presenta un problema: como ves, no hay una columna específica para los apellidos. La consecuencia directa de esto es que no se pueden hacer búsquedas por ese campo. Si te vas a la casilla de búsquedas y tecleas un apellido que sabes que está ahí, que lo estás viendo, comprobarás que no te muestra los resultados coincidentes. Esto es porque, cómo te he comentado, no existe realmente esa columna, al haber agrupado el nombre con los apellidos.

La solución a esto es añadir una columna exclusivamente para los apellidos. La añadiremos al final de la tabla HTML, es decir, a la derecha, para que el orden de las columnas coincida con el orden de los campos de la tabla MySQL que se leen en datos_externos_14.php. Pero claro, la columna no puede ser visible porque entonces los apellidos se verían dos veces: una en la columna del nombre completo y otra en la propia columna de los apellidos. Eso quiere decir que la columna de los apellidos tenemos que declararla como no visible.

Esto es algo que aprendimos a hacer por programación en el artículo XI, mientras que en el artículo XII veíamos como configurar una columna para que fuera invisible al inicio. Para ver como funciona, sustituye en tu ordenador el script articulo_14.php por articulo_14_b.php, cuyo listado es el siguiente:

Observa las líneas resaltadas. En la línea 27 definimos una columna más en la cabecera de la tabla HTML. Es la que usaremos para los apellidos. No le hemos puesto rótulo, porque dado que la vamos a hacer invisible, es irrelevante, pero debe estar ahí para que el númerto de columnas de la cabecera coincida con las columnas de datos que manejaremos.

En las líneas de la 95 a la 98 es donde decimos que la columna correspondiente al campo apellidos no será visible.

En la línea 111 declaramos el dato apellidos para esta columna.

Y con eso ya está. Si ahora pones algo en la caja de búsqueda verás que lo busca en todas las columnas, incluida la de apellidos. El hecho de que sea invisible no significa que no esté ahí. Pasa un poco como con las peticiones de aumento de sueldo que se le hacen a algunos jefes: la petición está ahí, pero para el jefe es invisible. Bromas aparte, con esto vemos como agrupar campos, sin perder prestaciones o funcionalidades.

Por cierto. Esta última versión mejorada también la tienes en el paquetito que te he puesto para descargar. 😉 

     

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *