¿Cuáles son las ventajas o desventajas de usar módulos basados ​​en referencias en lugar de módulos de taxonomía?


9

Me pregunto cómo decidir si utilizar el módulo de taxonomía central o el módulo de referencia de entidad .

No utilicé el módulo de referencia de entidad antes, pero utilicé el módulo de taxonomía (y algunos módulos relacionados) en 10-15 sitios web.

¿Cuáles son las ventajas o desventajas de usar módulos basados ​​en referencias en lugar de módulos de taxonomía?


Recientemente, comencé a construir un sitio web de archivo de revista.

Hay muchas revistas. Estas revistas tienen problemas. Cada número tiene artículos.


La parte más pequeña (y más profunda) aquí son los artículos .

Artículo

  • Número de página (rango):
  • Título:
  • Autor:
  • Tipo de artículo:
  • Palabras clave:
  • Revista:
  • Problema:


Problema

  • Número de emisión:
  • Imagen de portada:
  • Fecha de publicación):
  • Revista:


Revista

  • Descripción:
  • Imagen de portada:


ingrese la descripción de la imagen aquí

Aquí, hay (al menos) 2 métodos para implementar este sitio web:

1. Habrá un tipo de contenido llamado articley todos los demás (número, revista, autor) serán términos de taxonomía (jerárquico). Habría una jerarquía entre el número y la revista, etc.

2. Habrá muchos tipos de contenido: artículo, número, revista, autor. Mientras crea artículos; tema, revista y autor pueden ser referenciados etc.

Entonces, teóricamente, ambas formas son muy similares.

¿Alguien se enfrentó a una situación similar y podría decir qué método prefirió, por qué?

Respuestas:


9

También hay otras soluciones a su problema.

Colección de campo

Puede usar la colección de campos y los módulos de vistas de colección de campos para almacenar y organizar contenidos. Utilizando este enfoque, el Issuey Magazinevan a ser de tipo colección de campo, Issuees un campo de Articley Magazinees un campo de Issue. Tengo experiencia en implementar tal estructura. En mi caso, el requisito era Libraryque debería contener libros (con Título, Editor y ... campos), Cada libro contiene múltiples volúmenes (Número de páginas, traductor, ...) y cada volumen también contiene un número ilimitado de algunos otros artículos (como el escaneo de algunas páginas que no son las mismas entre los libros).

Implementé esto usando el enfoque de Field Collection y es muy agradable. Puede crear fácilmente un enlace para editar cada elemento individual de cada colección de campo y también puede filtrar por elementos de colección de campo. Publiqué una respuesta para Agrupar elementos en Vistas por valor en Field Collection que muestra cómo trabajar con Vistas de Field Collection

Adjunto de vista de entidad

También conocido como módulo EVA .

"Eva" es la abreviatura de "Adjunto de vistas de entidad"; proporciona un complemento de visualización de Vistas que permite adjuntar la salida de una Vista al contenido de cualquier entidad de Drupal. El cuerpo de un nodo o comentario, el perfil de una cuenta de usuario o la página de listado para un término de Taxonomía son ejemplos de contenido de la entidad.

Puede usar EVA para mostrar solo los valores de los campos para un contenido en particular, lo que proporciona un control increíble sobre la visualización y la flexibilidad de formato de los campos. Por ejemplo, es posible que desee tener dos campos concatenados de alguna manera especial. Puede agregar sus campos a su pantalla EVA, establecer el filtro contextual en NID, agregar un Global: Campo de texto y usar tokens para formatear sus campos con HTML. No olvide excluir sus campos de la pantalla si va a usarlos juntos en un Global: Campo de texto. Ejemplo: puede tener una ciudad, un estado y campos postales. Puede combinarlos en un Global: Campo de texto en Vistas para mostrar como "Ciudad, Estado ZIP". Cuando administre la pantalla para su tipo de contenido, agregue el EVA recién creado a la pantalla y cada vez que se muestre un nodo, el tipo pasará su nid al EVA y el EVA devolverá los campos que seleccione, formateado como lo desee. (fuente :EVA y procedimientos de casos de uso de referencia de entidad )

