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

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

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

Как вы считаете, ответьте на вопрос:

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

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

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

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

26 голосов | спросил Jon Freed 12 AMpTue, 12 Apr 2016 02:28:28 +030028Tuesday 2016, 02:28:28

4 ответа


16

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

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

Примечания:

  1. Это дерево решений не учитывает производительность или безопасность. Я не уверен, что если новый тип сущности для персонализированного контента будет работать лучше и быть более или менее безопасным, чем тип объекта Node.
  2. Даже если это дерево является хорошим ответом, оно, вероятно, не останется со временем из-за обновлений в выпусках ядра Drupal и Contrib. StackExchange, похоже, не соответствует тому, как «лучший» ответ сегодня может быть не лучшим завтра.)
ответил Jon Freed 12 AMpTue, 12 Apr 2016 02:28:28 +030028Tuesday 2016, 02:28:28
3

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

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

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

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

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

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

ответил Mohammed Gomma 17 PMpSun, 17 Apr 2016 23:49:00 +030049Sunday 2016, 23:49:00
3

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

  

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


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

  

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

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

  • Чтобы перевести «сущность» (по крайней мере, в D7), будет также интерфейс.
  • (открыт для предложений) ..
ответил rémy 19 PMpTue, 19 Apr 2016 14:30:08 +030030Tuesday 2016, 14:30:08
3

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

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

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

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

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

  • Статья
  • Страница
  • Размещение объявлений
  • Событие
  • Страница приземления
  • Главная

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

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

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

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

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

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

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

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

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

ответил Kevin 19 PMpTue, 19 Apr 2016 16:39:17 +030039Tuesday 2016, 16:39:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132