Интересно, как решить, использовать ли основной модуль таксономии или модуль Entity Reference ?

Я не использовал модуль Entity Reference раньше, но я использовал модуль таксономии (и некоторые связанные модули) на 10-15 веб-сайтах.

Каковы преимущества или недостатки использования ссылочных модулей вместо таксономического модуля?

Недавно я начал создавать сайт архива журнала.

Есть много журналов. У этих журналов есть проблемы. В каждом номере есть статьи.

Самая маленькая (и самая глубокая) часть здесь - статьи .

Статья

• Номер страницы (диапазон):
• Заглавие:
• Автор:
• Тип статьи:
• Ключевые слова:
• Журнал:
• Выпуск:

вопрос

• Номер выпуска:
• Изображение на обложке:
• Дата (опубликовано):
• Журнал:

журнал

• Описание:
• Изображение на обложке:

Здесь есть (как минимум) 2 метода для реализации этого сайта:

1. Будет назван тип контента, articleа все остальные (выпуск, журнал, автор) будут терминами таксономии (иерархическими). Там будет иерархия между выпуском и журналом и т. Д.

2. Будет много типов контента: статья, выпуск, журнал, автор. При создании статей; на номер, журнал и автора можно ссылаться и т. д.

Итак, теоретически оба пути кажутся очень похожими.

Есть ли кто-нибудь, кто сталкивался с подобной ситуацией, и не могли бы вы сказать, какой метод вы предпочли, почему?

Есть и другие решения вашей проблемы.

Полевая коллекция

Вы можете использовать сбор поля и просмотр сбора полевых модули для хранения и организовать содержание. Используя этот подход, Issueи Magazineбудет типом Field Collection, Issueявляется полем Articleи Magazineявляется полем Issue. У меня есть опыт внедрения такой структуры. В моем случае требовалось Library, чтобы в нем содержались книги (с полями «Заголовок», «Издатель» и «...»). Каждая книга содержит несколько томов («Количество страниц, переводчик» и т. Д.), И каждый том также содержит неограниченное количество других элементов. (например, сканирование некоторых страниц, которые не совпадают среди книг).

Я реализовал это, используя подход Field Collection, и это очень приятно. Вы можете легко создать ссылку для редактирования каждого отдельного элемента каждой коллекции полей, а также фильтровать по элементам коллекции полей. Я опубликовал ответ для элементов группы в представлениях по значению в коллекции полей, в котором показано, как работать с представлениями коллекции полей

Приложение Entity View

Также известный как модуль EVA .

«Ева» - это сокращение от «Entity Views Attachment»; он предоставляет плагин для отображения видов, который позволяет прикрепить вывод View к содержимому любой сущности Drupal. Тело узла или комментария, профиль учетной записи пользователя или страница листинга для термина Таксономия - все это примеры содержимого сущности.

Вы можете использовать EVA для отображения только значений полей для определенного фрагмента контента, предоставляя невероятный контроль над отображением и гибкость форматирования полей. Например, вы можете захотеть объединить два поля каким-то особым образом. Вы можете добавить свои поля на дисплей EVA, установить контекстный фильтр на NID, добавить Global: Text Field и с помощью токенов отформатировать свои поля с помощью HTML. Не забудьте исключить ваши поля из отображения, если вы собираетесь использовать их вместе в Global: Text Field. Пример: у вас могут быть поля города, штата и почтового индекса. Вы можете объединить их в Global: Text Field в Views, чтобы отобразить их как «City, State ZIP». Когда вы управляете отображением для своего типа контента, добавьте EVA, только что созданный на дисплей, и всякий раз, когда отображается тип узла, он передает свой nid в EVA, и EVA возвращает выбранные вами поля, отформатирован по вашему желанию. (источник :EVA и Entity Reference Use Case Как к )

Этот модуль идеален, он прикрепляет View как поле к узлам типа контента. Я использовал этот модуль для создания Album. Альбом содержит singer(с некоторой информацией о каждом), songsкоторый содержит файл, заголовок, оценку и .... Поэтому я создал вид типа EVA и прикрепил его к узлу. Таким образом, на странице узла каждого Певца я отобразил это представление, которое получает соответствующую информацию от узла. В просмотрах с Entity Reference является идеальным учебником о том , как использовать этот модуль.

