С текущим состоянием D8, каково дерево решений для создания нового типа объекта контента по сравнению с созданием Типа контента для объекта контента «Узел»?

Мы видели четыре года и первый выпуск Drupal 8 с тех пор, как был принят принятый ответ на вопрос « Когда уместно создавать сущность вместо простого добавления нового типа контента ?» И сущности более важны для Drupal 8, чем они были в Drupal 7. ( RefB , RefC , RefD )

В этом новом мире Drupal 8, каково дерево решений для создания нового типа сущности контента по сравнению с новым типом контента для сущности контента типа "Node"?

Рассматривая ответ, рассмотрите следующее:

• Является ли новый тип контента для типа объекта контента «Узел» все еще уместным в 99% ситуациях по сравнению с новым типом объекта контента?
• Включено ли в дерево решений больше, лучше или яснее причин отклониться от использования типа сущности контента «Узел» и вместо этого создать новый тип сущности контента? И если да, то что они? Они включают в себя:
  • Спектакль?
  • Безопасность / разрешения?
  • Количество модулей, которые работают с типами контента типа объекта узла и не работают с другими типами объекта контента?
• Возможно - на основании предыдущего принятого ответа, на который есть ссылка выше - единственная общая причина для создания пользовательского типа сущности контента - это если вы хотите сгруппировать данные узла, например, с помощью терминов таксономии, или аннотировать узел, например, комментариями?

Совместимость модулей выглядит особенно интересным для дерева решений. В настоящее время лишь немногие из наиболее установленных модулей имеют релиз для 8.x, который не является просто альфа, бета или rc (кандидатом на релиз). И, кажется, трудно определить, сколько из них будет работать «из коробки» с новым пользовательским типом объекта по сравнению с новым типом контента Node-entity. Похоже, что нет атрибута проекта, который бы отличал те, которые «написаны для сущностей» от «написаны для типов контента сущностей узлов».

Взгляните на pathauto, который в настоящее время является четвертым по величине установленным модулем из тех, которые имеют любой выпуск 8.x. Люди усердно работают над версией 8.x, которая обычно поддерживает сущности, а не только типы контента Node-entity-type. Но как насчет всех других модулей? И будут ли модули, которые поддерживают сущности, обычно требовать, чтобы пользовательские типы сущностей контента имели специфичные для модуля «ловушки», прежде чем модуль будет работать с ними? (В отличие от того, как модули могут просто работать прямо из коробки с новыми типами контента?) Похоже, это та проблема, с которой работает команда pathauto, и, возможно, это является причиной отклонения от пользовательского типа сущности контента?

Также стоит упомянуть, что ядро ​​Drupal 8 содержит пользовательский интерфейс для создания новых типов контента для сущности контента типа «Узел», но в настоящее время оно не содержит пользовательского интерфейса для создания новых типов сущностей контента. ( RefX , RefY , RefZ )

Дерево решений для выбора между созданием нового типа контента типа объекта узла и нового типа объекта контента:

1. Вы программист, или у вас есть легкий доступ к программисту?
   • Если нет, то вы в настоящее время в значительной степени ограничены созданием новых типов контента сущности узла. (В ядре нет пользовательского интерфейса для создания новых типов сущностей контента, и модуль вклада Entity Construction Kit (ECK) в настоящее время имеет только альфа-версию.)
   • Если да, то продолжай ...
2. Вы точно знаете, какие модули contrib вы хотите использовать для своих данных?
   • Если нет, то безопаснее всего будет просто создать тип контента Node-entity.
   • Если да, то поддерживают ли эти модули пользовательские типы объектов, которые вы рассматриваете, или вы готовы помочь улучшить их, чтобы они или воссоздали желаемую функциональность в вашем модуле?
     • Если нет, тогда вам лучше всего подойдет просто создание типа контента типа сущности узла.
     • Если да, то продолжай ...
3. Будут ли фактические данные контента, которые включены вашим модулем, просто помогать группировать или комментировать другие данные контента? (Так что это будет редко рассматриваться само по себе.)
   • Если да, то подумайте, похож ли ваш модуль на существующие типы сущностей для терминов и комментариев таксономии. Если это так, то новый тип объекта может быть безопасной ставкой.
   • Если нет, тогда продолжайте ...
4. Можете ли вы четко сформулировать, почему новый тип контента типа сущности узла не будет работать для вас?
   • Если нет, тогда вам лучше всего просто создать новый тип контента типа объекта-узла.
   • Если да, то продолжай ...
5. Наконец, вы уверены, что не можете просто расширить Node-entity-type и что вы хотите воссоздать все его полезные функции, такие как операции CRUD?
   • Если да, тогда создайте новый тип объекта.
   • Если нет, или если вы не уверены, то, возможно, вы захотите привлечь экспертов, которые помогут вам принять решение.

Заметки:

1. Это дерево решений не учитывает производительность или безопасность. Я не уверен, что новый тип объекта контента будет работать лучше и будет более или менее безопасным, чем Node-entity-type.
2. Даже если это дерево является хорошим ответом, оно, вероятно, не останется со временем из-за обновлений в ядре Drupal и выпусках модуля contrib. StackExchange, похоже, не учитывает, что «лучший» ответ сегодня не может быть лучшим ответом завтра.)

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

1. Как тип содержимого узла-сущности по умолчанию влияет на создание проекта простым, аккуратным способом, ближе к архитектуре и потокам данных, полученным из аналитического мышления документации проекта.

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

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

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

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

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

Если у вас есть автор и опубликованное состояние, вы должны выбрать тип контента.

В противном случае (если вы программист) предпочтительнее использовать пользовательские объекты. Многое может быть легко реализовано с помощью всех интерфейсов (таких как ревизионный, полевой, ограничение доступа и т. Д.)

На мой взгляд, это просто более четкая и упорядоченная архитектура (а также более производительная).

Думая о возможности многократного использования в нескольких проектах, стремлении сделать так, чтобы пользовательские сущности взорвались ... есть также отличные помощники, такие как drupal-code-generator . Чтобы сохранить пользовательское кодирование (или сложность) на низком уровне, вы должны рассмотреть возможность использования типов контента, если вы хотите:

• Чтобы перевести «сущность» (по крайней мере, в D7), был бы также интерфейс.
• (открыт для предложений) ..

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

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

В Drupal 8 эта идея намного более реализована, и намного проще начать работу с пользовательским объектом. Сам узел основан на ContentEntityBase, как и блоки, пользователи, файл и таксономия.

Узлы предназначены специально для опубликованных, видимых (или авторизованных) данных контента, которые обычно действуют как контент (то есть в меню, или в карте сайта, или в XML-карте сайта, или в каналах RSS и т. Д.). Drupal был спроектирован таким образом, чтобы вы могли подключиться к любому этапу процесса работы узла и изменить его, что может привести к непредвиденным последствиям, если у вас неправильное сочетание используемых модулей. Это, вероятно, противоречивое мнение, но оно помогает отделить себя от идеи «все есть узел», чтобы больше охватить концепцию сущности.

Идеальный контент, который делает великолепные типы контента:

• Статья
• страница
• Объявление о вакансии
• Мероприятие
• Целевая страница
• домашняя страница

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

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

• Продукт (Drupal Commerce)
• Позиция (Drupal Commerce)
• Поисковый сервер (ApacheSolr / SearchAPI)
• Контакт (например, CRM-лидерство)
• Билет (как билет поддержки)

Что делает их такими разными? Зачем вам нужен объект для контакта, а не использовать модель пользователя? Вы можете привести несколько аргументов, но мой пример будет таким: если вы скажете, собирая адреса электронной почты и имена и некоторые другие метаданные из формы контакта, сохраните эти данные как пользовательский объект. Вы предотвращаете загрязнение списка пользователей элементами, не относящимися к учетной записи, вы уменьшаете потенциальные проблемы с безопасностью (что, если сценарий или кто-то случайно обновил эти учетные записи, чтобы они стали администраторами или отправили массовую почту?), Вы выполняете внутреннее управление накладными расходами фактического пользователя учетные записи легче, и вы сегментируете то, что вы захватываете, к тому, что это, специализированный бит данных

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

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

Другим примером могут быть внешние импортированные данные. В большинстве случаев эти данные обычно не обогащаются локальными данными Drupal (даже если они, как сущность, все еще могут это делать). Это может быть что угодно. Может быть, это счета, может быть, это книги, может быть, это тянет бренды пива.

Такие данные обычно специфичны и требуют контроля за пределами того, для чего предназначен узел. Это не значит, что вы не можете дополнить его, используя поле ссылки на узле, чтобы указать на ваш пользовательский объект (так работает Drupal Commerce, на некотором уровне) для обогащения данных. В то же время вы изолируете и гарантируете контроль над своими данными и пользовательским интерфейсом от ошибочного кода кода, выходящего за рамки его дизайна и мешающего вашей модели. Это, вероятно, меньше проблем в D8, чем это было в D7, хотя некоторые хуки остаются.

В настоящее время существует правильная архитектура для поощрения разделения. Не все это узел.