Integración de módulos en Drupal

Puede que usted alguna vez se haya preguntado, ¿Como puedo colaborar con esta comunidad inmensa? Puede que no se lo haya preguntado, no se preocupe, si pasa el tiempo suficiente utilizando Drupal, usted solo se dará cuenta de lo importante que es su aporte.

Si usted es programador, tal vez la forma más simple de colaborar sea creando módulos. Sin embargo, esto trae varios problemas aparejados.

En primer lugar, hacer un módulo entero puede resultar una tarea compleja. Estoy hablando de algo realmente útil, que tenga un propósito concreto y no sea un packman para Drupal.

En segundo lugar, incluso habiendo creado el módulo, usted debe tener la capacidad de dar soporte para sus módulos. A muchos desarrolladores de la comunidad les está pasando que poseen demasiados módulos para mantener y mejorar. Y simplemente no dan a basto.

Por otro lado, para programar un módulo completo hay que conocer muy bien como funciona Drupal. Si no, su módulo posiblemente sirva, pero será poco elegante y seguramente tendrá fallas de seguridad en varios lugares.

No quiero desanimar a nadie a programar sus propios módulos. Yo mismo a dos años de utilizar Drupal, y dedicarme casi exclusivamente a la programación, no he liberado mi primer módulo por las primeras dos razones citadas.

Entonces, ¿Qué hago?

Por empezar puede crear parches, los parches son fundamentales para alivianar la tarea a los desarrolladores.

Pero si realmente quiere hacer algo útil, y no quiere meterse con el núcleo de Drupal, lo que usted debería evaluar seriamente es... integración.

Integración de módulos.

Cada módulo puede permitir o no, que otros trabajen con él. Por ejemplo, views, le permite a todos los demás módulos crear plugins que interactúen con él.

A continuación veremos entonces, cuales son las principales formas de integración.

Integración con CCK.

Esta forma de integración generalmente supone la creación de nuevos campos o widgets para estos.

Un programador puede programar para el Kit de Construcción de Contenidos un parche para que, por ejemplo, el módulo fivestar sea un campo CCK. De hecho esto ya fue programado hace tiempo, así que tendrá que pensar en otra cosa :)

La integración con CCK trae dos ventajas fundamentales para cualquier módulo. Primero, una flexibilidad en la configuración desde el lado del usuario. Por el otro, una solidez en lo que refiere a seguridad del API utilizado en la integración.

Integración con Views

Atención, aquí hay mucho trabajo por hacer!. Views 2 permite en su nuevo diseño que los módulos creen sus propios plugins y handlers para integrarse con Views.

A mi criterio, el 80% de los módulos existentes para Drupal podrían tener por más pequeña que sea, su integración con views.

¿El módulo almacena algún tipo de dato útil para el usuario? Pues permita listarlo con views. Y además utilizar ese valor para filtrar listados.

Existen muchísimos módulos que aún no tienen soporte, solo es cuestión de buscar la frase “Views integration” en Drupal, y verá una lista de las tareas disponibles.

Integración con Mailhandler.

Este módulo tal vez sea desconocido por algunos. Permite la creación de contenidos a través del procesamiento de emails en una casilla de correo.

Esto quiere decir, usted envía un mail a la cuenta x. Y al poco tiempo ese email es convertido en un nodo en un sitio en particular.

Un ejemplo de integración con este módulo el Messaging. Un sistema fabuloso de mensajería para Drupal. Haciendo uso de Mailhandler evita reescribir código.

Usted puede crear parches para integrar otros módulos a mailhandler. Especialmente a la hora de reconocer comandos encerrados entre [corchetes]

No recuerdo si ya está implementado el rellenado de campos CCK con este tipo de comandos.

Integración con Imagecache.

¿Le gusta el diseño gráfico? Tal vez haya creado algún tipo de proceso que permita modificar imágenes al vuelo. Supongamos, pasar una imagen a un formato tipo polaroid. Recuerde que ImageCache es el módulo encargado de proveer un API para este tipo de procesamientos.

Extendiendo ImageCache le da la posibilidad a los administradores de aplicar más filtros sin la intervención del usuario.

Integración con Voting API:

Hoy en día es común ver sitios con encuestas complejas en los sitios web. Preguntas que dependen de otras, o formas de votación complicadas.

Recuerde que cualquier módulo que termine o empiece con API, seguramente le dará soporte para extender y hacer uso de su código.

Voting API permite justamente extender el sistema de votaciones. Un ejemplo claro de integración con este módulo es Advanced Poll. Que extiende las opciones para encuestas.

Integración con Rules:

Otro ejemplo magnífico de modulo extensible es Rules. Como indiqué en este video Rules permite ejecutar acciones cuando un evento se dispara y se cumplen ciertas condiciones.

La buena noticia es que los eventos pueden crearse. Por ejemplo, usted podría crear un nuevo evento que se dispare cuando un contenido es traducido a un idioma determinado. O cuando una revisión es aprobada con node revisions, o cuando un usuario cancela su voto con advanced poll. Los eventos que puede crear son incontables.

Pero además también puede programar condiciones. Por ejemplo, usted puede programar una condición para evaluar si un usuario votó o no en una encuesta determinada.

Por último puede programar acciones. Las acciones estarán íntimamente relacionadas al módulo que las provea. Por ejemplo podría crear una acción para generar un pdf a partir del contenido de un nodo. Lo que se le ocurra.

Notas sobre la integración:

Los códigos de integración deberían figurar en los módulos que los implemententen. Esto es, si usted está programando una integración del módulo fivestar con views, el código de integración estará incluido obviamente en el módulo fivestar.

Sin embargo esto no siempre es así. Existen dos casos en los que se rompe este mecanismo y la integración se incluye en un modulo distinto al que se debería.

Primero, si su módulo implementa una característica realmente importante y novedosa para un sitio, como por ejemplo views, cck, o i18n, todas las integraciones con los demás módulos de su categoría, deberán incluirse en el mismo módulo. Por esta razón, la integración de cck con views está incluída en views y no en cck. ¿Por qué? Bueno, porque es demasiado trabajo para los desarrolladores de cck escribir todo el código para la integración con views, y además, ¿que sucede si en su sitio usa cck pero no views?

Y en segundo lugar, la integración de algún módulo del núcleo de Drupal no puede incluírse el el core. Suponga que quiere integrar el módulo blog al módulo rules. Es simplemente impensado que en el núcleo de drupal figure una implementación del un hook de rules. En ese caso, rules deberá incluir en su propio código las instrucciones necesarias para integrar blog a rules.

Manos a la obra.

Si le pareció buena la idea, simplemente ingrese a la página de proyectos de cada módulo y vea que integraciones son solicitadas o están en desarrollo.

En la mayoría de los casos, una integración con otro módulo es la implementación de un hook provisto por el propio módulo extensible.

Por ejemplo, para implementar un nuevo evento con rules, bastará hacer: