<?xml version="1.0"?>
     <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
     <channel>
      <link>http://www.bitacora.gesbit.com/</link>
      <title>Bitácora de Gesbit - Entrada "Al hilo del plugin GbDefensio" de la bitácora</title>
      <generator>Gesbit</generator>
      <description>Bitácora del gestor de bitácoras</description>
      <atom:link href="http://www.bitacora.gesbit.com/rss/" rel="self"
       type="application/rss+xml" />
    
      <item>
       <link>http://www.bitacora.gesbit.com/al-hilo-del-plugin-gbdefensio/</link>
       <guid>http://www.bitacora.gesbit.com/al-hilo-del-plugin-gbdefensio/</guid>
       <pubDate>Fri, 01 Aug 2008 00:30:48 +0200</pubDate>
       <title><![CDATA[ Al hilo del plugin GbDefensio ]]></title>
       <description><![CDATA[<p>Al hilo del plugin GbDefensio, que presentaba <a title="Entrada en esta bitácora" href="http://www.bitacora.gesbit.com/introduciendo-el-plugin-gbdefensio/">ayer mismo aquí</a>, he llevado a cabo algunos cambios en el sistema de plugins de Gesbit, si se me permite llamarlo de esta forma tan... tan... en fin, de alguna forma hay que llamarlo. Uno de los cambios que más pueden llamar la atención es que ahora no es necesaria ninguna función "para registrar" los plugins. Esta función, que tenían que implementar los plugins en el archivo de su clase principal, ya no es necesaria.</p>
<p>Quiere decirse que Gesbit se encargará, como antes, de requerir el archivo correspondiente, y, en lugar de buscar en él una función "de registro", buscará la clase del plugin, y, si la encuentra, sencillamente, la instanciará en un objeto, tal como hacía, pero, sin necesidad de la función de registro, como queda dicho. Otra de las novedades es que Gesbit se encargará de requerir un "archivo de constantes" para los plugins, si es que dicho archivo existe.</p>
<p>En Gesbit, por costumbre de su desarrollador principal (permítaseme llamarme a sí a mí mismo, yo me lo guiso, yo me lo como) por cada clase puede corresponderse un archivo de constantes, en que se defienen constantes, precisamente, relacionadas con el plugin y para su uso exclusivo, pero, también para poder usarse fuera del plugin, si es menester. En Gesbit, internamente, se hace un prolijo uso de estos archivos "de constantes", y pensé que sería buena cosa para GbDefensio.</p>
<p>Como sabes, los plugins para Gesbit han de implementar una clase que herede de la clase "GbPlugin". Dicha clase se implementa en un archivo "nombre-plugin.class.php", que se ha de encontrar en el directorio del plugin, que ha de llamarse "nombre-plugin", y ser un subdirectorio del directorio de plugins de Gesbit. Pues bien, si Gesbit encuentra en el directorio del plugin un archivo "nombre-plugin.const.php", lo requerirá justo antes de requerir e instanciar la clase del plugin.</p>
<p>He pensado también si sería bien dejar los métodos "OnActivatePlugin" y "OnDeactivatePlugin", de la clase "GbPlugin", como públicos, en lugar de como "abstractos", de forma que los plugins que no los necesiten, no tengan que declararlos, puesto que de no hacerlo obtendrían el error correspondiente. Sin embargo, creo que la intención primera sobre estos métodos todavía se mantiene: que el desarrollador sea consciente de que debe instalar y desinstalar su plugin limpiamente, y para eso cuenta con las herramientas necesarias.</p>
<p>Un buen ejemplo de uso de ambos métodos es, precisamente, el plugin GbDefensio. Este, además de necesitar guardar alguna que otra opción en la base de datos de Gesbit, "altera" la tabla de comentarios de la base de datos, añadiendo un nuevo campo, donde a su vez guardará información relativa a los comentarios. Pues bien, GbDefensio es el ejemplo perfecto de cómo se prepara lo necesario en la base de datos de Gesbit, cuando el plugin se activa, o se instala, y de cómo se desinstala cuando llega el momento.</p>
<p>Quiere decirse que GbDefensio aprovecha el método "OnActivatePlugin" para preparar la base de datos de Gesbit, la tabla de comentarios, y, como debe ser, hace uso del método "OnDeactivatePlugin" para dejar la base de datos tal como se la encontró cuando se instaló, para eliminar de la misma el campo que añadiera a la tabla de comentarios. Sobre esto me interesa prestar mucha atención, porque, ¿para qué hacer las cosas mal si pueden hacerse bien? Siempre en la medida de las posibilidades de cada quien, por supuesto.</p>
<p>En fin. Para terminar esta ya larga entrada, diré que he seguido hoy trabajando en el plugin GbDefensio, y que he conseguido algunas mejoras nada desdeñables. Una de las cosas que me preocupaban era el uso de la base de datos por el plugin, y de ciertas consultas que ha de realizar. Pues bien, creo que al cabo he perdido el miedo al uso de la base de datos, puesto que he comprobado que el plugin puede instalarse y desinstalarse limpiamente. Y, respecto a las consultas a la base de datos que ha de llevar a cabo, hoy he ahorrado alguna, y creo que lleva a cabo las mínimas necesarias.</p>
<p>Quizá mañana o pasado publicaré por fin el plugin GbDefensio, y hasta me plantee utilizarlo en mis bitácoras, aunque, como ya he dicho en ocasiones, en parte por el "CAPTCHA" que se incorpora en Gesbit "de serie" (aunque es opcional) y en parte porque mis bitácoras son poco visitadas, estoy completamente libre del SPAM, y que dure mucho tiempo. Podría añadir que he estado trabajando también en un "CAPTCHA" alternativo, que no use imagen alguna, y que algo he avanzado, pero, ya he dicho una vez que esta entrada es ya demasiado larga, así que lo dejaré para otra ocasión.</p>]]></description>
      </item>
      
     </channel>
    </rss>