Условия таксономии VS Ссылка на сущность

Я рекомендую вам прочитать ссылку на сущность по сравнению с таксономией и есть ли какие-либо преимущества / предостережения при использовании ссылки на сущность над термином ссылка? Как говорится, таксономии лучше всего использовать при иерархической организации подобных объектов. Нравится теги .

Таксономия позволяет использовать бесплатные теги (их можно отключить с помощью модуля Content Taxonomy ), что позволяет создавать новые теги на лету. Очень легко изменить каркас содержимого. Используя этот подход, обычные или, по крайней мере, некоторые аутентифицированные пользователи (которые не имеют знаний о программировании) могут изменить этот скелет. Модуль Hierarchical Select является прекрасным примером такого подхода.

Хотя таксономия проста в использовании, но я сам предпочитаю Entity Reference, она открывает множество возможностей и масштабируемость и позволяет создавать очень сложные структуры. Понятие сущности в этом контексте не ограничивается содержанием. Это могут быть комментарии, пользователи, таксономии и ... Он гораздо более масштабируемый, поэтому вам не придется беспокоиться о настройке типов контента или об их изменении в будущем (как было указано в « Ссылке на сущность по сравнению с таксономией» ). Я считаю, что подход Entity является более мощным, чем таксономия.

Существуют также некоторые другие комбинации этих подходов, о которых нет необходимости упоминать.

В любом случае, я рекомендую вам полностью понять подход Entity и связанные с ним модули. Если вы используете его в нескольких проектах, несмотря на его сложность, вам будет очень легко его использовать. Не только в соответствии с вашими текущими требованиями, но и в будущем это будет очень надежный инструмент для вас.

У вас также может быть другая комбинация, например, статьи и вопросы - это узлы, а журналы - это таксономии.

На самом деле нет правильного или неправильного ответа, это сводится к личным предпочтениям, конкретным требованиям проекта и т. Д.

Лучше всего использовать узлы для контента и таксономии для категоризации этого контента, однако иногда может быть немного неясным, является ли что-то просто категоризацией или собственным контентом.

Например, поля типа вашей статьи и ключевые слова, скорее всего, являются таксономиями, но проблема и журналы могут действительно пойти в любую сторону.

Одна вещь, которая может повлиять на ваше решение - это нестандартная функциональность. Например, для узлов гораздо больше дополнительных модулей, чем для таксономий, но для таксономий вы получаете стандартные страницы со списком (если хотите). Могут также быть функциональные возможности, связанные с иерархией, которые легче получить из коробки с одним или другим решением.

Определения типа контента являются только частью изображения. Вы должны определенно полностью обдумать, как вы намерены представлять контент пользователю, как вы хотите, чтобы пользователь перемещался по иерархии контента, как этот контент связан с другим контентом на сайте, как вы хотите, чтобы администраторы управляли этим контент и т. д. Например, хотите ли вы какую-то иерархическую систему меню, хотите, чтобы люди могли заходить в журналы или публиковать страницы, или контент связан с теми, которые видны только на страницах статей. Хотите ли вы иметь единый поиск, в котором перечислены все 3 типа контента (это может быть не так просто, если некоторые являются узлами, а некоторые - терминами таксономии).

Спланируйте все это, а затем посмотрите, какие модули доступны, чтобы помочь вам достичь этого. Вы можете найти один способ облегчить достижение того, что вы хотите. Если нет, то вам просто нужно пойти с тем, который вы считаете лучшим по тем или иным причинам.

Иногда вы можете пойти одним путем, а затем найти что-то, что затрудняет выполнение ваших требований. Если вы планируете это как можно раньше, вы уменьшаете этот риск.

Еще одно соображение при использовании терминов таксономии для таких вещей, как «Журнал», заключается в том, что вы потеряете функциональность, такую ​​как пересмотр и комментарии к этим элементам. Предоставленные ревизии могут быть добавлены с помощью такого модуля, как ревизия таксономии, но это модуль с очень низкой базой установки. Лично я бы доверял ядру в обработке ревизии на узлах по этому поводу.

