Sin embargo, a la hora de validar las páginas de la bitácora usando el tema GbMobile con el nuevo tipo de documento, me he encontrado conque el W3C me advertía del uso del atributo "onclick" en ciertos elementos, en concreto, los que tienen que ver con el CAPTCHA de Gesbit, puesto que este permite "recargarse" y "escucharse", y para esto hace uso de los atributos "onclick" y su poquito de Javascript. pero XHTML Mobile Profile 1.0 no pasa por ahí, amigo.

Así que he aprovechado para mejorar un aspecto de la clase CAPTCHA que me viene preocupando desde hace tiempo: la personalización de los elementos del formulario "HTML" en que se muestra la imagen en cuestión, y el resto de código HTML necesario. Ahora, el método "FormFields()" de la clase Captcha de Gesbit permite especificar, entre otras cosas, si se requieren los enlaces para "recargar" y "escuchar" la imagen CAPTCHA, de modo que GbMobile, simplemente, los omite.

Esto no significa que no puedan escribirse comentarios, pero, la mecánica cambia un poco respecto de la habitual en el resto de temas de Gesbit: en el tema de GbMobile no hay "vista previa" del comentario, porque para esto también se usaba cierto atributo "onclick", y, como podrá imaginarse, tampoco es posible "recargar" ni "escuchar" el CAPTCHA. Sin embargo, es posible añadir comentarios, y por supuesto el test CAPTCHA estará ahí si se está usando en la bitácora, que, como sabes, es opcional.

En fin. Termino recomendando la lectura de cierto artículo que me parece muy útil y curioso: Global Authoring Practices for the Mobile Web, de Luca Passani. Y, por cierto, la demostración de Gesbit cuenta con el plugin GbMobile, y puedes probarlo, si te apetece, en el emulador del navegador Opera Mini. Abre el enlace anterior y escribe en el navegador: www.demo.gesbit.com ¡Que usted lo pase bien! ;-)

De hecho, tenía un tanto abandonado el panel de administración en este sentido, y es que, aunque para las páginas de una bitácora procuraba enviar las cabeceras HTTP correspondientes, mediante la clase "FrontEnd" de Gesbit, no era así para los "scripts" del panel de administración, puesto que para estos "scripts" no se utiliza la clase "FrontEnd" en absoluto, pensada sólo para las páginas de las bitácoras.

Sea como sea, trabajando en otra cuestión, me he dado cuenta de que no estaba comprobando correctamente si un agente de usuario acepta la compresión GZip. Concretamente, el validador del W3C no acepta este tipo de compresión en los documentos para validar, y, había un error cuando se comprobaba esto, de modo que no se habilitaba la compresión Gzip correctamente. Al arreglar esto he trasteado en la clase "FrontEnd" y al cabo he acabado con una clase nueva: "UserAgent".

Como una forma de evitar el duplicado de código, y también para poner ciertas cosas en su sitio. Efectivamente, la clase "FrontEnd" contenía métodos que comprobaban si el agente de usuario aceptaba la compresión Gzip, y, por extensión, si este era el validador del "W3C", métodos estos que quedan mejor en una clase aparte, como es "UserAgent", puesto que se trata de obtener información del agente de usuario. Pero además se evita desde ya cierto duplicado de código.

Y es que, como he dicho, ahora se envían las correspondientes cabeceras HTTP también en los "scripts" del panel de administración, y se ha de comprobar si el agente de usuario acepta la compresión GZip, para habilitarla si es el caso, de modo que también la clase "Admin" hace uso de la nueva clase "FrontEnd", y no tiene que implementar (duplicar) lo necesario para averiguar si el agente de usuario soporta este tipo de compresión o no la soporta.

En definitiva, que, en virtud de estos cambios que relato, Gesbit sirve ya las páginas con compresión GZip, si está disponible (la correspondiente extensión para PHP) y la acepta el agente de usuario. Y que esto mismo se hace en los "scripts" del panel de administración. La clase "FrontEnd" se ha aligerado y existe una nueva clase "UserAgent" que ya es ciertamente útil y acaso puede serlo más aún en el futuro. Y esto es lo que tenía que decir respecto a la compresión Gzip. ;-)

