PHP

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:

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.