Cuando lees un artículo de una nueva API normalmente la gente se suele copiar en los ejemplos, o a lo sumo desarrolla uno de ellos un poquito más, es raro hablar de una Bundle Class o lo que se ha programado en ella ya que suele ser parte de la lógica de negocio.

Este texto son unas reflexiones de Statu en el Slack de Drupal-es en el que termina encontrando otra "aplicación" práctica para resolver una feature y obviamente implica implementar métodos en una Bundle Class.


El problema:
 

Ando escribiendo un módulo, el cual tiene varios formularios de configuración, y no se me ocurrió otra cosa que crear un formulario base que inyecta todas las dependencias necesarias (de todos los formularios), y a la vez tiene varios métodos además de los métodos estandar de los formularios de Drupal, de tal forma que el resto de formularios únicamente tendrían que extender este formulario para usar los métodos adicionales añadidos y sobreescribir los métodos comunes de los formularios con sus métodos propios.

Desde un punto de vista de DDD se puede justificar en que queda todo dentro del dominio que representa la funcionalidad concreta de ese módulo, pero no terminaba de gustarme la idea de tener un formulario sobrecargado de métodos para que luego el resto de formularios mediante la extensión pudiesen usar los métodos que implementa el formulario padre ya que yo creo que rompe el principio de responsabilidad única al ser sobrecargado con métodos que en algunos casos comparten el resto de formularios pero en otros casos no.

Es por eso que en un principio pensé en hacer una clase de tipo Helper y crear métodos estáticos pero en ese caso me pasaba un poco lo mismo esa clase era un poco como un cajón desastre donde meter todo aquello que no tenía claro donde poner, así se me ocurrió que en vez de eso podría usar Functors 

Así que vamos con el código.

Como se puede ver, de esta manera podemos tener múltiples Functors que al ser definidos como servicios no solo se pueden usar en el módulo sino que el día de mañana otro módulo podría llamar también a esos servicios, cada Functor únicamente se encargaría de su propia lógica (Principio de Responsabilidad Única), y simplemente se tienen que inyectar en los formularios.

Hux es módulo que permite escribir módulos de Drupal sin necesidad de usar el archivo *.module, me han comentado que únicamente para algunos hooks que hacen referencia al tema sería necesario usar el archivo *.module, me queda por comprobar eso.

Uno de los requisitos importantes de Hux es que es necesario usar PHP 8.x ya que usa anotaciones en los métodos de las clases que se crean, otro de los requisitos es que solo se puede usar a partir de la versión 9.4 de Drupal, o en su defecto la 9.3 con un parche que existe, ya que para hacer posible el funcionamiento del módulo hubo que modificar el core de Drupal.

¿Qué nos permite hacer Hux? Con Hux podemos mover los hooks del archivo *.module a clases dentro de la ruta /src/Hooks del módulo custom que se esta desarrollando, de esta forma en vez de tener un archivo *.module gigantesco lo separaremos en archivos mucho más pequeños y nos permite organizar mejor el código, con Hux podemos usar una o más clases para escribir nuestros hooks, tenerlo todo en una única clase que simule el viejo *.module es posible, pero también podemos tener varias clases el como o que tiene cada clase ya queda a decisión de cada uno, se puede ordanizar pensando en entidades de Drupal, se puede organizar el código pesando en DDD, o como queramos ya que ahora no estamos obligados a usar el archivo *.module (menos los hooks de temas).

Otra de funcionalidades que tenemos es que podemos invocar el mismo hook varias veces en la misma clase o en clases diferentes y gracias a esto mantener el principio de responsabilidad única cada vez que se invoca el hook; un ejemplo de esto sería un tipo de contenido que quiere definir varios pseudofields, en vez de tener todos los pseudofields en 2 hooks, se puede tener una clase por cada pseudofield y en esa clase declarar los hooks necesarios para cada uno de los pseudofields.

En este artículo se explica mejor que se puede hacer con el módulo, y el archivo Readme.md del módulo
 

Estos últimos meses al actualizar versiones de PHP me ocurría que el debug dejaba de funcionar en VSCode y hasta ahora no he podido trastear con ello para ver que estaba ocurriendo.

Precisamente, mirando el docker-compose de este blog al cual si funciona bien el Xdebug lo que vi es que en el docker-compose.override.yml lo tenía diferente respecto al que tengo en algunos proyectos donde no me fuciona.

Lo que he probado y funciona es añadir este código:

Hux es un modulo que permite que dejemos de usar (parcialmente) los hooks en el archivo *.module de Drupal y usar en su defecto clases, en este artículo explican como funciona el módulo: https://www.previousnext.com.au/blog/hux-alternative-to-hooks

He jugado un rato para aclarar dudas:

 

