Збір поля та довідка про особу

Яким чином збір поля є перевагою? Те ж саме можна зробити з новим типом вмісту, що вказує на батьківство з посиланням на сутність.

Можливо, хтось може зламати деякі ситуації, коли кожна з них буде краща.

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

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

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

Може хтось може допомогти пояснити?

Це питання, яке я задаю собі, коли стикаюся з новими проектами, Field Collection vs Entity Reference + спеціальна сутність або якщо структура проста, Field Collection vs користувальницьке поле з кількома db стовпцями / Multifield . Ось моя думка, заснована на моєму досвіді .

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

Field Collection - це чудове рішення, якщо ви робите сайт, який можна виконати лише за допомогою декількох налаштувань тут і там, він дає розробникам сайтів потужний інструмент для створення складних структур, не переживаючи про внутрішні місця. Це в основному створить сутність, яка пов'язана з об'єктом "хост" за допомогою ідентифікаторів, дозволяючи додавати до нього поля і все. Недоліки полягають у знанні внутрішніх даних збору поля, які вам необхідні для виконання складних операцій, таких як управління польовим збором з посиланням на сутність, або міграція даних. Оскільки це загальний інструмент, зробити крок далі досить складно.

Інший варіант, який ви маєте там, - це використання ECK з Entity Reference, але мій досвід з цим досі був катастрофою, я вважаю, що легше створити тип сутності за кодом без помічника.

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

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

Це дійсно залежить від даних, які ви вводите в поля, та використання, яке ви хочете зробити з ними.

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

Якщо ви хочете повторно використовувати інформацію, яку ви додаєте до колекції полів, буде краще використовувати тип вмісту або спеціальну сутність. Приклад: шкільний курс має 5 тем. Тема містить 3 поля: Назва, години та рівень. Якщо ви збираєтесь повторно використовувати теми в декількох шкільних курсах, перейдіть до типу вмісту / спеціальної особи та скористайтеся посиланням на предмет

Вони повинні бути приблизно еквівалентними по продуктивності, але колекція полів використовує Entity API і не вимагає створення спеціального типу вмісту.