Bitácora de Gesbit

Los temas y plugins para Gesbit incluyen en un archivo de información (XML) datos acerca del tema o plugin en cuestión, como pueda ser el nombre, autor, página web, etc. Uno de estos datos era la descripción de un tema o plugin, que, como el resto de ellos, se usaba para mostrarla en el panel de administración de Gesbit, en el formulario correspondiente. Este asunto ha tenido su miga, porque, al usar, directamente, la descripción de dicho archivo de configuración, esta no se mostraba traducida al idioma usado en Gesbit, sólo podía mostrarse en el idioma original.

En el caso de los plugins al cabo se ha dado una solución, de modo que ahora la descripción original se muestra sólo en el caso de plugins desactivados, mientras que para los activados, se da la oportunidad al desarrollador del plugin de retornar una descripción del mismo traducida al idioma en uso en Gesbit. En el caso de los temas, la solución no podía ser la misma, de modo que ahí seguía mostrándose la descripción original del tema, independientemente del idioma usado en Gesbit. Esto ha cambiado hoy mismo, con una solución salomónica, podría decirse.

Efectivamente, he quitado la descripción de los temas del formulario usado en el panel de administración de Gesbit para gestionarlos. De hecho he quitado dicha descripción de los archivos de información de los temas, vamos, que ya no es necesaria en absoluto. Ya sabes, muerto el perro, se acabó la rabia. Pero, lo cierto es que no he empezado así, quiero decir, primero he añadido algo que no había antes, y que ha venido a sustituir a la descripción. ¿No dicen que una imagen vale más que mil palabras? Entonces también más que la descripción de los plugins, que no podían ser tan extensas además.

Así que ahora los temas pueden incluir una imagen, de nombre "gbtheme.png" (como viene siendo habitual) dentro del directorio "images" del tema, y, esta será la imagen que muestre Gesbit en el panel de administración, que además ha sufrido algún que otro cambio. La imagen en cuestión, por supuesto, ha de ser una captura de una bitácora que use el tema, y las medidas de la misma habrán de ser 150 por 120 píxeles, que, es una de las que ofrece el sitio web Thumbalizr, con el que es posible capturar en una imagen una determinada página web. Y esto es todo lo que quería comentar en esta entrada. ;)

Un cambio reciente que creo que merece la pena ser comentado aquí. Como sabes, una de mis obsesiones en Gesbit es tratar la base de datos con cuidado, e intentar hacer las menos consultas SQL posibles. Estoy escribiendo el "tutorial para desarrollar plugins", y, en el mismo trato de exponer (con mis diez duros de inglés) cómo es posible utilizar la base de datos para guardar opciones, sí, pero, también que existen una serie de posibilidades para evitar hacerlo, y, que es una buena idea evitarlo, dicho de otro modo, que es una mala idea lanzarse a poner opciones como loco en un plugin.

Los "desarrolladores de plugins" tienen ya varias alternativas que Gesbit proporciona para no tener que recurrir a la base de datos. Incluso teniendo que utilizarla, Gesbit proporciona también varias alternativas a los desarrolladores de plugins. Sin embargo, había algo que no estaba contemplado, y que no sólo no es una mala idea, sino es que muy buena, y lo prueba el que no se me haya ocurrido a mí. Efectivamente, en algunos otros proyectos he podido verlo, y ha sido cuestión de estar escribiendo sobre el asunto para caer en la cuenta de que podía implementar algo así también. ¿Pero de qué estoy hablando?

Como sabes, todas las clases PHP en Gesbit pueden acompañarse de archivos con "constantes para la clase". Las clases de Gesbit se "autocargan", y, si junto al archivo de una clase existe un archivo del mismo nombre pero con cierta extensión especial (.const.php), Gesbit también requiere dicho archivo, de modo que las constantes definidas en el mismo están disponibles para la clase que las necesite, e incluso en otros lugares de Gesbit. Por ejemplo, muchas constantes definidas en el archivo para constantes de la clase "GbInput" son utilizadas a lo largo y ancho de Gesbit, hasta ahora, con buenos resultados.

