Цікаво, як вирішити або використовувати основний модуль таксономії або модуль довідки суб'єкта ?

Я раніше не використовував модуль посилання на суб’єкти, але я використовував модуль таксономії (і деякі пов'язані з ним модулі) на 10-15 веб-сайтах.

Які переваги чи недоліки використання опорних модулів замість модуля таксономії?

Нещодавно я почав створювати веб-сайт архіву журналів.

Є багато журналів. Ці журнали мають випуски. У кожному номері є статті.

Найменша (і найглибша) частина тут - статті .

Стаття

• Номер сторінки (діапазон):
• Назва:
• Автор:
• Тип статті:
• Ключові слова:
• Журнал:
• Проблема:

Проблема

• Номер заявки:
• Зображення на обкладинці:
• Дата (опубліковано):
• Журнал:

Журнал

• Опис:
• Зображення на обкладинці:

Тут є (принаймні) два способи реалізації цього веб-сайту:

1. Буде названий тип вмісту, articleа всі інші (випуск, журнал, автор) будуть термінами таксономії (ієрархічні). Існувала б ієрархія між випуском та журналом тощо.

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

Отже, теоретично обидва способи здаються дуже схожими.

Чи є хтось, хто стикався з подібною ситуацією і чи не могли б ви сказати, якому методу ви віддали перевагу, чому?

Існують також інші рішення вашої проблеми.

Польова колекція

Для зберігання та впорядкування вмісту можна використовувати модулі збору та перегляду польових колекцій . Використовуючи цей підхід, тип Issueі Magazineзбирається поля колекції, Issueє полем Articleі Magazineє полем Issue. Я маю досвід впровадження такої структури. У моєму випадку вимога полягала в Libraryтому, що повинна містити книги (із полями Назва, Видавець та ...), кожна книга містить кілька томів (Кількість сторінок, перекладач, ...), а кожен том також містить необмежену кількість деяких інших елементів (як-от сканування деяких сторінок, які не однакові серед книг).

Я реалізував це, використовуючи підхід Field Collection, і це дуже приємно. Ви можете легко створити посилання, щоб редагувати всі окремі елементи кожної польової колекції, а також можете фільтрувати за елементами колекцій поля. Я опублікував відповідь на групові елементи у «Перегляди за значенням» у «Колекція полів», де показано, як працювати з видами «Колекція поля»

Додаток перегляду особи

Також відомий як модуль EVA .

"Eva" є скороченим до "Attachment Attachment;" він надає плагін відображення Views, який дозволяє приєднати висновок View до вмісту будь-якої суті Drupal. Тіло вузла або коментаря, профіль облікового запису користувача або сторінка з переліком терміна Таксономія - це всі приклади вмісту сутності.

Ви можете використовувати EVA для відображення лише значень полів для певного вмісту, надаючи неймовірний контроль над відображенням та гнучкістю форматування полів. Наприклад, ви можете хотіти, щоб два поля були об'єднані якимось особливим чином. Ви можете додати свої поля до свого EVA-дисплея, встановити контекстний фільтр на NID, додати глобальне: текстове поле та за допомогою лексем відформатувати свої поля за допомогою HTML. Не забудьте виключити свої поля із відображення, якщо ви збираєтесь використовувати їх разом у полі "Глобальне: текст". Приклад: у вас можуть бути місто, штат та поштові поля. Ви можете комбінувати їх у глобальному: текстовому полі у видах, щоб відображатись як "Місто, штат". Коли ви керуєте дисплеєм для вашого типу вмісту, додайте щойно створений EVA до дисплея, і кожного разу, коли буде показаний вузол, він передасть свій nid EVA, і EVA поверне вибрані вами поля, відформатований за вашим бажанням. (джерело:Інструкція щодо використання EVA та довідника юридичної особи )

Цей модуль є ідеальним, він приєднує погляд як поле до вузлів типу вмісту. Я використовував цей модуль для створення Album. Альбом містить singer(з деякою інформацією про кожного) і songsмістить файл, заголовок, швидкість та .... Тому я створив вигляд типу EVA і приєднав його до вузла. Отже, на сторінці вузла кожного співака я відображав цей вид, який отримує відповідну інформацію від вузла. У переглядах з Entity Reference є ідеальним підручником про те , як використовувати цей модуль.

Умови таксономії VS Суб'єкт господарювання

Я рекомендую вам ознайомитись із посиланням на юридичну особу порівняно з систематикою та чи є якісь переваги / застереження із використанням довідки суб’єкта господарювання за довідкою терміна? , Як мовиться, таксономії найкраще використовувати при організації подібних предметів в ієрархічному порядку. Як теги .

Таксономія дозволяє використовувати безкоштовне тегування (його можна відключити за допомогою модуля Content Taxonomy ), що дозволяє створювати нові теги на ходу. Змінити каркас вмісту дуже просто. Використовуючи такий підхід, регулярні або хоча б деякі аутентифіковані користувачі (які не знають програмування) можуть змінити цей каркас. Ієрархічний модуль Select є прекрасним прикладом такого підходу.

Незважаючи на те, що таксономія проста у використанні, але я сам віддаю перевагу Entity Reference, вона відкриває багато можливостей та масштабованості і дозволяє створювати дуже складні структури. Поняття сутності в цьому контексті не обмежується змістом. Це можуть бути коментарі, користувачі, таксономії та .... Це набагато масштабніше, тому ви не будете турбуватися про налаштування типів вмісту або його модифікацію в майбутньому (як це вказувалося в посиланнях Entity vs. taxonomy ). Я вважаю, що підхід Entity є більш потужним, ніж таксономія.

Існують також деякі інші комбінації цих підходів, про які їх згадувати зайве.

У будь-якому разі я рекомендую вам повністю зрозуміти підхід Entity та пов'язані з ним модулі. Якщо ви використовуєте його в декількох проектах, незважаючи на його складність, використовувати його буде дуже просто. Не тільки у вашій поточній вимозі, але і в майбутньому це буде дуже надійним інструментом для вас.

Ви також можете мати якусь іншу комбінацію, наприклад, статті та випуски - це вузли, що журнали є таксономіями.

Насправді немає правильної чи неправильної відповіді на це, це зводиться до особистих уподобань, конкретних вимог проекту тощо.

Найкраще використовувати вузли для вмісту та таксономії для категоризації цього вмісту, проте іноді це може бути трохи мутним, чи є щось просто категоризацією чи власним вмістом.

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

Одне, що може вплинути на ваше рішення, - це функціональність. Наприклад, є набагато більше модулів доповнення для вузлів, ніж для таксономій, але для таксономій ви виходите зі сторінок, що перелічують вікна (якщо ви хочете їх). Також може бути функція, пов’язана з ієрархією, яку простіше вийти з коробки одним чи іншим рішенням.

Визначення типу вмісту є лише частиною зображення. Ви, безумовно, повинні повністю розглянути питання про те, як ви плануєте презентувати вміст для користувача, як ви бажаєте, щоб користувач переміщався по ієрархії вмісту, як цей вміст стосується іншого контенту на сайті, як ви хочете, щоб адміністратори цього адміністрували. наприклад, чи хочете ви якусь ієрархічну систему меню, чи хочете, щоб люди мали змогу переходити до журналів чи видавати сторінки, чи вміст пов’язаний із тими, які видно лише на сторінках статей. Чи хочете мати єдиний пошук, у якому перераховані всі 3 типи вмісту (це може бути менш тривіально, якщо деякі - це вузли, а деякі - терміни таксономії).

Плануйте все це, а потім подивіться, які модулі доступні, щоб допомогти вам досягти цього. Можливо, ви знайдете один спосіб полегшити досягнення бажаного. Якщо ні, то вам просто потрібно їхати з тим, кого ви вважаєте найкращим з будь-яких причин.

Іноді ви можете піти в один бік і потім знайти щось, що ускладнює досягнення ваших потреб. Якщо ви плануєте це наперед, наскільки це можливо, ви зменшите цей ризик.

Ще одне врахування при використанні термінів таксономії для таких речей, як "Журнал", - це те, що ви втратите функціональність, таку як перегляд та коментарі до цих предметів. Затверджені редакції можна додати за допомогою такого модуля, як редакція Taxonomy, але це модуль з дуже низькою базою встановлення. Особисто я б довіряв основним питанням щодо обробки версій на вузлах.

Я можу придумати хоча б один випадок, коли мені довелося щось змінити з терміна таксономії на вузол після того, як проект вийшов з ладу через зміни вимог, і це передбачає неабияку реструктуризацію та міграцію.

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

Я не скажу, що це найточніша відповідь, але я так думаю. Я поясню на деяких прикладах.

Я зазвичай використовую таксономії для категоризації вузлів на основі абстракції. Наприклад, новини можна класифікувати на спортивні, політичні тощо.

Але коли я хочу мати довідник, як журнал, я думаю про майбутнє. Подумайте, коли ви хочете допомогти користувачеві вирішити, яку статтю вибрати. Рейтинг журналу (можливо, фактор впливу) - це можливість. А може, я хочу зв’язатися з тим журналом. Термін не допоможе мені в цій ситуації, коли, якби це вузол чи сутність, це було б.

З іншого боку, ви повинні зробити деякі речі самостійно. Наприклад, клацання терміна таксономії призведе до сторінки, заповненої категоризованими вузлами цього терміна. Тож зараз потрібен перегляд і контекстний фільтр тощо.

Я був впевнений, що хтось запитав, чому я тримаюсь подалі від польових колекцій, але коментар видається видаленим. У будь-якому випадку мої 2 копійки:

Таксономії слід використовувати для класифікації та категоризації. Не для змістових відносин. Пов'язуючи 2 частини вмісту через термін таксономії, ви використовуєте 3 об'єкти, де вам потрібно лише 2.

На моєму досвіді, хоча систематики зараз є запоручними, вони не є повноцінними утвореннями, і тому їх не слід використовувати як "зміст".

У цьому конкретному випадку, якщо ваш Журнал має вміст (опис того, що це таке, детальну інформацію про його замовлення тощо) або власну "сторінку", то це має бути тип контенту, оскільки він є вмістом.

Питання трохи неоднозначні, але шанси у вас є огляд тощо, тому вони, ймовірно, мають сторінку, і вони, ймовірно, вміст теж. Отже, інший тип вмісту.

Статті, очевидно, є змістовними.

Створюючи адміністратор для цього, ви можете скористатися посиланням на суб’єкт, щоб зв’язати ці частини вмісту, але ви можете перейти до кращого.

Так само, як @Drupalist запропонував використовувати колекції Field, ви можете використовувати вбудовані форми сутності (я думаю, що частина довідки про сутність). Колекції польових програм - один із цих старих модулів, який там, де чудова ідея, не дуже вдало реалізована, і при багатьох зіткненнях з іншими модулями. Хоча вони зараз є сутностями, у них все ще виникають проблеми, і вам краще використовувати повноцінні сутності (навіть типи вмісту) для таких речей, як ви, автори тощо.

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

Додайте в CER, і ви автоматично отримаєте посилання від автора на статтю, статтю назад до випуску та випуск назад до Журналу, або в будь-якому напрямку ви рухаєтесь. Це має переваги в ефективності ваших переглядів, але також дозволяє відображати список статей на сторінці автора, а також інформацію про автора на сторінці статті, все без переглядів взагалі.

Повне коло назад до таксономій, ви б потім використали їх для "тегів" статей тощо тощо ... або автора, який має вміст / написаний про цей тег.

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