Hasta ahora estaba funcionando bien; aparentemente, comprobar si en el directorio del caché existían archivos expirados, lo que significa revisar todos los archivos de dicho directorio, no llevaba mucho tiempo, aunque, como un egregio lector de esta bitácora apuntaba en un comentario, quizá era demasiado revisar esta cuestión a cada petición de los usuarios, puesto que, si la bitácora tenía muchas visitas, muchos archivos "cacheados", esto podía implicar un consumo excesivo de recursos. No quedó claro cómo de excesivo, pero, ciertamente, tampoco se puede dejar de pensar en ello.

Mientras se implementa o no en Gesbit una especie de "Cron", una especie de "gestor de tareas", se me ha ocurrido algo muy sencillo, pero, que, no se me ocurrió en su momento, y es utilizar una variable de sesión para comprobar si ya hemos comprobado el contenido del caché expirado para una determinada sesión de usuario. Es decir, ahora no se comprueba la expiración del caché a cada petición de usuario, sino a cada sesión de usuario, quiere decirse, que nos ahorramos todas las peticiones del mismo usuario, aunque, por supuesto, otros usuarios podrán ejecutar la limpieza del caché, en otra sesión de usuario.

Además, he "movido" el punto en que se comprueba si existe contenido en el caché expirado o no. Efectivamente, este punto es justo el momento en que se va a proceder a enviar contenido cacheado al usuario, por supuesto, si antes ha sido guardado. El cambio consiste en comprobar el caché expirado sólo si la petición del usuario es "cacheable", lo que quiere decir que es posible que exista contenido cacheado para ella. Si la petición de usuario no es cacheable, tampoco se comprobará el caché expirado, y no como se hacía hasta ahora, que se comprobaba en todo caso.

La verdad es que apenas si se nota diferencia. Mejor dicho, no se nota, porque, como he dicho arriba, tampoco se notaba ninguna "perturbación" por comprobar el caché expirado a cada petición del usuario, pero, es de suponer (o al menos así lo he supuesto) que algo se habrá ganado con esta medida. Sobre todo, si llega el caso de que una determinada bitácora gestionada con Gesbit, y que use el caché de contenido integrado, cuenta con una cantidad de visitas formidable. Quizá hasta podría realizarse alguna prueba sobre este asunto, pero, de momento, quédese como está.

Ahora bien, acaso el egregio lector a que me he referido esté leyendo esto, y quisiera preguntarle, ¿qué te parece, maestro, esta solución "ad hoc"? ¿Puede valer o qué? ;-)

Si quieres, puedes ver el tema Kubrick en el blog de Julián Torres, que, hay que decirlo, es la segunda persona de que tengo constancia que hace uso de Gesbit (*), además de yo mismo en esta bitácora y otras bitácoras que llevo a cabo. Espero que pronto Kubrick esté disponible en la wiki de Gesbit, y, desde aquí agradezco de nuevo a Julián Torres que se tomara el trabajo en su desarrollo. ¡Muchas gracias Julián! Doblemente además, por confiar en Gesbit para tu blog, y por el desarrollo de Kubrick. Bueno, y, también por otras cosas, por estar ahí, simplemente, que no es poco. Qué pelota soy, je je je. XD

(*) En realidad me consta que otra persona ha hecho también algunos pinitos con Gesbit, y me hizo cierta ilusión saberlo. Pero el blog de esta persona no está publicado, y yo no debo tampoco, creo, darlo a conocer. Sea como sea, se trata de las únicas personas que yo conozco, casi personalmente, que se han dispuesto a usar Gesbit. ¡Ellos sabrán lo que hacen! :D

Actualización: Ya es posible encontrar el tema Kubrick en la wiki de Gesbit.

Antes de mostrar las cifras, me gustaría decir algo al respecto. Para la comparativa he utilizado versiones recién instaladas, tanto de Gesbit como de Wordpress, si bien he añadido ciertos "Widgets" a este último, como pueda ser el que muestra las últimas entradas en la "barra lateral", puesto que Gesbit lo muestra de forma predeterminada. Lo mismo cabe decir para los últimos comentarios, la "nube de etiquetas", la lista de categorías, fechas, etc. Es decir, he tratado de ambos sistemas muestren información similar en cada uno de sus apartados, de modo que la comparativa fuera, al menos en este punto, más o menos realista.