Pues bien, los plugins para Gesbit también pueden aprovecharse de esta característica, y de hecho así lo hacen, así que podían definir constantes, además de las que ya definen, pensadas para ser "rellenadas" por los usuarios del plugin, de modo que este pudiera comprobar si dichas constantes tienen o no un valor adecuado, y, en caso de que sea así, no utilizar la base de datos de la bitácora, sino ceñirse a dichas constantes "de configuración". Efectivamente, esto era posible, pero, como digo, los plugins ya usan el archivo de constantes para definir las que necesitan, y no he visto bien mezclar ambos tipos de constantes: las que usa el plugin y las de su posible configuración.

¿Solución? Considerando que la idea era buena, la solución ha venido sola: de la misma manera que las clases de plugins pueden incorporar un archivo para constantes, que será requerido por Gesbit incluso justo antes de requerir la propia clase del plugin, de esa misma manera, digo, ahora los plugins también pueden incluir junto a ellos un archivo de configuración, que habrá de tener el mismo nombre que el archivo de la clase y el de constantes, pero, con la extensión ".config.php". Este archivo de configuración puede mantenerse "claro", incluir "instrucciones", definir constantes, en fin, con vistas a que lo haga el usuario del plugin.

A continuación y como ya he dicho, si el plugin comprueba que la constante o constantes correspondientes tienen valores apropiados, el plugin puede usar dichas constantes, en lugar de recurrir a la base de datos. De hecho, llegado el caso, cuando el usuario quiera ver el formulario de opciones del plugin (puesto que las constantes de configuración pueden ser opcionales) el plugin podrá informar al usuario de que no es necesario dicho formulario, pues ya se han determinado las constantes de configuración oportunas y el plugin hará uso de ellas. Es tan buena idea que, por supuesto, todos los plugins para Gesbit que yo mismo desarrollo hacen uso de este nuevo archivo de configuración para plugins.

Piénsese en el valor de algo así cuando se usaran muchos plugins. Efectivamente, yo uso trece o catorce en mi bitácora, gestionada con Gesbit, esta misma bitácora usa también varios plugins, y no noto ningún problema, todo va bien, las consultas SQL no ralentizan nada, en definitiva, pudiera pensarse que el archivo de configuración para los plugins no es en absoluto necesario. Y así puede ser. Pero, también es una forma de "estar preparados". De poder hacer las cosas de otro modo. PIensa que ahora sería posible tener instalados 200 plugins sin que estos tocaran en absoluto la base de datos, sin que necesitan consultarla, en fin, intentando aprovechar lo más posible los recursos disponibles. Sí, tal vez no sea necesario, pero, no está mal contar con algo así.

¿No te parece? Y bueno, eso es todo lo que tenía que decir. Ah, bueno, también que sigo escribiendo la documentación de Gesbit, incluyendo algunos tutoriales. Voy avanzando, pero, es una tarea que requiere bastante dedicación. Por supuesto, a veces sale trabajo de ahí, puesto que mientras estás escribiendo sobre algo estás dándole vueltas y así puede ocurrírsete alguna cosa que no esté del todo mal. Ah, y otra cosa. El dominio gesbit.com ha estado "caído" el día de ayer y hoy, pero, como ves ya está todo en marcha de nuevo. Era cuestión de realizar la oportuna renovación, pero, este tipo de cambios por lo visto no son automáticos, sino que llevan su tiempo y no puede hacerse sino esperar. Y ahora sí eso es todo. Que tengas un buen día. :-)

PD. Quisiera añadir algo. Por supuesto, nada impedía a un plugin para Gesbit requerir el archivo de configuración correspondiente. Pero, el "estandarizar" esto, el hacer saber que existe esta forma de hacer las cosas, hacerlo además sencillo (Gesbit se encarga de requerir el archivo de configuración automáticamente) es lo que considero más o menos reseñable. El asunto está en enfocar a hacer las cosas de una determinada forma, y no por mero gusto, sino porque se considera que de cierta manera las cosas son mejor para todos: desarrolladores y usuarios deben salir ganando y esto debe quedar tan claro que no quepan excusas. Y bueno, ya me callo. :D

