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.
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.
fuente
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.
fuente
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.
fuente
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.
fuente