Con el estado actual de D8, ¿cuál es el árbol de decisión para crear un nuevo tipo de entidad de contenido versus crear un Tipo de contenido para la entidad de contenido "Nodo"?

Hemos visto cuatro años y el primer lanzamiento de Drupal 8 desde que la respuesta aceptada se escribió para la pregunta "¿ Cuándo es apropiado crear una Entidad en lugar de simplemente agregar un nuevo tipo de contenido ?" Y, las entidades son más centrales para Drupal 8 que en Drupal 7. ( RefB , RefC , RefD )

En este nuevo mundo de Drupal 8, ¿cuál es el árbol de decisión para crear un nuevo tipo de entidad de contenido versus un nuevo Tipo de contenido para la entidad de contenido del tipo "Nodo"?

Cuando considere una respuesta, considere lo siguiente:

• ¿Sigue siendo apropiado un nuevo tipo de contenido para el tipo de entidad de contenido de "Nodo" en situaciones del 99% frente a un nuevo tipo de entidad de contenido?
• ¿El árbol de decisión ahora incluye más, mejores o más claras razones para evitar usar el tipo de entidad de contenido "Nodo" y en su lugar crear un nuevo tipo de entidad de contenido? Y si es así, ¿qué son? ¿Incluyen:
  • ¿Actuación?
  • Seguridad / permisos?
  • ¿El número de módulos que funcionan con tipos de contenido de tipo entidad de nodo y no funcionan con otros tipos de entidad de contenido?
• Quizás, en base a la respuesta aceptada anterior a la que se hace referencia anteriormente, la única razón general para hacer un tipo de entidad de contenido personalizado es si desea agrupar datos de Nodo, por ejemplo, con términos de taxonomía, o anotar Nodo, por ejemplo, con comentarios.

La compatibilidad del módulo parece una consideración particularmente interesante para un árbol de decisión. En la actualidad, pocos de los módulos más instalados tienen una versión para 8.x que no es simplemente alfa, beta o rc (una versión candidata). Y parece difícil identificar cuántos de ellos funcionarán de forma inmediata con un nuevo tipo de entidad personalizada frente a un nuevo tipo de contenido de entidad de nodo. No parece haber un atributo de proyecto para distinguir entre aquellos que están "escritos para entidades" versus "escritos para tipos de contenido de entidad de nodo".

Eche un vistazo a pathauto, que actualmente es el cuarto módulo más instalado de aquellos que tienen algún tipo de versión 8.x. La gente está trabajando duro en una versión 8.x que generalmente admite entidades y no solo Tipos de contenido de tipo entidad de nodo. ¿Pero qué hay de todos los otros módulos? ¿Y los módulos que admiten entidades generalmente requerirán tipos de entidades de contenido personalizados para tener "ganchos" específicos del módulo antes de que el módulo trabaje con ellos? (¿Frente a cómo los módulos pueden funcionar directamente con nuevos tipos de contenido?) ¿ Ese parece ser el tipo de desafío con el que está trabajando el equipo de Pathauto, y tal vez es una razón para alejarse de un tipo de entidad de contenido personalizado?

También vale la pena mencionar que el núcleo de Drupal 8 contiene una interfaz de usuario para crear nuevos tipos de contenido para la entidad de contenido del tipo "Nodo", pero actualmente no contiene una interfaz de usuario para crear nuevos tipos de entidades de contenido. ( RefX , RefY , RefZ )

Árbol de decisión para elegir entre crear un nuevo tipo de contenido de tipo entidad de nodo versus un nuevo tipo de entidad de contenido:

1. ¿Eres un programador o tienes acceso fácil a un programador?
   • Si no, entonces actualmente está bastante limitado a crear nuevos tipos de contenido de entidad de nodo. (No hay una interfaz de usuario en el núcleo para crear nuevos tipos de entidades de contenido, y el módulo de contribución Entity Construction Kit (ECK) actualmente solo tiene una versión alfa).
   • Si es así, entonces continúe ...
2. ¿Sabes exactamente qué módulos contrib quieres aprovechar para tus datos?
   • Si no, entonces la apuesta segura es probablemente crear un tipo de contenido de entidad de nodo.
   • En caso afirmativo, ¿esos módulos ya admiten los tipos de entidad personalizados que está considerando, o está dispuesto a ayudar a mejorarlos para que puedan o recrear la funcionalidad deseada en su módulo?
     • De lo contrario, crear un tipo de contenido de tipo entidad de nodo puede ser lo mejor para usted.
     • Si es así, entonces continúe ...