Se veía venir. Desde que se introdujo en Gesbit la clase "GbTheme" para los temas, se veían venir una serie de, como lo diría, dizque mejoras, relacionadas con esta nueva posibilidad. En efecto, poco después de introducir la clase "GbTheme", esta contaba con "Actions" y "Printers", exactamente igual que los plugins para Gesbit. Pero, todavía tenía una espinita clavada: la activación y desactivación de los temas de Gesbit.

La activación y desactivación que ya existían para los plugins, están pensadas para que estos puedan llevar a cabo las tareas de instalación y desinstalación necesarias. En un principio todo esto se pensó por el afán en Gesbit por no dejar rastros en la base de datos una vez desinstalado un plugin que la ocupara de algún modo. Sin embargo, al cabo se llegó a una especie de "subsistema" que permite a los plugins usar acciones, y a Gesbit borrarlas automáticamente, luego de que el plugin en cuestión se desactive.

No obstante, los plugins no tienen porqué (aunque puede ser lo ideal) usar dicho "subsistema", y pueden por tanto llevar a cabo su propia instalación, y, sobre todo, su propia desinstalación. Ahora bien, los temas de Gesbit también podrían usar opciones, aunque, en mi opinión en menor medida que los plugins, e incluso estos a veces no las necesitan. Decía, que los temas pueden también necesitar de cierta instalación y desinstalación, y, hasta ahora, esto no era posible.

Había ya hecho algunos intentos, pero, sin éxito, hasta que, esta tarde, mientras estaba escribiendo un tutorial sobre Gesbit (luego comentaré algo sobre esto) se me ha ocurrido la idea que, sin acaso ser la mejor posible, permite que los temas se "enteren" de cuando son activados, y también, sobre todo, de cuándo son desactivados. Todo esto, por el momento, dejando todo esto como algo opcional, es decir, que un tema puede o no implementar.

Los cambios necesarios han consistido en lo siguiente. Como sabes, cada tema en Gesbit podía implementar, opcionalmente, una clase "GbTheme", que, ya podía contar con ciertos métodos, también opcionales, como "ActionCallback()" o "PrinterCallback()". En esto estamos igualando a temas y plugins, y en lo que viene también. Ahora cada tema puede implementar, opcionalmente, una clase del mismo nombre que el tema, otra vez, tal como hacen los plugins para Gesbit.

Dicha clase puede heredar o no de la clase "GbTheme", pero, en caso de hacerlo, la clase del tema habrá de implementar los métodos "OnActivateTheme()" y "OnDeactivateTheme()", puesto que son "abstractos" en la clase "GbTheme", y, en fin, a estos métodos llamará Gesbit cuando sea menester, es decir, cuando el tema sea activado o sea desactivado, respectivamente. Sobre todo esto quedan algunos flecos. Por ejemplo, no sé aún si hacer obligatorio que la clase del tema derive de "GbTheme". O si la propia clase ha de existir sí o sí.

Por el momento es opcional, tanto la clase del tema, como que esta derive de la clase "GbTheme", aunque, tal como he dicho arriba, estos métodos de activación y desactivación se declararon ya "abstractos" en la clase "GbPlugin", precisamente, para obligar a su implementación, para que, aunque no se usaran, se supiese claramente que podía (y aun debía) contarse con ellos en caso necesario. Pero, con los temas tal vez sea distinto, al fin y al cabo, será raro el tema que necesite guardar sus propias opciones, por ejemplo.

Pero, como digo, todo esto está en el aire. Parece claro que estos métodos han venido para quedarse, y en esto volvemos a aproximar los plugins a los temas, pero, tal vez se vea bien realizar ciertos cambios. Y bueno, para no aburrir, quiero terminar diciendo que al fin le he tomado el hilo al PhpDoc, y he visto cómo puedo incluir tutoriales en la propia documentación de Gesbit, que, últimamente estoy reescribiendo.

Estoy en ello y la idea es añadir unos cuantos. Entre otras cosas porque esto ofrece varias ventajas. Primero, la documentación la puede generar cualquiera a partir del código fuente de Gesbit. Segundo, los tutoriales pueden enlazar con la propia documentación de Gesbit, es de decir, se integran con la documentación. Y tercero porque todo queda en casa, y así me place. Así que en estas estoy. Ya lo sabes. :)