Este módulo es perfecto, adjunta una vista como un campo a los nodos de un tipo de contenido. Usé este módulo para crear un Album. El álbum contiene singer(con información sobre cada uno) y songsque contiene un archivo, título, velocidad y .... Entonces creé una vista de tipo EVA y la adjunté a un nodo. Entonces, en la página del nodo de cada cantante, mostré esta vista que obtiene su información apropiada del nodo. Las vistas con referencia de entidad son un tutorial perfecto de cómo usar este módulo.

Términos de taxonomía VS referencia de entidad

Le recomiendo que lea Referencia de entidad versus taxonomía y ¿Hay algún beneficio / advertencia con el uso de Referencia de entidad sobre Referencia de término? Como se dice, las taxonomías se utilizan mejor cuando se organizan elementos similares de forma jerárquica. Me gusta las etiquetas .

Taxonomy le permite utilizar el etiquetado gratuito (se puede deshabilitar con el módulo Content Taxonomy ), lo que permite la creación de nuevas etiquetas sobre la marcha. Es muy fácil modificar el esqueleto de contenidos. Con este enfoque, los usuarios habituales o al menos algunos autenticados (que no tienen conocimientos de programación) pueden cambiar este esqueleto. El módulo de selección jerárquica es un ejemplo perfecto de este enfoque.

Aunque la taxonomía es fácil de usar, yo prefiero la referencia de entidad, abre muchas posibilidades y escalabilidad y permite la creación de estructuras muy complejas. El concepto de entidad en este contexto no se limita al contenido. Pueden ser comentarios, usuarios, taxonomías y .... Es mucho más escalable, por lo que no tendrá que preocuparse por personalizar los tipos de contenido o modificarlos en el futuro (como se señaló en Referencia de entidad vs. taxonomía ). Creo que el enfoque de entidad es más poderoso que la taxonomía.

También hay algunas otras combinaciones de estos enfoques que no es necesario mencionarlos.

De todos modos, le recomiendo que comprenda completamente el enfoque de la entidad y sus módulos relacionados. Si lo usa en múltiples proyectos, a pesar de su complejidad, será muy fácil usarlo. No solo en el requisito actual de los suyos, sino también en el futuro, será una herramienta muy confiable para usted.


Muchas gracias por tu respuesta detallada. Me dio una buena perspectiva sobre el uso de módulos no taxonómicos. Antes de utilizar ese tipo de soluciones, hay dos cosas que entender: 1. La taxonomía tiene la función de autocompletar, ¿tienen estos módulos esta función? Porque sin la función de autocompletar en la página de agregar nodo es casi imposible crear un sitio web. 2. Puedo usar el módulo de taxonomía central sin otros módulos, pero las soluciones que mencionas necesitan algunos módulos adicionales y es difícil saber "qué otros módulos serían buenos" . Gracias de nuevo.
herci

2
De nada. Acerca de la pregunta número 1, si usa el módulo de entidad y el campo de referencia de entidad, sí, es autocompletado. Si usa Field Collection, no es necesario que se complete automáticamente porque no tiene relación, el nodo y sus hijos se encapsulan como un paquete único. Acerca de la pregunta 2, muchos módulos dependen del módulo de entidad, por lo que no importa qué enfoque esté utilizando, deberá instalar y habilitar este módulo. Además, creo que el poder que le proporciona merece la instalación de algunos módulos
M ama D

Si bien recomendaría mantenerse alejado de las Colecciones de campo, la entidad con campos de referencia de entidad es una herramienta excelente y muy poderosa. Combinado con algo como CER (Referencias de entidades correspondientes) se obtienen relaciones bidireccionales, por lo que en su caso el artículo sabría a qué tema y revista pertenece, junto con el tema que conoce el artículo. Debo señalar que las vistas ya tienen una búsqueda inversa para las relaciones entre entidades, pero esto es más rápido y abre nuevas posibilidades.
mediaashley

