En un tutorial anterior, analizamos el sistema de complementos de Drupal 8 y cómo crear nuestro propio tipo de complemento personalizado. Hemos visto que gran parte de la funcionalidad declarada a través de ganchos _info en Drupal 7 ha sido reemplazada por estos complementos. Nuestro caso de uso fue muy simple y permitió declarar manualmente cada instancia de dicha funcionalidad a través de una nueva clase de complemento y un formulario asociado.
Pero, ¿y si necesitamos que tales instancias se declaren dinámicamente dependiendo de algunos factores fuera de nuestro pequeño subsistema? Por ejemplo, cuando declaramos ganchos _info en Drupal 7, podemos obtener una lista de algo, iterar a través de ellos y declarar un nuevo elemento en la matriz devuelta para cada algo único. El sistema de menús hace esto para proporcionar un nuevo bloque para cada menú que viene con el núcleo de Drupal o que se crea más tarde a través de la interfaz de usuario.
Entonces, ¿qué pasa con Drupal 8? Hemos visto que necesitamos declarar una clase de PHP diferente para cada plugin de cierto tipo. Para crear un nuevo bloque necesitamos una nueva clase. Crear Otro bloque que necesitamos Otro Clase. Entonces, ¿dónde tendría lugar este bucle que vemos en Drupal 7? La respuesta corta a eso es: dentro de un complemento derivado.
En este artículo examinaremos la respuesta larga a esto, qué son los derivados y cómo podemos usarlos. Para esto último, crearemos un ejemplo dentro del módulo de demostración que se encuentra en este repositorio de git que, con suerte, debería ayudarnos a comprender mejor lo que está sucediendo. Para un ejemplo un poco más complejo, el sistema de menús es excelente ya que proporciona un bloque individual para cada uno de sus menús (similar a Drupal 7 pero con complementos).
Lo que vamos a hacer es en realidad muy simple. Implementaremos la funcionalidad básica de bloque de nodos que nos permitirá tener un bloque para todos los nodos de artículos en nuestro sitio. ¿Ridículo? Seguro. ¿Deberíamos hacer esto para todos los nodos en nuestro sitio? ¡definitivamente no! Pero es una implementación muy simple destinada a acortar las cosas y demostrar el uso de los derivados del complemento.
Derivados de complementos
Los derivados de complementos son la forma en que un complemento de cierto tipo se puede representar en el sistema como múltiples instancias de sí mismo. En otras palabras, un complemento puede hacer referencia a una clase derivada que es responsable de proporcionar una lista de definiciones de complementos que se basan en el complemento original (se asume la misma definición base) pero tienen datos de configuración o definición ligeramente diferentes. El SystemMenuBlock mencionado anteriormente es un gran ejemplo. Es un complemento único que tiene tantos derivados como menús hay en la página.
Para profundizar un poco más, cuando se solicita una lista de todos los complementos de cierto tipo, el administrador de complementos usa su mecanismo de detección para cargar todos los complementos de ese tipo. Si este mecanismo está equipado con DerivativeDiscoveryDecorator, el administrador también puede recuperar derivados. Para hacer esto, la detección de derivados en cada complemento busca una clase derivada y, si encuentra una, solicita esta lista.
Los administradores de tipo de complemento que amplían la clase base DefaultPluginManager normalmente deben tener el mecanismo de detección derivado que adorna la detección predeterminada (anotaciones). Este es el patrón más común en el sistema de complementos del núcleo de Drupal: detección anotada envuelta en derivados.
La clase derivada
Ahora que entendemos el papel de los derivados del complemento, creemos nuestra primera clase derivada que será utilizada por nuestro complemento de bloque (que crearemos en un momento).
Dentro de src/Plugin/Derivative/NodeBlock.php del módulo de demostración tenemos lo siguiente:
nodoAlmacenamiento = $nodo_almacenamiento; } /** * {@inheritdoc} */ public static function create(ContainerInterface $container, $base_plugin_id) { return new static($container->get(‘entity.manager’)->getStorage(‘node’) ); } /** * {@inheritdoc} */ public function getDerivativeDefinitions($base_plugin_definition) { $nodes = $this->nodeStorage->loadByProperties([‘type’ => ‘article’]); foreach ($nodos como $nodo) { $este->derivados[$node->id()] = $base_plugin_definición; $esto->Derivados[$node->id()][‘admin_label’] = t(‘bloque de nodos: ‘) . $nodo->etiqueta(); } devuelve $esto->derivados; } }
Todo lo que nuestra clase tiene que implementar es DeriverInterface y la implementación de sus dos métodos. En su lugar, usamos ContainerDeriverInterface porque queremos que nuestro contenedor derivado sea consciente. ¿por qué? Porque estamos usando la inyección de dependencia para cargar el administrador de entidades de Drupal para que podamos acceder al almacenamiento del nodo (eso es lo que hacen el constructor y el método create()). Además, nuestra clase derivada se extiende desde la clase DeriverBase ya que hereda uno de los métodos requeridos (getDerivativeDefinition()).
Finalmente, getDerivativeDefinitions() es el método responsable de proporcionar una serie de definiciones de complementos derivadas del complemento que usa esta clase. Toma $base_plugin_definition como argumento (la definición del complemento real que usa este derivado) y lo usamos para construir nuestras definiciones derivadas. En nuestro caso, cargamos aleatoriamente todos los nodos de artículos y creamos una definición separada para cada uno, que se diferencia solo por una admin_label diferente (esta es una propiedad de la clase de anotación DrupalCoreBlockAnnotationBlock). La matriz de derivadas está encriptada por la ID de la derivada (en nuestro caso, la ID del nodo, que usaremos más adelante).
Un punto muy importante que debemos enfatizar aquí es que nunca es una buena idea cargar todos los nodos y crear complementos a partir de ellos. Puede ser interesante implementar una funcionalidad con la que los nodos individuales puedan exponerse como bloques a través de una casilla de verificación o algo similar.
El complemento de bloque
Ahora que tenemos nuestra clase derivada, creemos un complemento de bloque simple que lo use para generar múltiples instancias de sí mismo (uno para cada nodo Artículo).
Dentro de src/Plugin/Block/NodeBlock.php:
viewBuilder = $entity_manager->getViewBuilder(‘nodo’); $this->nodeStorage = $entity_manager->getStorage(‘node’); $this->node = $entity_manager->getStorage(‘node’)->load($this->getDerivativeId()); } /** * {@inheritdoc} */ public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) { return new static($configuration, $plugin_id, $plugin_definition, $container->get( ‘entity.manager’) ); } /** * {@inheritdoc} */ public function build() { if (!$this->node instanceof NodeInterface) { return; } $build = $this->viewBuilder->view($this->node, ‘full’); devolver $construir; } /** * {@inheritdoc} */ public function blockAccess(AccountInterface $cuenta, $return_as_object = FALSE) { return $this->node->access(‘view’, NULL, TRUE); } }
Lo primero que notamos en la anotación de este complemento es la clave derivada, que hace referencia a la clase que creamos anteriormente. Y eso es básicamente todo lo que necesitamos para emparejar los dos. El Discovery Decorator derivado hace el trabajo pesado.
Gran parte del resto es construcción de bloques simples con los que deberíamos estar familiarizados. Lo que es interesante es que podemos usar el método getDerivativeId() para obtener el ID del nodo, que también usamos como el ID del derivado mostrado, y usarlo para cargar el objeto del nodo y crear el bloque como la salida del nodo real. Finalmente, dentro del método blockAccess(), nos aseguramos de que este bloque tenga las mismas comprobaciones de acceso que el nodo real, por lo que si el usuario actual no tiene acceso para ver el nodo actual, el bloque ni siquiera se mostrará. .
Ahora, si borramos los cachés y navegamos a la interfaz de diseño de bloques, deberíamos ver algunos bloques llamados Node Block: [Node title]. Puede colocarlos en cualquier lugar que desee y representarán el nodo correspondiente.
Conclusión
En este artículo, analizamos los derivados de complementos y vimos un ejemplo simple de cómo funcionan. La clave de este tema es que los derivados de complementos son la forma en que declaramos dinámicamente varias instancias del mismo complemento. Por lo general, nos ayudan a convertir funciones configuradas por el usuario (p. ej., menús) en complementos (p. ej., bloques de menú).
Para ilustrar el uso de derivaciones, vimos una técnica muy simple que podemos usar para representar nodos de elementos como bloques. Sin embargo, debemos recordar no intentar esto en un sitio con muchos nodos de artículos, sino implementar características adicionales que limiten la cantidad de nodos expuestos. Ya sabes, para que no bloqueemos nuestro sitio.
¿Preguntas? ¿Comentarios? ¿Hay algo que le gustaría explicar con más detalle? ¡Haznos saber!