Se pueden usar hooks genéricos que afecten a todas las entidades o filtrando por bundle (entre otras cosas).

se pueden usar hooks más específicos que afecte a una única entidad.

A la hora de organizar el código de nuestros proyectos es una gran ventaja, ya no tendremos todo el código en el archivo *.module, podemos tener múltiples clases dentro del directorio src/Hooks y cada una de esas clases que recoja un único hook, o tener varios hooks por clase, además puede ser un buen punto de partida a la hora de "agrupar" el código pensando en DDD o agruparlo por entidades, ya que a veces en proyectos custom no se visualiza el código agrupado de esta manera sino que simplemente se van creando módulos que resuelven una necesidad.

Mi antiguo compañero en TCK, Nando, siempre me decía que el código tiene que ser lindo, que tenemos que escribir código como si escribieramos una novela, que sea un disfrute leer el código.

El otro día veía con un compañero porque PHPStan daba un error, y al final para resolvermos optó por un clásico:

$values = $entity->get('field_name')->getValue();
$uri = $values['uri'];
$title = $values['title'];

El caso es que me dió por buscar alternativas a esas líenas de código y en esto que encontré dos funciones de PHP con las que me puse a trastear un rato, list() y extract().

List con un array con índices:

Lo que vemos es que list no funciona con un array que tiene definidos índices para los elementos que lo componen.

Pero vemos lo que ocurre cuando es un array sin índice:

En entes caso funciona como un guante

Si hemos visto que con la función list solo funciona los arrays sin índices definidos, ahora con extract ocurre todo lo contrario:

No podemos negar que queda mucho más lindo el uso de list() o de extract(), según el caso, para pasar los valores de un array a variables.

El otro día me pedían que analizase la petición de un cliente, el cliente planteaba la necesidad de realizar una teréa periódica de forma manual, no llevaría más de 2 o 3 horas como mucho, una vez al mes, y otra tarea anual que llevaría unas cuantas horas, pero que en cómputo general entre las dos tarenas no supondría más de +-40 horas.

Las tareas a realizar son:

• Generar un informe.
• Subir el informe a un directorio en un servidor.
• Comunicar por correo electrónico la ejecución de la tarea.

Eso a todo el mundo le puede parecer perfecto, tareas que se repiten 1 vez al mes, pero uno de mis muchos TOCS es la automatización de tareas, sobre todo cuando son tareas repetitivas, mecánicas y que se pueden programar, así que me puse a pensar como sería la forma más sencilla para montar un robot que ejecutase la tarea.

Montar un robot en PHP es sencillo, existen varios "task runners", posiblemente el más conocido de todos ellos es Robo.li, pero existen otras alternativas como programar comandos en Symfony con una instalación mínama o en otro caso se puede plantear con algún otro microframework que trabaje con CLI como Minicli, en resumen programar la ejecución de las tareas será entretenido ya que será código puro y nada de front-end.

A lo que más le di al coco era a la arquitectura de sistemas, y veía tres opciones, un proyecto web levantado todo el rato que se ejecuta con un cron definido, un proyecto web que se levantase bajo demanda la arquitectura y que una vez finalizado se apaga, pero aunque esta apagado siempre esta encendido esperando una petición, un entorno efímero que se levanta para ejecutar la tarea y luego se vuelve a caer,  el sistema se levanta cuando se tiene que ejecutar la tarea y luego se apaga el entorno y no es accesible.

Para mi las ventajas de un entorno efímero son los siguientes:

• Se levantan los entornos únicamente cuando se tienen tienen que llevar a cabo las tareas, luego se apagan, y no vuelven a ser accesibles, más seguros.
• Al esta apagados consumen menos recursos del sistema dejando recuros para otros proyectos que si necesiten estar levantados todo el rato.

Las desventajas que le veo

• Al ser un entorno completamente en PHP-CLI es más dificil de depurar, pero no imposible.
• Al ser un entorno efímero posiblemente no existirá una bbdd, la mejor opción en esos casos habría que ver como registrar los logs del sistema en algún lado.
• Es necesario tener un cron-job que levante todo el entorno, ejecute el proceso y luego vuelva a apagar todo.
• Seguramente se tenga que construir uno o más contenedores de Docker para llevar a cabo todas las tareas.

La propuesta de arquitectura es sencilla:

Este artículo se sale de lo que quería que fuese el blog, algo más centrado en tecnología y dejar el resto de lado, al final parece que no puede ser.

Hace años que me conozco a mi mismo, se que soy un bocazas, y también se que suelo soltar las cosas directas, crudas, y sin "suavizar", soy nieto de mi abuela, eso no lo puedo negar.

Una vez contextualizado al autor vamos con el artículo.