1
@mediaashley para obtener una relación de 2 maneras que no necesita instalar CER. Usando relaciones puede lograr esto fácilmente. El drupal.stackexchange.com/questions/124893/... explica esto
M AMA D

2
Aconsejaría mantenerse alejado de las colecciones de campo para cualquier otra cosa que no sean casos de uso simples. Cuando se trata de requisitos más complejos, encontrará que a largo plazo las colecciones de campo son débilmente compatibles en otros módulos. Otro problema es que todas las técnicas de drupal para acceder y manipular los datos a los que se acostumbró no se aplican a los datos almacenados en colecciones de campo. Por supuesto, todavía es posible hacer toda la manipulación de datos, sin embargo, la implementación es bastante confusa. Ir con referencia de entidad.
gbyte.co

8

También podría tener alguna otra combinación, como artículos y números son nodos y revistas son taxonomías.

Realmente no hay una respuesta correcta o incorrecta para esto, se trata de preferencias personales, requisitos específicos del proyecto, etc.

Es mejor usar nodos para contenido y taxonomías para la categorización de ese contenido, sin embargo, a veces puede ser un poco confuso si algo es solo categorización o su propio contenido.

Por ejemplo, los campos de tipo de artículo y palabras clave parecerían más evidentemente taxonomías, pero los números y las revistas realmente podrían ir en cualquier dirección.

Una cosa que podría influir en su decisión es la funcionalidad inmediata. Por ejemplo, hay muchos más módulos adicionales para los nodos que para las taxonomías, pero para las taxonomías sale de la lista de páginas (si las desea). También puede haber una funcionalidad relacionada con la jerarquía que sea más fácil de sacar de la caja con una solución u otra.

Las definiciones de tipo de contenido son solo una parte de la imagen. Definitivamente, debe considerar completamente cómo pretende presentar el contenido al usuario, cómo desea que el usuario navegue a través de la jerarquía de contenido, cómo se relaciona este contenido con otro contenido en el sitio, cómo desea que los administradores administren esto contenido, etc. Por ejemplo, ¿desea algún tipo de sistema de menú jerárquico, desea que las personas puedan ir a páginas de revistas o publicaciones o que el contenido esté relacionado con aquellos que solo están visibles en las páginas del artículo. ¿Desea tener una sola búsqueda que enumere los 3 tipos de contenido (esto puede ser menos trivial si algunos son nodos y otros son términos de taxonomía).

Planifique todo eso y luego vea qué módulos están disponibles para ayudarlo a lograrlo. Puede encontrar una manera que le facilitará lograr lo que desea. Si no, entonces solo tienes que ir con el que creas que es mejor por las razones que tengas.

A veces puede ir por un camino y luego encontrar algo que le dificulta cumplir sus requisitos. Si lo planifica por adelantado tanto como sea posible, disminuye ese riesgo.


Sí, dijiste que podría haber alguna otra combinación. Probaré los módulos basados ​​en referencias porque ya he usado las soluciones basadas en taxonomía en muchos proyectos. Compartiré los resultados para este caso. Gracias.
herci

5

Otra consideración al usar términos de taxonomía para cosas como "Revista" es que perderá funcionalidad como la revisión y los comentarios sobre esos elementos. Las revisiones otorgadas se pueden agregar con un módulo como la revisión de Taxonomía, pero ese es un módulo con una base de instalación muy baja. Personalmente, confiaría en los núcleos en el manejo de revisiones en los nodos sobre esto.

Puedo pensar en al menos una ocasión en la que tuve que cambiar algo de un término de taxonomía a un nodo después de que un proyecto se puso en marcha debido a cambios en los requisitos, y esto implica un poco de reestructuración y migración.

Probablemente descubra que si cambia a utilizar otros tipos de entidades, como nodos con entity_reference, no tendrá problemas para realizar el cambio, ya que todo funciona de la misma manera, pero le dará más flexibilidad.


