Сложно конечно говорить не зная особенностей Вашего конвейера, но во многих случаях на мой взгляд легче качественно разработать один модуль и потом свободно подключать его в нужные проекты, чем в виде костылей каждый раз подкручивать все заново.
Хотя бывают разные ситуации. Иногда нужно решить какую-то строго определенную задачу, и если реализовать это в виде костыля на это уйдет N строчек кода. Но если хочешь вынести этот функционал в отдельный модуль часто возникает проблема того, что модуль должен решать не только Вашу а широкий спектр связанных задач. Т.е. должен быть хорошо настраиваемым и расширяемым. А чтобы его таким сделать нужно уже писать N*X строчек кода.
Я разрабатываю вторую версию коммерческой системы для своей компании (commerce и ubercart ввиду некой спецефичности нашей торговой площадки нас не устраивают). В первой версии все в основном решал костылями т.к. сильно жали сроки. Сейчас подошел к процессу более основательно. При этом решил те модули которые являются сервисными (т.е. не относятся к основной части системы и могут быть использованы отдельно от нее) делать открытыми и выкладывать в комюнити. Drupal очень помог нашему бизнесу и хочется отплатить чем-то хорошим )
Модуль так и работает. Дело в том что в Field API есть 2 разных понятия. Поле и экземпляр поля. Само поля не является привязанным ни к какому типу. Это просто поле. Когда Вы создаете поле первый раз происходит 2 вещи.
1. Создается само поле
2. Экземпляр этого поля прикрепляется к том типу для которого это поле изначально создавалось.
При этом настройки для поля и экземпляра поля различны. При наследовании модуль работает именно с экземплярами. Все отслеживание происходит также по отношению к настройкам экземпляров. Отслеживать сами поля нет смысла т.к. как уже говорилось ранее сами поля не привязаны к типу.
При этом интересно то, что само по себе поле удалить напрямую нельзя. Оно удаляется автоматически если не остается его экземпляров. Довольно элегантная система на мой взгляд.
Имею ввиду что разница в бандлах сущностей не всегда ограничивается разным набором полей для них. Вот дать возможность модулям определяющим новый тип сущности через хуки реализовать свою логику наследования (Т.е. реагировать на то когда пользователь создает\редактирует\удаляет наследуемый тип). Но там надо аккуратно все это продумать. Т.к. например в случае с нодами врядли нужно наследовать «настройки публикации».
Собираюсь. Пару недель подержу в песочнице, погоняю на своих проектах, подожду мало-ли кто-то набросает проблем\патчей. Потом подам заявку (не получал еще доступ к полным проектам на друпалорге).
Читал эту статью, но там совсем другие проблемы рассматриваются. Концепция сущностей фундаментальна и довольно строго определена. Уж сущности то точно из ядра выпиливать не надо. Другое дело что в 8ке наверное имеет смысл выпилить ноды из комплекта базовой поставки.
Не знаю, меня в свое время перевод вполне устроил. Была вроде пара несостыковок в каких-то моментах, но в целом довольно приличная книга.
А по 7ке недавно перевели www.ozon.ru/context/detail/id/6967116/
Честно скажу сам не читал и не собираюсь (официальной документации на drupal.org хватает), но знакомые о ней неплохо отзывались.
Как написать модуль Вы можете прочитать в учебнике) Сейчас на русский язык перевели один неплохой.
В этой же статье я описал работу с сущностями. К слову если Вас интересует создания типов материалов это тоже не является темой данной статьи. Вообще говоря по сравнению с Drupal 6 в определении нового типа ноды особо ничего не поменялось.
В общем случае действительно не рекомендуется. Просто если объявляешь конструктор в интерфейсе надо четко понимать зачем ты это делаешь. И еще раз повторюсь, что в данном случае считаю решение разработчиков определить конструктор в интерфейсе вполне логичным и обоснованным.
Да, хоть это и не является каноническим подходом к пониманию интерфейсов, в PHP можно определять в интерфейсах конструкторы, деструкторы и так называемые «magick methods». На мой взгляд в данном случае это вполне уместно, т.к. однозначно определяется набор аргументов (точнее говоря единственный аргумент) передаваемый в конструктор. Я уже ссылался в статье, но вот: DrupalEntityControllerInterface DrupalEntityControllerInterface::__construct
А галерею через Views не сделать? Каждая фотография отдельная нода. Соответственно каждую можно комментировать.
Хотя бывают разные ситуации. Иногда нужно решить какую-то строго определенную задачу, и если реализовать это в виде костыля на это уйдет N строчек кода. Но если хочешь вынести этот функционал в отдельный модуль часто возникает проблема того, что модуль должен решать не только Вашу а широкий спектр связанных задач. Т.е. должен быть хорошо настраиваемым и расширяемым. А чтобы его таким сделать нужно уже писать N*X строчек кода.
Напишу тесты для simpletest-а и сразу создам issue.
Чужой поток эндорфинов стимулирует мой заставляя дальше трудится на благо community )
1. Создается само поле
2. Экземпляр этого поля прикрепляется к том типу для которого это поле изначально создавалось.
При этом настройки для поля и экземпляра поля различны. При наследовании модуль работает именно с экземплярами. Все отслеживание происходит также по отношению к настройкам экземпляров. Отслеживать сами поля нет смысла т.к. как уже говорилось ранее сами поля не привязаны к типу.
При этом интересно то, что само по себе поле удалить напрямую нельзя. Оно удаляется автоматически если не остается его экземпляров. Довольно элегантная система на мой взгляд.
А по 7ке недавно перевели www.ozon.ru/context/detail/id/6967116/
Честно скажу сам не читал и не собираюсь (официальной документации на drupal.org хватает), но знакомые о ней неплохо отзывались.
В этой же статье я описал работу с сущностями. К слову если Вас интересует создания типов материалов это тоже не является темой данной статьи. Вообще говоря по сравнению с Drupal 6 в определении нового типа ноды особо ничего не поменялось.
DrupalEntityControllerInterface
DrupalEntityControllerInterface::__construct