З поточним статусом D8, яке дерево рішень для створення нового типу об'єкта вмісту порівняно зі створенням типу вмісту для об'єкта вмісту "Вузол"?

Ми побачили чотири роки і перший реліз Drupal 8, оскільки прийнята відповідь була написана на питання " Коли доцільно створити Entity, а не просто додати новий тип вмісту ?" І сутність є центральнішою для Drupal 8, ніж була для Drupal 7. ( RefB , RefC , RefD )

У цьому новому світі Drupal 8, яке дерево рішень для створення нового типу об’єкта вмісту порівняно з новим Тип вмісту для об'єкта вмісту типу "Вузол"?

Розглядаючи відповідь, будь ласка, врахуйте наступне:

• Чи новий тип вмісту для типу об’єкта вмісту "Вузол" все-таки підходить у ситуаціях 99% проти нового типу об'єкта вмісту?
• Чи тепер дерево рішень включає більше, кращі чи зрозуміліші причини, щоб відмовитися від використання типу об’єкта вмісту "Вузол" і натомість створити новий тип об'єкта вмісту? І якщо так, то що вони? Чи включають вони:
  • Продуктивність?
  • Безпека / дозволи?
  • Кількість модулів, які працюють з типами Content-Type-типів Node та не працюють з іншими типами об'єктів вмісту?
• Можливо - виходячи з попередньої прийнятої відповіді, на яку посилається вище, - єдиною загальною причиною створення користувальницького типу контентної сутності є те, якщо ви хочете згрупувати дані Вузла, наприклад, з умовами таксономії або іншим чином анотувати Вузол, наприклад, з коментарями?

Сумісність з модулем здається особливо цікавим фактором для дерева рішень. В даний час мало хто з найбільш встановлених модулів має випуск для 8.x, який не є просто альфа, бета або rc (кандидатом на випуск). І здається складно визначити, скільки з них працюватимуть нестандартно з новим користувацьким типом сутності порівняно з новим типом вмісту Node-entity. Здається, атрибут проекту не може відрізняти ті, які "написані для об'єктів", а не "написані для типів вмісту об'єктів вузла".

Погляньте на pathauto, який на даний момент є четвертим за розміром модулем із тих, у кого випуск 8.x. Люди наполегливо працюють над версією 8.x, яка, як правило, підтримує сутності, а не лише типи вмісту типу "Вузол". А як щодо всіх інших модулів? І чи будуть модулі, які підтримують суб'єкти, які зазвичай вимагають призначених для користувача типів вмісту, мати специфічні для модуля "гачки", перш ніж модуль працюватиме з ними? (На відміну від того, як модулі можуть працювати прямо з коробки з новими типами вмісту?) Це, мабуть, є викликом, з яким працює команда патхауто, і, можливо, це є причиною відмовитися від користувальницького типу контентної сутності?

Можливо, варто також згадати, що ядро ​​Drupal 8 містить інтерфейс користувача для створення нових типів вмісту для об'єкта вмісту типу "Вузол", але він наразі не містить інтерфейс для створення нових типів об'єктів вмісту. ( RefX , RefY , RefZ )

Дерево рішень щодо вибору між створенням нового типу вмісту типу "Вузол-сутність" порівняно з новим типом суті-контенту:

1. Ви програміст чи у вас легкий доступ до програміста?
   • Якщо ні, то зараз ви майже в значній мірі обмежені створенням нових типів вмісту сут-вузлів. (У ядрі не існує інтерфейсу інтерфейсу для створення нових типів контентної сутності. Модуль вкладу Entity Construction Kit (ECK) наразі має лише альфа-версію.)
   • Якщо так, то продовжуйте ...
2. Ви точно знаєте, які модулі внесків ви хочете використовувати для своїх даних?
   • Якщо ні, то безпечна ставка - це, мабуть, просто створення типу вмісту суто-сутності.
   • Якщо так, чи підтримують ці модулі вже призначені для вас типи (-и) особи, які ви розглядаєте, чи ви готові допомогти вдосконалити їх, щоб вони створили або відтворили потрібну функціональність у вашому модулі?
     • Якщо ні, то саме створення типу Вміст-Субстанція типу вмісту може бути найкращим для вас.
     • Якщо так, то продовжуйте ...
3. Чи допоможуть фактичні дані про вміст, які увімкнено модулем, лише групувати або коментувати інші дані вмісту? (Так що його рідко можна буде переглядати самостійно.)
   • Якщо так, то подумайте, чи ваш модуль подібний до існуючих типів сутності для термінів та коментарів щодо таксономії. Якщо це так, то новий тип юридичної особи може бути безпечною ставкою.
   • Якщо ні, то продовжуйте ...
4. Чи можете ви чітко сформулювати, чому новий тип вмісту типу "Вузол" не буде працювати для вас?
   • Якщо ні, то ваша безпечна ставка - це, ймовірно, просто створити новий тип вмісту типу "Вузол".
   • Якщо так, то продовжуйте ...
5. Нарешті, чи впевнені ви, що не можете просто розширити тип вузла-сутність і хочете відтворити всі його корисні функції, такі як операції CRUD?
   • Якщо так, то вперед і створіть новий спеціальний тип сутності.
   • Якщо ні, або якщо ви не впевнені, то, ймовірно, ви хочете залучити деяких експертів, які допоможуть вам прийняти рішення.