Otra cosa más me gustaría añadir. Las cifras que se mostrarán a continuación son para los usuarios sin autenticar, es decir, para los lectores de una bitácora, pongamos por caso. Porque, si se trata de usuarios autenticados, a las cifras que daré habrá que sumar dos consultas SQL, en el caso de Gesbit, mientras que, en el caso de Wordpress, no habrá que sumar consulta alguna. Ignoro ahora mismo porqué Gesbit hace las mismas consultas SQL para usuarios autenticados y no autenticados, pero, el caso es que las cifras muestran las consultas necesarias para usuarios sin autenticar, y, como he dicho, Gesbit realiza dos consultas más (en cada apartado) para los usuarios autenticados, precisamente, porque ha de obtener los datos de dichos usuarios.

Sin más dilación, he aquí la comparativa en cuestión, que, después de lo dicho, igual queda hasta un poco ridícula. Sin embargo, puede verse cómo Gesbit realiza menos consultas SQL para mostrar similar información, y, además, persigue el objetivo de hacerlo de este modo: usar las menos consultas SQL posibles, de modo que luego podré añadir algo más a este respecto. Ahora vengan las cifras en cuestión, comparando el número de consultas SQL necesarias para conformar los distintos apartados de una bitácora en ambos sistemas:

Portada: GB 12 - WP 23
 
Entrada: GB 10 - WP 16
 
Página: GB 7 - WP 24
 
Categoría: GB 14 - WP 23
 
Etiqueta: GB 14 - WP 24
 
Autor: GB 13 - WP 23
 
Fecha: GB 12 - WP 23
 
Feed RSS: GB 5 - WP 13

¿Qué te parece? Como puede verse, en todos los apartados Gesbit realiza menos consultas SQL a la base de datos. A veces, como para el caso de mostrar entradas ("singles") la diferencia es de 6 consultas SQL, mientras que, para el caso de mostrar una página de la bitácora, Gesbit lo hace con 7 consultas SQL, mientras que Wordpress require 24. A todo esto he dicho que iba a añadir algo. Y es que, por ejemplo, esta bitácora que lees ahora, hace uso de varios plugins para Gesbit, empero, no suman en absoluto ninguna consulta más a la base de datos.

Efectivamente, dichos plugins hacen uso de las opciones "autoload", de modo que en una sola consulta se traen las opciones necesarias, tanto para Gesbit como para los plugins que lo requieren. Digo esto, porque, no ya sólo es que me he esforzado en mantener bajo el número de consultas SQL necesarias en Gesbit, sino que lo mismo he hecho mirando por los plugins y temas para Gesbit. En general, los plugins para Gesbit no suman consultas SQL a la base de datos de la bitácora, y tanto estos como los temas se pueden beneficiar del sistema de caché de consultas, que, hay que decirlo, creo que también existe en Wordpress.

Dicho todo esto, que conste que no sólo no tengo nada en contra de Wordpress, sino que, por el contrario, mucho que agradecer a sus autores, puesto que Gesbit utiliza prácticamente la misma estructura de base de datos que la de Wordpress (este asunto no es lo mío, desde luego), con pocos cambios, y también en Gesbit hago uso de ideas y hasta código fuente de Wordpress, algunas funciones, por ejemplo, están recogidas de este estupendo gestor de bitácoras, con el que acaso Gesbit no puede competir, no nos engañemos, ¡siempre que no hablemos del número de consultas SQL que ambos sistemas realizan!

De todos modos, para terminar, me referiré de nuevo a lo "científico" de la comparativa, que no tiene nada de esto. Por ejemplo, no conozco tanto Wordpress como para afirmar a ciencia cierta que estamos comparando cosas iguales. Dicho de otro modo, es posible que Wordpress cuente con alguna característica con la que Gesbit no cuenta, y es posible que dicha característica requierea el uso de la base de datos. En esta comparativa no he mirado estos "detalles". Me he limitado a hacerlo "por encima", porque, por encima, ciertamente, una portada es una portada, una entrada es una entrada, el archivo de etiquetas es lo que es, etc. Es por esto que considero esta comparativa como más o menos válida, pero, júzgalo tú mismo en todo caso. ;-)