Bitácora de Gesbit

Siguiendo el hilo apuntado en esta y esta otra entradas, por fin me he decidido a implementar el nuevo tipo de "evento" ante el que los plugins que lo necesiten podrán "actuar". Gesbit ya cuenta con "printers" y "filters", que aprovechan varios de los plugins disponibles actualmente, pero, era preciso incorporar un nuevo tipo de "evento", que he dado en llamar "action", y, que, por supuesto tiene características que no ofrecen los "eventos" conque hasta ahora se podía contar.

Con las acciones he dudado más, y, me sorprende que, después de varias pruebas, terminase implementándolo (de momento) tal y como lo tenía pensado casi desde un principio. O bien no he sabido ni podido ir más allá, o bien lo que se me ocurrió al principio (y luego de darle algunas vueltas, como digo) podría servir perfectamente. El código que puedes ver a continuación es el encargado de ejecutar las acciones en los plugins que lo precisen, luego trataré de describirlo.

public function ApplyAction($actionID, $args = array()){
  $results = array();
  if(!empty($this->pluginObjects)){
    foreach($this->pluginObjects as $gbPlugin){
      $method = GBPLUGINS_PLUGIN_ACTIONCALLBACK_METHOD;
      if(method_exists($gbPlugin, $method)){
        $pluginID = strtolower(get_class($gbPlugin));
        $results[$pluginID] = $gbPlugin->$method($actionID, $args);
      }
    }
  }
  return $results;
}

Como puede verse las acciones se distinguen claramente de los "filters" y "printers", en que estas pueden recibir ciertos argumentos, y, además, el "resultado" de los plugins cuenta, se guarda, para poder ser utilizado por Gesbit en caso necesario. Aquí estriba la mayor dificultad de las acciones, y es que, a diferencia de los otros "eventos", estas tendrán características diferentes, aunque su implementación es generalista, por decirlo así.

Dicho de otro modo, un "filter" no cambia: los plugins obtienen el identificador de un "filter", y también el "contenido" a filtrar. Esto no cambia, siempre es así, y no hay dudas acerca de cómo trabajar. Lo mismo pasa también con los "printers". Los plugins son informados de que en un lugar determinado es posible "escribir" código, principalmente HTML, y tampoco hay vuelta de hoja aquí: los plugins escriben o no el código necesario atendiendo al "filtro" correspondiente.

Pero las acciones son algo distinto. Una acción, por ejemplo, puede no necesitar argumentos, y, de este modo, el plugin no recibirá argumento alguno. Una acción puede necesitar argumentos, pero, tal vez no haga uso del resultado de aplicar las acciones sobre los plugins. Por último, y en general, diferentes acciones pueden necesitar diferentes tipos de argumentos, y Gesbit podrá estar o no al tanto de los resultados de diferentes acciones, según sea o no necesario.

En realidad, pienso que no debería haber mayores problemas, siempre que las diferentes acciones que puedan llevarse a cabo, estén perfectamente documentadas. El desarrollador de un plugin no necesitará conocer todas las acciones, o, al menos, bastará con que conozca aquella o aquellas que necesite para su plugin. De momento he pensado en documentar las acciones en el mismo "script" en que se definen las constantes relacionadas, puesto que cada acción tendrá una constante (identificador) diferente.

También procuraré, si todo esto sigue adelante, documentar en la wiki de Gesbit todo este asunto. De hecho pienso que puedo aprovechar ya mismo parte del texto de esta entrada, aunque sea para dejar una pequeña referencia sobre la posibilidad de utilizar estas "acciones" en Gesbit. Si todo va bien, más pronto que tarde verás algún plugin que haga uso de las acciones de Gesbit. Mi intención es comenzar a usarlas para un posible plugin que utilizara el servicio de Defensio, para tratar de automatizar el reconocimiento de SPAM en las bitácoras.