Otra de las cosas que me preocupan en Gesbit es la documentación que pueda y aun deba incorporar. Me estoy esforzando últimamente en preparar una documentación del código fuente que se muestre bien y sea realmente útil. La idea es que cualquier persona pueda adentrarse en el código fuente de Gesbit y comprenderlo más o menos perfectamente. Por supuesto, no he empezado ahora, y de hecho he dedicado mucho tiempo a la documentación, pero, es una tarea de nunca acabar.

Efectivamente, los cambios en el código fuente de Gesbit (que son constantes) implican cambios en la documentación del mismo, y, además, no todos los comentarios a modo de documentación que incluye el código es "consistente" como para presentarlo luego en el HTML que puede generar una herramienta como PHPDoc, que es la que uso para generar la documentación de Gesbit a partir de su código fuente. Quiere decirse que a veces esta no se presenta adecuadamente.

Esto es lo que me he propuesto cambiar, y en esto es en lo que estoy trabajando, si bien es una tarea un tanto más ingrata que cuando estás arreglando algún problema o añadiendo alguna funcionalidad o mejorando alguna existente. Sin embargo, ¿quién duda de que es importante? Porque además cada "script" en Gesbit tiene una razón de ser, se requiere allí donde es necesario únicamente (por alguna razón), en definitiva, es preciso comprender todo esto si se quiere uno adentrar en Gesbit a esos niveles.

Es una tarea más ingrata que otras, pues, como digo, está sujeta a cambios, que, a veces, echan a perder párrafos y más párrafos que dejan con los cambios de tener sentido. Aunque también es agradable darte cuenta de que tienes el sistema de Gesbit en la cabeza, que, funcione mejor o peor, está paso por paso, casi línea por línea de código metido en tu cabeza, como quien lleva más de un año trabajando sobre el mismo, claro está. Pues bien, lo agradable estriba en tratar de sacarlo de tu cabeza y explicárselo a otros mediante la documentación.

Y todavía no hablamos de la documentación para desarrolladores de temas y plugins para Gesbit, así como la relativa a la traducción del mismo a otros idiomas. Esta documentación habrá de separarse del código fuente, propiamente, aunque, a decir verdad, la idea es que al menos los desarrolladores de plugins para Gesbit puedan también conocer el sistema de Gesbit, más allá de los recursos que se les ofrece para llevar a cabo plugins para el mismo. Pues no sé, por ejemplo, tengo pendiente una especie de tutorial acerca de las "convenciones" usadas en Gesbit.

Total, que hay tarea por delante. Mucha tarea, a decir verdad. Pero, que, vamos poco a poco haciéndola. Debería ser cuestión de tiempo. Y mientras quede cierta ilusión seguiré adelante, desde luego, aunque sea con algo como la documentación de Gesbit y alrededor de Gesbit, que no es lo que más me agrada, como ya he dicho, pero, que, considero muy necesaria, realmente. Pienso, por ejemplo, en las capacidades de los nuevos entornos para trabajar con PHP. Efectivamente, estos entornos hacen buen uso de la documentación del código fuente, facilitando la tarea de desarrollar un determinado proyecto, en este caso Gesbit.

Una de las cuestiones a las que le ha dado y aun le daré más vueltas en Gesbit es la "autocarga" de clases, es decir, la implementación que se hace de la función "autoload" de PHP. Si eres lector de esta bitácora desde sus orígenes sabes que es así, y, efectivamente, sigo dándole vueltas al asunto y haciendo los cambios que me parecen más oportunos y elegantes, lo que, por supuesto, no quiere decir que sean así, sólo que a mí me lo parecen. ¡Pero funciona! ;)

Como sabes, las principales clases PHP utilizadas en Gesbit se "autocargan" cuando son necesarias, puesto que Gesbit tiene "controlado" qué directorios contienen las clases utilizadas, y así puede recorrer dichos directorios y requerir los archivos precisos. Esto es así desde un principio. Hace poco que los plugins también podían beneficiarse de esta "autocarga" de clases, y, hace menos aún, también los temas de Gesbit pueden hacerlo del mismo modo.

La implementación respecto de los plugins no era muy curiosa, para qué nos vamos a engañar. Añadí una función en el mismo "script" "autoload.php", de modo que se "juntaban" los directorios para classes de Gesbit, con los directorios correspondientes a los plugins instalados, siempre que existiesen. Ya aquí se echa de ver qué fallaba: se añadían todos los directorios, de todos los plugins, tanto activos como inactivos.

