Объекты в Друпале 7

Что такое Drupal Entities в Drupal 7? Я понимаю, что Drupal Commerce создала Продукты как Сущность. Теперь я знаю, что есть базовый API-интерфейс Entity и дополнение для Entity API.

В этом году у меня есть несколько проектов, в которых я хотел бы использовать Drupal 7, NoSQL и, возможно, API-интерфейс Entity, если он этого требует, но у меня возникают проблемы с поиском того, где это будет необходимо.

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

Кроме того, можете ли вы по-прежнему иметь возможность общаться с модулями с сущностью и как это сделать? Например, сущность Job Posting получает псевдоним Pathauto и отображается в Views, а также появляется в XML Sitemap.

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

В Drupal 7 Core, узлы, пользователи, комментарии, словари и термины являются сущностями.

В Contrib есть еще много, например, личные сообщения и коммерция, например дюжина из них;)

Тем не менее, я думаю, что объявления о вакансиях прекрасно работают как узлы :) Объекты не имеют автоматической интеграции с Pathauto (Tokens), Views и т. Д.

Объекты - это мета-уровень над узлами, пользователями и т. Д.

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

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

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

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

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

Я начал использовать сущности в нескольких своих проектах для вещей, которые на самом деле не были «контентом». Мы используем их для того, что нас не волнует, когда оно было опубликовано или кем был автор.

Реальные преимущества определения сущностей заключаются в разработке собственных пользовательских модулей. Вы получаете хорошую структуру таблиц и кучу полезных свойств Drupal (Fieldability, Views Views, ...) бесплатно. Больше не нужно создавать свои собственные структуры таблиц или модифицировать тип узла в соответствии с вашими потребностями. Кроме того, мне нравится, насколько они легкие, поэтому сущности с точки зрения производительности должны быть лучше. Если вы выполнили какие-либо запросы в D6 с узлами, вы поймете, что я имею в виду.

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

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

Если вы хотите сказать это в нескольких словах, вы можете сказать, что en entity - это просто часть данных, о которой знает drupal, и которую можно хранить где угодно.