Hace pocos meses se ha publicado la versión 8 de Drupal. Llevo trabajando con Drupal de forma profesional desde hace ya diez años. He tocado todas las versiones desde la 4.7 que empezó a ganar notoriedad hasta la actual.

Esta serie de posts quiero que sirva para que la gente que ha trabajado programando con versiones viejas de Drupal, encuentre el camino a seguir en Drupal 8. Si además consigo que la gente que entra a Drupal 8 directamente aprendan algo también, mejor.

Dicho esto, vamos a ponernos manos a la obra…

(Muy) Breve introducción a Drupal

Siempre que tengo que introducir Drupal a alguien lo hago de la misma forma: Es un CMS mezclado con un framework de programación. Hasta Drupal 8, esta definición era un poco ambiciosa. La programación en Drupal 7 era (es) principalmente procedural. Drupal 7 se basa en una API constituida de “hooks” que son funciones que se llaman durante la ejecución en momentos concretos de la misma. De esta forma, el programador puede intervenir en el pipeline de ejecución y alterar el input para añadirle las funcionalidades que sean necesarias.

Este concepto es algo muy sencillo de entender con pocos ejemplos y hacía que la curva de entrada a programar en Drupal fuera muy baja. Esto a nivel de programación, claro. A nivel de sistema, Drupal ha tenido históricamente una curva de aprendizaje bastante jodida. En otras palabras, programar en Drupal 7 es muy sencillo si sabes hacer scripts tontos en cualquier lenguaje. Hacer las cosas de forma correcta para obtener la funcionalidad deseada, es otra historia completamente distinta.

La susodicha curva

No todo el monte es orégano

Lo de Drupal fue una genialidad. Ha aliviado mucho trabajo a las plataformas desarrolladas con ese sistema en cualquiera de sus versiones. En lugar de tener que montar un CMS desde cero en un lenguaje concreto, tenias ya uno hecho que te gestionaba usuarios, acceso, contenidos, taxonomías, etc. Solo necesitabas darle algunos toquecitos de programación para tunearlo. Además venía con un motor de templates propio (PHPTemplate) que te permitía poder jugar con el aspecto de los distintos elementos. Construir un site de gestión de contenidos muy personalizado era fácil con Drupal (Si tenías los desarrolladores adecuados, claro).

Pero a medida que Drupal y el desarrollo web han ido creciendo, los hooks de Drupal se han ido quedando cortos. Con ellos no todo se valía, no todo se podía hacer. Los módulos que hacían cosas chulas eran monstruosos de ver en código (alguien dijo Views?). Muchas veces, por la salud mental del que los hacía, se acaban programando usando orientación a objetos que luego se enchufaba a los hooks de Drupal.

Además, la adopción progresiva de Drupal por parte de organismos importantes (NASA, White House, grandes empresas multinacionales, Comisión Europea, Naciones Unidas, etc.) hicieron que el software necesitase convertirse en mas robusto. Eso significa metodologías de programación que aseguren calidad como testing, despliegue automatizado, etc. Si alguno de vosotros ha intentado hacer esto en Drupal 7, sabrá el berenjenal que es. No es imposible hacer tests en condiciones con Drupal 7, pero si innecesariamente complejo y no todo puede testearse. Pero ya hablaremos de esto más adelante.

Drupal 8 y el “nuevo” paradigma

Los desarrolladores de Drupal tenemos mucho trecho que recorrer para ponernos a la misma velocidad que el resto del mundo. Para nosotros, la orientación a objetos es algo nuevo que no habíamos tocado a penas. Quizás lo habíamos visto en algún módulo hecho por alguien con más conocimientos, pero no era algo que nos preocupase en nuestro mundo de hooks.

Drupal 8 ha venido a cambiar esto. Adoptando algunos de los componentes de Symfony y apostando por una arquitectura completamente orientada a objetos, Drupal 8 ha cambiado drásticamente la forma de programar en este sistema. De pronto hay que aprender qué son los namespaces y como se usan. Que es el autoloader. Por qué hay que meter tantos “use” al principio del archivo. Que es la inyección de dependencias. O por qué narices necesito escribir una interfaz en lugar de una clase directamente…

Pero creedme, es para mejor.

¡No hay que tener miedo!

Primero, no es tan difícil como parece. De verdad, son una serie de conceptos extraños de entrada, pero lo bueno de la orientación a objetos es que suele ser muy intuitiva. Además, las ventajas que proporciona la orientación a objetos compensan sobradamente los problemas de aprender las cuatro tonterías que hay que aprender.

Os imagináis poder substituir una parte del Core sin afectar al propio Core y sin liar un cristo de código ininteligible? Poder hacer testing unitario y de integración sin tener que cargar todo el sistema en memoria? Tener el código perfectamente organizado en distintas clases fácilmente reconocibles en lugar de un solo archivo de 1500 líneas?

Pues eso es sólo es lo que ganáis como programadores. Sumadle un sistema de caching mucho más trabajado, que funciona por distintos trozos en lugar de solo por página y para usuarios autenticados. Sumadle que el sistema ya no necesita tener todo el código de todos los módulos cargado en memoria como pasaba en Drupal 7 y anteriores.

Todo eso es posible gracias a la orientación a objetos. Y en los siguientes artículos os explicaré todos sus conceptos e ideas que se utilizan en Drupal 8, usando ejemplos reales.

Vamos, venid conmigo. Seguro que los disfrutaréis.


Deja un comentario

Entradas relacionadas

Drupal

D8 para D7 developers: Namespaces

En este primer capítulo vamos a ver los namespaces en PHP y Namespaces de PHP en Drupal, un concepto básico de orientación a objetos. Si ya sabes de que van los namespaces y el autoload, Leer más…

A %d blogueros les gusta esto: