Когда уместно создавать Entity или просто добавлять новый тип контента?

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

Я всегда думаю о типе сущностей taxonomy_term как хороший пример того, почему не все должно быть типом узла /содержимого:

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

Таким образом, термин таксономии создается как отдельный объект и запрограммирован на то, чтобы делать только то, что ему нужно, при этом все еще получая преимущества от возможности прикреплять поля и т. д.

Я думаю, что простой ответ заключается в том, что когда тип node /content не выполняет то, что вам нужно, или это просто огромное количество излишних /накладных расходов для очень мало пользы, тогда вы должен выбрать запись пользовательского объекта.

Это основано только на моем личном опыте; Мне было бы интересно услышать, что кто-то, кто непосредственно связан с разработкой Drupal, должен был сказать об этом.

Очень простое эмпирическое правило, которое я использую, заключается в том, должен ли ваш контент публично отображаться сам по себе. Если это так, то перейдите к узлу, если не выберите объект. Entityforms теперь позволяет вам создать интерфейс для заполнения ваших объектов.

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

Сущность представляет конкретный вариант использования .

Я считаю, что кредит для этого простого определения относится к Fago , но я должен лениться, чтобы найти ссылку.

Мы могли бы использовать Content (aka Nodes) для всех случаев использования, если мы этого хотели, но часто это не имеет смысла.

Content имеет автора и настройки для комментариев и расположения меню.

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

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

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

Существует также Знакомство с объектами , но, к сожалению, он не отвечает на ваш вопрос.

Я думаю, что это все о контексте, узел в основном используется для контента, поэтому это будут блоги, статьи, faq и т. д. В то время как пользователь для профилей, таких как персонал, клиенты и т. д. Пример того, когда вы можете создать новую enitity:

• Форум
• Проект (с точки зрения управления проектами)
• Форма
• Талон поддержки
• Группа

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

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

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

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

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

Entity vs Content

Объект имеет Связки объектов , которые Поля

Контент - это тип Entity. Таким образом,

Контент имеет Пакеты контента (статья, страница), которые Поля (тело, изображение статьи)

Если вы программист, вы, конечно, выбираете путь создания собственной сущности, но для сайтостроителей это может быть не лучший путь. Снова для разработчиков сайтов существует пользовательский интерфейс для создания Entity http://drupal.org/project/eck