В чем преимущество создания новых типов сущностей по сравнению с созданием нового типа контента?
Кажется немного излишним делать все пользовательское кодирование, необходимое для создания нового объекта, когда у вас уже есть все функции CRUD и Views, уже встроенные в типы контента.
Ответы:
Дело не столько в преимуществах, сколько в том, что подходит для конкретной ситуации, как вы сказали. Вы можете представлять практически все с помощью узла, и в 99% случаев (как я обнаружил, по крайней мере) вам не нужно реализовывать пользовательские типы объектов.
Я всегда считаю taxonomy_termтип сущности хорошим примером того, почему не все должно быть типом узла / типа контента:
Термин таксономия по существу предназначен для группировки разных сущностей и поэтому не требует той же функциональности, что и узел. Хотя теоретически вы могли бы использовать тип контента для выполнения этой функции (возможно, с полем ссылки на узел), термину таксономии не нужно делать то же самое, что и узлу, поэтому в действительности это не имеет смысла. То же самое можно сказать о userи taxonomy_vocabularyсущностях типов.
Таким образом, термин таксономии создается как отдельная сущность и запрограммирован делать только то, что ему нужно, при этом получая преимущества возможности присоединения полей и т. Д.
Я думаю, что простой ответ заключается в том, что когда узел / тип контента не выполняет то, что вам нужно, или это просто огромное количество избыточных ресурсов / издержек для очень небольшой выгоды, тогда вы должны написать собственный объект.
Это только на основе моего личного опыта; Мне было бы интересно услышать, что кто-то, непосредственно связанный с разработкой ядра Drupal, должен сказать об этом.
Очень простое практическое правило, которое я использую, заключается в том, нужно ли публиковать ваш контент самостоятельно. Если это так, то перейдите на узел, если нет, выберите объект. Entityforms теперь позволяет создавать интерфейс для заполнения ваших сущностей.
Например, на веб-сайте, созданном с помощью D6, мы создаем тип рекламного контента (с его полем изображения, датой начала / конца отображения ...), но затем вы должны сделать так, чтобы он не был опубликован по умолчанию, и предоставить своим редакторам права на редактирование. / просмотреть эти узлы и надеемся, что ни один просмотр / поиск не отобразит их во внешнем мире. Это довольно громоздко, и было бы легче иметь дело с юридическими лицами.
Сущность представляет конкретный вариант использования .
Я считаю, что заслуга в этом простом определении принадлежит Фаго , но мне лень найти ссылку.
Мы могли бы использовать Content(иначе Nodes) для всех вариантов использования, если бы захотели, но часто это не имеет смысла.
Content имеет автора и настройки для комментариев и расположения меню.
Users, представляют собой случай использования, достаточно отличный от того, Contentчто userни в одном из вышеперечисленных случаев нет никакого смысла, в то время как с другой стороны, он userдолжен иметь адрес электронной почты и пароль.
Taxonomy terms Выделиться, потому что они имеют встроенную функциональность, чтобы быть организованы в иерархии, даже круговой.
Если ваш вариант использования достаточно похож на существующую сущность, перейдите к использованию этой сущности. Если ваша сущность подчиняется правилам, существенно отличающимся от существующих, создайте новый.
Также есть «Введение в сущности» , но, к сожалению, оно не отвечает на ваш вопрос.
Я думаю, что это все о контексте, узел в основном используется для контента, таким как блоги, статьи, часто задаваемые вопросы и т. Д. В то время как пользователь для таких профилей, как персонал, клиенты и т. Д. Пример того, когда вы можете создать новую организацию:
Хотя вы можете использовать узел для чего-то вроде заявки в службу поддержки, он может быть не лучшим шаблоном и по умолчанию ... Надеюсь, это поможет.
Объекты могут создаваться с меньшими накладными расходами, чем узлы, поскольку им не нужно иметь все функциональные возможности, которые имеют объекты.
Это также означает, что хранилище может быть проще - вы можете построить их так, чтобы захватить всю информацию простым запросом без JOINS, если хотите. Все поля красиво в одной аккуратной таблице.
Это может быть огромным преимуществом, если у вас много функций, которые должны выполнять запросы к сущностям, и вы одновременно обновляете множество сущностей с помощью запросов UPDATE в базу данных. Если вы можете быть уверены, что данные относительно автономны в одной таблице, у вас меньше забот и возможностей повреждения данных.
Тип контента предназначен для контента сайта. То есть каждый тип контента предназначен для публикации и отображения на сайте. Например, статья (из коробки) предназначена для отображения на первой странице.
Теперь предположим, что вы хотите создать что-то вроде заявления о приеме на работу или в квартире. Очевидно, что вы не захотите публиковать чью-либо заявку на работу на своем веб-сайте. Кроме того, что, если вы хотите составить список контактов клиентов / ведущих? Хотите ли вы рискнуть, что эта информация может быть ошибочно опубликована на вашем веб-сайте? Лично я бы не стал.
Следовательно, модуль формы объекта, который обсужден выше. Это позволяет вам создавать тип сущности, который не предназначен для содержания. Однако эти типы сущностей доступны любому модулю, который поддерживает только такие сущности, как правила, представления и органические группы.
И тогда вы попадаете в Drupal Commerce, где продукты являются типами сущностей. По сути, сущности позволяют разработчикам расширять Drupal так, как это никогда не предполагалось первоначальными дизайнерами Drupal.
Это подлежит обсуждению, и, в конце концов, вы должны принять решение как разработчик.
Я выбираю сущности вместо узлов, когда данные не должны быть общедоступными с их собственным URL. Узлы по умолчанию получают псевдоним URL, опубликованный статус, заголовок, метатеги, ... а сущности просто получают запись в базе данных.
«Я хочу добавить как можно больше баннеров с текстом, а затем в блоге выбрать один из них»
Сущность против контента
У сущности есть Связки сущностей с полями
Контент - это тип сущности. Так,
Контент имеет пакеты контента (статья, страница), которые имеют поля (тело, изображение статьи)
Если вы программист, вы наверняка выберете путь создания своей сущности, но для создателей сайтов это может быть не лучшим путем. Опять же, для создателей сайтов есть интерфейс для создания Entity http://drupal.org/project/eck