3. ¿Los datos de contenido reales habilitados por su módulo simplemente ayudarán a agrupar o anotar otros datos de contenido? (Para que rara vez se vea por sí solo).
   • En caso afirmativo, considere si su módulo es como los tipos de entidad existentes para términos y comentarios de taxonomía. Si es así, entonces un nuevo tipo de entidad puede ser una apuesta segura.
   • Si no, entonces continúe ...
4. ¿Puedes explicar claramente por qué un nuevo tipo de contenido de tipo entidad de nodo no funcionará para ti?
   • Si no, entonces su apuesta segura es probablemente crear un nuevo tipo de contenido de tipo entidad de nodo.
   • Si es así, entonces continúe ...
5. Por último, ¿está seguro de que no puede simplemente extender el tipo de entidad de nodo y que desea recrear todas sus funcionalidades útiles como las operaciones CRUD?
   • En caso afirmativo, continúe y cree un nuevo tipo de entidad personalizada.
   • Si no, o si no está seguro, entonces probablemente desee contratar a algunos expertos para que lo ayuden a decidir.

Notas:

1. Este árbol de decisiones no considera el rendimiento ni la seguridad. No estoy seguro de si un nuevo tipo de entidad de contenido personalizado funcionará mejor y será más o menos seguro que un tipo de entidad de nodo.
2. Incluso si este árbol es una buena respuesta, probablemente no lo será con el tiempo debido a las actualizaciones en el núcleo de Drupal y las versiones del módulo contrib StackExchange no parece adaptarse a cómo la "mejor" respuesta de hoy puede no ser la mejor respuesta mañana).

Un enfoque simple sobre ese tema es tener en cuenta el propósito del proyecto, el tamaño y los requisitos comerciales.

1. Cómo el tipo de contenido de entidad de nodo predeterminado afecta la construcción del proyecto de una manera fácil y ordenada más cercana a la arquitectura y los flujos de datos producidos a partir del pensamiento analítico de los documentos del proyecto.

Un aviso importante aquí es la decisión de crear un nuevo tipo de entidad que generalmente toman los desarrolladores o líderes técnicos, no los creadores de sitios o los propietarios de proyectos que administran la aplicación y solo se centran en los negocios.

2. Drupal 8 depende de algunos paquetes de Symfony2 y está más cerca de los frameworks, desarrollo que los cms tradicionales que hablan de Drupal con esos grandes cambios arquitectónicos, imagino que construir una nueva entidad es mejor que hacer muchas personalizaciones y configuraciones complejas sobre tipos de contenido de entidad de nodo en orden para aprovechar Drupal entre otros marcos, ya que a muchas personas no les encanta la forma en que la configuración de Drupal y la configuración distribuida, es posible que algunas personas provengan de WordPress y solían configurar todo desde una forma que les molesta cuando se trata con el panel de administración de Drupal.

3. Drupal 9 planea eliminar por completo el sistema de enlace y reemplazarlo con un despachador de eventos que genera una gran necesidad de una interfaz de administrador para crear una nueva entidad, ya que alterar la funcionalidad existente del código será mucho más difícil para las personas que no son desarrolladores y será muy esencial para agrega esa característica.

Al final , veo que las nuevas entidades adaptadas a las necesidades del proyecto ofrecen un alto rendimiento mejor que los tipos de contenido complejos con un gran número de campos, ya que ahora cada campo agrega 2 tablas a la base de datos y necesita cargar su configuración en cada solicitud, especialmente con el Se requiere una gran lógica de negocios.

Claro y simple: no todo es contenido. La lista del contenido podría ser bastante larga y ser confusa si solo usa tipos de contenido. ( ContentEntityBase también podría ser implementado por una entidad personalizada)

Si tiene un autor y un estado publicado , debe elegir un tipo de contenido.

De lo contrario (suponiendo que sea un programador), se preferirán las entidades personalizadas. Un lote se puede implementar fácilmente con todas las interfaces (como revisión, capacidad de campo, restricción de acceso, etc.)

En mi opinión, esto es una arquitectura más clara y ordenada (y también más eficiente).

Pensando en la reutilización en varios proyectos, el esfuerzo para hacer que las entidades personalizadas exploten ... también hay ingeniosos ayudantes como drupal-code-generator . Para mantener la codificación personalizada (o la complejidad) en un nivel bajo, debe considerar el uso de tipos de contenido si desea:

• Para traducir la 'entidad' (al menos en D7), también habría una interfaz.
• (abierto para sugerencias) ..