La comunidad de Drupal llevaba desde 2019 parada, incluso en el caso de Madrid la comunidad local llevaba algo más de tiempo parada, las responsabilidades de las personas que tiraban de la comunidad había hecho que no se hicieran tampoco muchas D&B (si no damos una charla por lo menos hacer un poco de terapia de grupo).

En eso que aparecieron dos personas hace relativamente poco y montaron un grupo de Meetup dedicado a Drupal, todos los grupos locales de meetup se habían movido a los grupos de drupal (este es otro melón que un día de estos tendremos que retomar). Genial, dos personas con ganas de hacer cosas.

Los problemas que veo yo a lo que están haciendo:
 
Primero los títulos de las reuniones "Drupal esta muerto", y "Cómo sobrevivir a Drupal", son dos títulos que no hay por donde cogerlos, parecen artículos de opinión de un periódico en el que se paga al "opinador" por las veces que se visualice la página y no por la lectura del artículo.
En comunicación una regla no escrita dice que los títulos negativos no se deben usar; el problema es que de 100 personas que vean el título de la charla 90 se quedan con el título, 10 entran en la charla y solo 1 aporta o participa. No es bueno dejar ese poso en Internet porque normalmente esas cosas se quedan ahí y luego la gente la va a recuperar, pongamos un ejemplo una persona que quiere decir que hacer con su futuro como programador y lee una entrada que pone "Drupal esta muerto" ¿Creéis que realmente se molestará en indagar mas? No, se quedará con la idea en la cabeza e irá a buscar otras opciones laborales.

Normalmente trabajo con Wodby 4 Drupal como la base para levantar mis proyectos de Drupal en local, y en entornos de desarrollo, hasta ahora había usado Behat para hacer testing, es una herramienta que me gusta, y que considero que esta muy bien, pero había leído cosas buenas de Cypress, y quería probarlo, y cuando descubrí que además se podía integrar con Cucumber pues mucho mejor.

Cypress es una herramienta Javascript de end-to-end testing. En otras palabras, permite comprobar que el funcionamiento de un producto de software recién desarrollado sea buena y corresponda con los requerimientos iniciales.

Cucumber es una herramienta de software que apoya el desarrollo impulsado por el comportamiento. En el enfoque de Cucumber BDD es fundamental su analizador de lenguaje ordinario llamado Gherkin. Permite especificar los comportamientos esperados del software en un lenguaje lógico que los clientes puedan entender.

Poder usar Cucumber por un lado para seguir la metodología BDD y por otro lado con Gherkin hacer partícipe al cliente de las pruebas que se escriben para el proyecto me parecía que era una doble victoria, así que me puse manos a la obra para hacerlo funcionar.

El éxito de todo esto se lo debo a este artículo y a los otros cuatro artículos escritos por Soraia Reis Fernandes que me ayudaron ha realizar una inmersión en Cypress primero y luego en Cucumber, y por último como integrarlo todo en Docker.
 

Lo cierto es que yo únicamente he trasteado un poco con las rutas para adecuarlo a Wodby 4 drupal, en un segundo artículo hablaré de otras cosas que he investigado, artículos sobre Cypress + Drupal que he leído y módulos que hay de Drupal para ejecutar test de Cypress.

He subido un proyecto aquí con todo lo que se necesita para empezar a trabajar con Cypress + Cucumber en Wodby 4 drupal.

La situación es la siguiente, en un proyecto es necesario subir archivos pdf, algunos de los cuales pueden llegar a subir hasta 700 megas, con ese peso tanto para subir como para servir el documento no es viable usar Apache/Nginx/PHP, se puede usar pero no es la opción más óptima, para solventar esto vamos a proponer usar un sistema de almacenamiento como es el caso de S3.

La wikipedia define S3 de la siguiente manera:
 

Amazon S3 o Amazon Simple Storage Service es un servicio ofrecido por Amazon Web Services que proporciona almacenamiento de objetos a través de una interfaz de servicio web.

En el caso de Drupal tenemos dos módulos que nos ayudarán con lo que queremos conseguir, por un lado esta el módulo S3 file system y por otro el módulo S3 file system Cors.

Configurar S3 file system

Tenemos que recordar que el sistema de Files de Drupal   por defecto nos permite configurar entre público o privado en /admin/config/media/file-system

Image

Para hacer nuestro truco tenemos que añadir la siguiente configuración del módulo S3 file system

Image

Ponemos a False s3fs.use_s3_for_public porque no queremos que Drupal delegue en el S3 todos los archivos que tenemos dentro de la carpeta files, sino que solo los archivos de los campos que nosotros queremos. 

Si volemos a cargar la página del módulo de file system veremos lo siguiente: