lemark 21 окт 2011 в 01:28

Drupal Bundle Inherit — модуль для наследования типов сущностей

3 мин

2.8K

Drupal*

+22

Комментарии 29

JiLiZART 21 окт 2011 в 06:53

Круто и искать не пришлось, как раз нужно было такое, т.к всё это руками делать ну оочень долго )

vasilyyaremchuk 21 окт 2011 в 08:48

Собираетесь переводить проект из песочницы в разряд нормальных?

lemark 21 окт 2011 в 14:25

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

andyceo 24 окт 2011 в 04:15

Как решите выйти в нормальный проект, пишите мне, я могу сделать ревью. Это ускорит принятие решения по вам и вашему модулю. Чем чаще будут комментить в вашей заявке — тем она более на виду у админов и вас-таки быстрее утвердят.

lemark 24 окт 2011 в 20:01

Буду крайне признателен.
Напишу тесты для simpletest-а и сразу создам issue.

lemark 30 окт 2011 в 00:41

Заявился: drupal.org/node/1326122

andyceo 31 окт 2011 в 00:02

Вам там ответили быстрее, чем я успел. Просят разрабатывать не master-ветке, а ветке, специфичной для версии, т.е. в вашем случае это видимо 7.x-1.x

Также, поставьте модуль Coder и прогоните тесты (без этого от вас все равно не отстанут педанты на drupal.org).

lemark 31 окт 2011 в 00:25

Окей. Создам новый бранч.

Я прогонял. Только я прогонял из меню модулей а не из меню кодера. А оттуда оно по умолчанию прогоняется на нормале. На друпалорге попросили прогнать на миноре.

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

lemark 31 окт 2011 в 22:03

Исправил.

IRuslan 21 окт 2011 в 21:00

Полезная штука! Мне бы такую год назад и на Д6…

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

-1

lemark 21 окт 2011 в 21:52

Имею ввиду что разница в бандлах сущностей не всегда ограничивается разным набором полей для них. Вот дать возможность модулям определяющим новый тип сущности через хуки реализовать свою логику наследования (Т.е. реагировать на то когда пользователь создает\редактирует\удаляет наследуемый тип). Но там надо аккуратно все это продумать. Т.к. например в случае с нодами врядли нужно наследовать «настройки публикации».

IRuslan 22 окт 2011 в 06:05

Да, в принципе интересно получается.

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

Plazik 22 окт 2011 в 16:37

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

lemark 22 окт 2011 в 17:57

Модуль так и работает. Дело в том что в Field API есть 2 разных понятия. Поле и экземпляр поля. Само поля не является привязанным ни к какому типу. Это просто поле. Когда Вы создаете поле первый раз происходит 2 вещи.
1. Создается само поле
2. Экземпляр этого поля прикрепляется к том типу для которого это поле изначально создавалось.
При этом настройки для поля и экземпляра поля различны. При наследовании модуль работает именно с экземплярами. Все отслеживание происходит также по отношению к настройкам экземпляров. Отслеживать сами поля нет смысла т.к. как уже говорилось ранее сами поля не привязаны к типу.

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

Washington 23 окт 2011 в 19:33

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

lemark 23 окт 2011 в 22:20

Рад что Вы рады)
Чужой поток эндорфинов стимулирует мой заставляя дальше трудится на благо community )

Washington 24 окт 2011 в 19:44

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

lemark 24 окт 2011 в 19:52

Я разрабатываю вторую версию коммерческой системы для своей компании (commerce и ubercart ввиду некой спецефичности нашей торговой площадки нас не устраивают). В первой версии все в основном решал костылями т.к. сильно жали сроки. Сейчас подошел к процессу более основательно. При этом решил те модули которые являются сервисными (т.е. не относятся к основной части системы и могут быть использованы отдельно от нее) делать открытыми и выкладывать в комюнити. Drupal очень помог нашему бизнесу и хочется отплатить чем-то хорошим )

Washington 24 окт 2011 в 20:07

Ага, т.е. Вы, по сути, работаете над одним проектом. Это, конечно, другое. У нас на нашем ковейере потратить время на основательную разработку модуля — увы, но роскошь. Хотя и хочется порой.

lemark 24 окт 2011 в 20:23

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

Хотя бывают разные ситуации. Иногда нужно решить какую-то строго определенную задачу, и если реализовать это в виде костыля на это уйдет N строчек кода. Но если хочешь вынести этот функционал в отдельный модуль часто возникает проблема того, что модуль должен решать не только Вашу а широкий спектр связанных задач. Т.е. должен быть хорошо настраиваемым и расширяемым. А чтобы его таким сделать нужно уже писать N*X строчек кода.

Washington 24 окт 2011 в 20:55

Вот то-то и оно, что у нас нет такого, что написание модуля решило бы множество проблем. В каждом проекте какая-то своя вредная мелочь-особенность и решается костылями. Это вот минус разработки на CMS, который пока не удается побороть. Если и создается модуль, то для реализации какого-нибудь там хука типа alter_form().
Правда сейчас как раз, кажется, появились задачи, где нужны модули. Например, фотогалерея с возможностью комментировать отдельно каждую фотографию. Или вывод данных в виде интерактивных графиков.

lemark 24 окт 2011 в 21:25

Ясно.
А галерею через Views не сделать? Каждая фотография отдельная нода. Соответственно каждую можно комментировать.

Washington 24 окт 2011 в 21:30

Увы, делать каждую фотографию нодой — плохой вариант. Представьте себе, как редактор задерется все это дело заливать. Ни разу не удобно.

lemark 24 окт 2011 в 22:16

Тоже правда. На самом деле если рассматривать задачу в комплексе довольно интересно получается. Думал по этому поводу, есть такое неординарное решение.
Сделать тип поля которое бы было ссылкой на ноду.
Как будет работать:
Добавляете к материалу тип поля node_reference (назовем его так, кпримеру)
В настройках поля указываете на ноды какого типа будет ссылаться.
Также как и для любого поля можно указать чтобы количество элементов полей было N или неограничено.

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

Вот такая идея. можно развить :)

Washington 24 окт 2011 в 22:24

Такой тип поля есть на самом деле: drupal.org/project/references
И все там есть, о чем говорите. Один минус — оно ссылается на уже созданную ноду. Т.е. чтобы сделать ссылки на фотографии, нужно сначала эти фотографии в виде отдельных нод создать.

Washington 24 окт 2011 в 22:25

А вот вопрос автоматического создания нод решить таки хочется. Он мне для других затей нужен.

lemark 24 окт 2011 в 22:35

Поискал в запросах на функционал (feature requests): drupal.org/node/1004970
Там сказано что реализовывать данный функционал в рамках модуля References не планируется, но уже есть надстройки.

drupal.org/project/nodeconnect
вот вроде то что надо