Я могу вспомнить хотя бы один случай, когда мне нужно было что-то изменить с термина таксономии на узел после запуска проекта из-за изменений в требованиях, и это включает в себя немало реструктуризации и миграции.

Вы, вероятно, обнаружите, что если вы перейдете к использованию других типов сущностей, таких как узлы с entity_reference, то у вас не возникнет проблем с внесением изменений, поскольку все работает во многом так же, но это даст вам большую гибкость.

Я не скажу, что это самый точный ответ, но я так думаю об этом. Я объясню на некоторых примерах.

Я обычно использую таксономии для классификации узлов на основе абстракции. Например, новости можно разделить на спортивные, политические и т. Д.

Но когда я хочу получить такую ​​ссылку, как журнал, я думаю о будущем. Подумайте, когда вы хотите помочь пользователю решить, какую статью выбрать. Рейтинг журнала (возможно, Impact Factor) возможен. Или, может быть, я хочу связаться с этим журналом. Термин не помог бы мне в этой ситуации, если бы это был узел или объект.

С другой стороны, вы должны сделать что-то самостоятельно. Например, щелкнув термин таксономии, вы попадете на страницу, заполненную категоризованными узлами этого термина. Так что теперь требуется представление и контекстный фильтр и т. Д.

Я был уверен, что кто-то спросил, почему я должен держаться подальше от полевых сборов, но комментарий, кажется, был удален. В любом случае мои 2 цента:

Таксономии должны использоваться для классификации и категоризации. Не для содержательных отношений. Связывая 2 части контента через термин таксономии, вы используете 3 сущности, где вам нужно только 2.

По моему опыту, в то время как таксономии теперь доступны для использования, они не являются полноценными объектами и поэтому не должны использоваться в качестве «контента».

В этом конкретном случае, если ваш журнал имеет контент (описание того, что это такое, подробности о его заказе и т. Д.) Или собственную «страницу», то это должен быть тип контента, потому что это контент.

Проблемы немного двусмысленны, но, скорее всего, у вас есть обзор и т. Д., Поэтому они, скорее всего, имеют страницу и, скорее всего, тоже контент. Так что другой тип контента.

Статьи, очевидно, являются типами контента.

При создании админа для этого вы можете использовать Entity Reference, чтобы связать эти фрагменты контента, но вы можете сделать это лучше.

Таким же образом, как @Drupalist предложил использовать Коллекции полей, вы можете использовать встроенные формы сущностей (я думаю, что это часть Entity Reference). Полевые Коллекции - это один из этих старых модулей, у которого отличная идея, не очень хорошо реализованная и со многими конфликтами с другими модулями. Хотя теперь они являются сущностями, у них все еще есть проблемы, и вам лучше использовать полноценные сущности (даже типы контента) для таких вещей, как вы, авторы и т. Д.

Встроенные формы сущностей позволяют вам создавать и редактировать ссылочные сущности из сущности, на которую вы хотите сослаться ... так, создавать / редактировать автора изнутри статьи или просто ссылаться на уже созданную.

Добавьте в CER, и вы автоматически получите от автора ссылку на статью, статью на проблему, проблему на страницу журнала или другое направление, в котором вы движетесь. Это имеет преимущества в том, как работают ваши представления, но также позволяет отображать список статей на странице автора и информацию об авторе на странице статьи, причем вообще без представлений.

Вернитесь назад к таксономиям, затем вы можете использовать их для «пометки» статей и т. Д. С помощью «рыбалки», «машины», «компьютеров» и т. Д. / Чего угодно ... чтобы вы могли найти любую проблему, журнал, статью или автор, который имеет содержание / написано об этом теге.

Пытался сделать это кратко, так что, надеюсь, это помогает и имеет смысл. Я сделал это на десятках сайтов. Глобальные спортивные мероприятия, сайты бронирования путешествий / отдыха, международные вещательные компании, напитки, благотворительные организации и т. Д. Надежные и мощные, и покрывают вас для непредвиденных потребностей.