Gracias, la parte de revisión es un buen punto. Como dijiste, migrar de la taxonomía al nodo es difícil. Lo más probable es que use una solución basada en node + entity_reference . Gracias de nuevo por su respuesta.
herci

3

No diré que esta es la respuesta más precisa, pero así es como lo pienso. Lo explicaré con algunos ejemplos.

Usualmente uso taxonomías para categorizar nodos basados ​​en una abstracción. Por ejemplo, las noticias se pueden clasificar en deportivas, políticas, etc.

Pero cuando quiero tener una referencia como una revista, pienso en el futuro. Piense en cuándo quiere ayudar al usuario a decidir qué artículo elegir. El rango de revista (Factor de impacto tal vez) es una posibilidad. O tal vez quiero contactar esa revista. Un término no me ayudaría en esta situación, donde si fuera un nodo o entidad lo haría.

Por otro lado, tienes que hacer algunas cosas tú solo. Por ejemplo, hacer clic en un término de taxonomía lo llevaría a una página llena de nodos categorizados de ese término. Así que ahora se necesita una vista y un filtro contextual, etc.


3

Estaba seguro de que alguien preguntó por qué me mantendría alejado de las colecciones de campo, pero el comentario parece haber sido eliminado. De cualquier manera mis 2 centavos:

Las taxonomías deben usarse para la clasificación y categorización. No para relaciones de contenido. Al vincular 2 piezas de contenido a través de un término de taxonomía, está utilizando 3 entidades donde solo necesita 2.

En mi experiencia, si bien las taxonomías ahora se pueden enviar, no son entidades completas, por lo que no deben usarse como "contenido".

En este caso particular, si su Revista tiene contenido (una descripción de lo que es, detalles sobre cómo ordenarlo, etc.), o una "página" propia, entonces debe ser un tipo de contenido, porque es contenido.

Los problemas son un poco ambiguos, pero es probable que tengas una visión general, etc., por lo que es probable que tengan una página y que también tengan contenido. Entonces otro tipo de contenido.

Los artículos son obviamente tipos de contenido.

Al crear el administrador para esto, puede usar la Referencia de entidad para vincular estas piezas de contenido, pero puede elegir una mejor.

De la misma manera que @Drupalist sugirió usar Field Collections, puede usar formularios de entidad en línea (creo que es parte de la Referencia de entidad). Las colecciones de campo son uno de estos módulos antiguos que son una gran idea, no están muy bien implementadas y tienen muchas colisiones con otros módulos. Si bien ahora son entidades, todavía tienen problemas, y sería mejor utilizar entidades completas (incluso tipos de contenido) para cosas como sus autores, etc.

Los formularios de entidad en línea le permiten crear y editar entidades referenciadas, desde dentro de la entidad desde la que desea hacer referencia ... por lo tanto, crear / editar autor desde dentro de un artículo, o simplemente hacer referencia a una que ya se ha creado.

Agregue CER y automáticamente obtendrá una referencia del autor al artículo, el artículo al tema y el tema a la Revista, o en la dirección que vaya. Esto tiene ventajas en el rendimiento de sus vistas, pero también le permite mostrar una lista de artículos en la página del autor y la información del autor en la página del artículo, todo sin vistas.

Complete el círculo de regreso a las taxonomías, luego las usaría para "etiquetar" artículos, etc.con ... "pesca", "automóvil", "computadoras", etc. o autor que tiene contenido / escrito sobre esa etiqueta.

Intenté hacer eso breve, así que espero que ayude y tenga sentido. Lo he hecho en docenas de sitios. Eventos deportivos globales, sitios de reserva de viajes / vacaciones, emisoras internacionales, bebidas, organizaciones benéficas, etc. Robusto, potente y lo cubre para requisitos imprevistos.


Gracias por tu respuesta. Realmente tiene sentido y la experiencia de lectura es muy importante para mí.
herci
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.