Claro está que eso no significaba nada en cuanto a consumo de recursos se refiere, de ahí que se quedara el asunto tal cual: al fin y al cabo funcionaba como se esperaba. Sin embargo, ayer mismo, cuando me propuse que los temas también pudieran contar con clases PHP "autocargables", el cómo lo hize fue por otros derroteros. Es el caso que no podía hacerlo como con los plugins, porque, cuando se añadían los directorios de estos, no puede saberse el tema "actual" de la bitácora.

Así pues, dejé encargada a la clase "GbThemes" de este asunto, de modo que en su constructor, y, una vez conocido el tema en uso en la bitácora, de añadir a la correspondiente variable global el directorio "pscripts" del tema en cuestión, siempre que existiese, porque ya sabes que es opcional. Ahora bien, ¿por qué no hacer lo propio para los plugins? Efectivamente, dejando a la clase "GbPlugins" esta tarea, para empezar, sólo se añadirán los directorios existentes de los plugins activos.

Y así lo he hecho. Aunque, ya puestos, he añadido una nueva clase a Gesbit, la claes "GbClassDirs", que, precisamente, utilizan ahora tanto la clase "GbThemes" como la clase "GbPlugins" para trabajar con la variable global correspondiente. Esto para abstraer un poco esta variable global, inicializada no de la forma en que suelen las otras variables globales de Gesbit, sino en el propio "script" "autoload.php", la primera vez que se ejecuta la función "__autoload()".

Total, que, como ves, no dejo de darle vueltas al asunto de la "autocarga" de clases PHP en Gesbit. Eso sí, creo que voy mejorando, aunque sea poco a poco. Ahora mismo, tanto Gesbit como los temas y plugins que lo compongan pueden utilizar esta característica para no tener que requerir los archivos de las clases por su cuenta y riesgo, sino que estos se requieran justo en el momento de necesitar una clase cualquiera.

Sigo dándole vueltas al asunto de la clase "GbTheme", de que he venido hablado en las últimas entradas, y, claro, cuantas más vueltas le doy más mejoras se me ocurren. Lo último es que los temas deberán situar la clase "GbTheme" (en caso de usarla) dentro de un subdirectorio "pscripts" en el directorio raíz del propio tema. Como digo, todo esto es opcional, tanto el subdirectorio como la clase "GbTheme" pueden no existir, y no pasará nada. Pero (aquí viene lo bueno) en caso de existir, el directorio "pscripts" será añadido a la variable global "gbClassDirs", lo que significa que las clases que se ubiquen en dicho directorio serán "autocargadas" por Gesbit justo en el momento de necesitarlas.

Quiere decirse que en el directorio "pscripts", los temas podrán situar no sólo la clase "GbTheme", que, tiene un tratamiento especial por parte de Gesbit (ejecuta sus métodos "ActionCallback()" y "PrinterCallback()", por ejemplo, si estos existen), decía, que, cualquier clase que siga la convención de nombres de Gesbit, que se sitúe en el directorio "pscripts", será "autocargada" por Gesbit, lo que significa en pocas palabras que el desarrollador del tema no tendrá que preocuparse de requerir las clases que necesite, sino que podrá usarlas sin preocuparse de nada más. Esto ya se hacía con los plugins, pero, no así con lo temas, que estaban un tanto "marginados".

Es lo que más me gusta de los cambios que últimamente estoy llevando a cabo en Gesbit: que los temas se acercan a lo que "pueden" los plugins para Gesbit. Evidentemente no son la misma cosa, pero, creo que puede resultar curiosa la clase "GbTheme", y de hecho se utiliza ya en los temas incluidos en Gesbit, y creo que también puede resultar útil la "autocarga" de clases que usen los temas mismos, para lo que les sea menester. Otras cosas pueden ocurrirse también en el futuro, basadas, quiero decir, en todo lo que se está haciendo ahora. Aunque sólo sirviera para lo que ahora ya está disponible me daría por satisfecho, pero, me temo que voy a seguir dándole más vueltas. ;-)