Es una pregunta difícil que honestamente creo que solo se entiende una vez que la ha implementado antes. Pero, como se mencionó en remy, no todo es crudo, el contenido se enfrenta al usuario .

En Drupal 7, existía la capacidad de crear entidades personalizadas, pero podría ser una tarea desalentadora si fuera duro con OOP. Fue implementado a la mitad (o a la mitad, como quiera decirlo), lo que condujo a formas de crear entidades que no eran todas exactamente uniformes y enfoques acordados, con procedimientos mixtos y OOP mixtos.

En Drupal 8, la idea es mucho más clara y es mucho más fácil poner en marcha una entidad personalizada. El nodo en sí se basa en ContentEntityBase, al igual que los bloques, los usuarios, los archivos y la taxonomía.

Los nodos son específicamente para datos de contenido publicados, visibles (o autorizados) que generalmente actúan como contenido (es decir, en un menú o en el mapa del sitio, o en el mapa del sitio xml, o en los canales RSS, etc.). Drupal se diseñó de forma tal que pudieras conectarte a cualquier paso del proceso de operaciones de nodo y modificarlo, lo que puede tener consecuencias no deseadas si tienes la combinación incorrecta de módulos contribuidos. Esta es probablemente una opinión controvertida, pero ayuda a separarse de la idea de "todo es un nodo" para abrazar más el concepto de entidad.

Contenido ideal que crea excelentes tipos de contenido:

• Artículo
• Página
• Oferta de trabajo
• Evento
• Página de destino
• Página principal

El hilo común para ellos es que comparten un concepto de un tipo de contenido. Por lo general, se encuentra en cualquier número de estados de flujo de trabajo (publicado, promocionado, fijo, archivado, destacado, etc., si usa opciones de publicación personalizadas), y una gran cantidad de módulos contribuidos interactúan directamente con él, como Pathauto.

Pero supongamos que desea almacenar datos en Drupal que son internos, privados, manejan otros datos o datos que no deberían permitir la integración fuera de su alcance a menos que lo permita. ¿Qué tipo de datos podría ser esto? Aquí hay algunos tipos posibles:

• Producto (Drupal Commerce)
• Línea de pedido (Drupal Commerce)
• Servidor de búsqueda (ApacheSolr / SearchAPI)
• Contacto (como cable CRM)
• Ticket (como ticket de soporte)

¿Qué los hace tan diferentes? ¿Por qué querría una entidad para contacto, en lugar de utilizar el modelo de usuario? Podría hacer algunos argumentos allí, pero mi ejemplo sería que si dice, recolectando direcciones de correo electrónico y nombres y algunos otros metadatos de un formulario de contacto, almacene esos datos como una entidad personalizada. Evita que la lista de usuarios se contamine con elementos ajenos a la cuenta, reduce los posibles problemas de seguridad (¿qué sucede si un script o alguien actualiza accidentalmente esas cuentas para ser administradores o se envía un correo masivo?), Realiza una administración interna interna del usuario real cuentas más fáciles, y segmentas lo que estás capturando a lo que es, un bit especializado de datos.

A partir de aquí, está en gran parte divorciado de las partes más automáticas del sistema Drupal / Node y puede adaptar las acciones y la experiencia. Usted determina las rutas, el acceso y el flujo de trabajo CRUD.

En esa mentalidad, hace que sea más fácil ver por qué el enfoque se haría de esa manera. Tomemos el ejemplo del ticket de soporte: son solicitudes entrantes, pero no son datos publicados, y es probable que tenga un flujo de trabajo muy específico que sea más fácil de configurar que separarlo de partes del sistema de nodos que no desea que adhiera a.

Otro ejemplo serían los datos externos importados. En la mayoría de los casos, estos datos generalmente no se enriquecen con datos locales de Drupal (incluso si es así, como entidad, aún puede hacerlo). Podría ser cualquier cosa. Tal vez son facturas, tal vez son libros, tal vez está tirando marcas de cerveza.

Datos como este suelen ser específicos y requieren un control más allá de lo que el nodo está destinado. Eso no quiere decir que no pueda aumentarlo utilizando un campo de referencia en un nodo para apuntar a su entidad personalizada (así es como funcionó Drupal Commerce, en algún nivel) para enriquecer los datos. Al mismo tiempo, está aislando y asegurando el control sobre sus datos y la interfaz de usuario del código de contribución erróneo que va más allá de su diseño e interfiere con su modelo. Esto es probablemente un problema menor en D8 que en D7, aunque quedan algunos ganchos.

La arquitectura adecuada ahora existe para alentar la separación. No todo es un nodo.