Примітки:

1. Це дерево рішень не враховує ефективність чи безпеку. Я не впевнений, чи буде, коли новий спеціальний тип об’єкта вмісту матиме кращі результати та матиме більш-менш безпечний характер, ніж тип вузлової сутності.
2. Навіть якщо це дерево є гарною відповіддю, воно, ймовірно, не залишиться одне з часом через оновлення у випуску ядра та модуля вкладників Drupal. Здається, StackExchange не відповідає тому, як найкраща відповідь сьогодні може бути не найкращою відповіддю завтра.)

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

1. Те, як тип вмісту за замовчуванням сутності-сутності впливає на побудову проекту легким, акуратним способом, ближчим до архітектури та потоків даних, що випливає з аналітичного мислення документів проекту.

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

2. Drupal 8 залежить від деяких пакетів symfony2 і є більш близьким до каркасів, розробки, що традиційні cms, що говорять про Drupal з такими великими архітектурними змінами, я передбачаю, що створення нового об'єкта краще, ніж робити багато налаштувань і складних конфігурацій для типів вмісту вузла-сутності, щоб замовити щоб використовувати Drupal серед інших рамок, оскільки багато людей не люблять спосіб налаштування Drupal та розподілені налаштування. Ви можете зіткнутися з деякими людьми, що надходять з WordPress і використовуються для налаштування кожної речі з однієї форми, яка викликає роздратування при роботі з інформаційною панеллю адміністратора Drupal.

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

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

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

Якщо у вас є автор та опублікований стан, вам слід перейти до типу вмісту.

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

На мій погляд, це просто чіткіша та впорядкована архітектура (а також більш ефектна).

Розмірковуючи про можливість повторного використання в декількох проектах, намагання змусити користувальницькі організації вибухнути. Є також чудові помічники, такі як drupal-генератор коду . Щоб зберегти спеціальне кодування (або складність) на низькому рівні, вам слід розглянути можливість використання типів вмісту, якщо ви хочете:

• Для перекладу "сутності" (принаймні, у D7) був би також інтерфейс.
• (відкрито для пропозицій) ..

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

У Drupal 7 можливість створення спеціальних сутностей існувала, але це може бути непростим завданням, якщо ви будете грубими по краях з OOP. Це було начебто наполовину впроваджене (або наполовину виконане, як би ви цього не хотіли сказати), що призвело до способів створення організацій, які не були б абсолютно однаковими та узгодженими підходами, зі змішаним процедурним та змішаним ООП.

У Drupal 8 ідея набагато реалізовується, і вставати та працювати з користувацьким об'єктом набагато простіше. Сам вузол базується на ContentEntityBase, як і Блоки, Користувачі, Файл та Таксономія.

Вузли призначені спеціально для опублікованих, видимих ​​(або авторизованих) даних про вміст, які зазвичай виступають як вміст (тобто в меню, або в мапі, або в XML, або в RSS-каналах тощо). Drupal був розроблений таким чином, щоб ви могли підключитися до будь-якого кроку процесу роботи вузла та змінити його, що може мати непередбачувані наслідки, якщо ви маєте неправильну суміш модулів, що надаються. Це, мабуть, суперечлива думка, але це допомагає розлучитися з ідеєю "все - це вузол", щоб більше сприйняти концепцію Entity.

Ідеальний вміст, який створює чудові типи вмісту:

• Стаття
• Сторінка
• Проведення роботи
• Подія
• Цільова сторінка
• Домашня сторінка

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

Але припустимо, що ви хочете зберігати дані в Drupal, які є внутрішніми, приватними, дисками інших даних або даних, які не повинні допускати інтеграції за межами її сфери, якщо ви не дозволяєте. Що це за дані? Ось кілька можливих типів:

• Продукт (Drupal Commerce)
• Пункт-позиція (Drupal Commerce)
• Пошуковий сервер (ApacheSolr / SearchAPI)
• Контакт (як привід CRM)
• Квиток (як квиток на підтримку)

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

Звідси він значною мірою відокремлений від більш автоматичних частин системи Drupal / Node, і ви можете налаштувати дії та досвід. Ви визначаєте маршрути, доступ та робочий процес CRUD.

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

Іншим прикладом можуть бути зовнішні, імпортовані дані. У більшості випадків ці дані, як правило, не збагачуються локальними даними Drupal (навіть якщо це, як організація, ви все одно можете це зробити). Це може бути що завгодно. Можливо, це рахунки-фактури, можливо, це книги, можливо, це тягне марки пива.

Такі дані, як правило, є специфічними і потребують контролю за межами того, що призначений вузол. Це не означає, що ви не можете його доповнити, використовуючи посилання на вузлі, щоб вказати на вашу власну сутність (саме так на певному рівні працювала Drupal Commerce) для збагачення даних. У той же час ви ізолюєте та забезпечуєте контроль над своїми даними та інтерфейсом користувача від коду помилкового внеску, що виходить за рамки його дизайну та заважає вашій моделі. Це, ймовірно, менше проблем у D8, ніж у D7, хоча деякі гачки залишаються.

Зараз належна архітектура існує для заохочення відокремлення. Не все - це вузол.