Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Круто и искать не пришлось, как раз нужно было такое, т.к всё это руками делать ну оочень долго )
Собираетесь переводить проект из песочницы в разряд нормальных?
Собираюсь. Пару недель подержу в песочнице, погоняю на своих проектах, подожду мало-ли кто-то набросает проблем\патчей. Потом подам заявку (не получал еще доступ к полным проектам на друпалорге).
Как решите выйти в нормальный проект, пишите мне, я могу сделать ревью. Это ускорит принятие решения по вам и вашему модулю. Чем чаще будут комментить в вашей заявке — тем она более на виду у админов и вас-таки быстрее утвердят.
Буду крайне признателен.
Напишу тесты для simpletest-а и сразу создам issue.
Напишу тесты для simpletest-а и сразу создам issue.
Заявился: drupal.org/node/1326122
Полезная штука! Мне бы такую год назад и на Д6…
«и интегрироваться с внутренней логикой разных типов сущностей»
Тут вы, что имеете ввиду?
«и интегрироваться с внутренней логикой разных типов сущностей»
Тут вы, что имеете ввиду?
Имею ввиду что разница в бандлах сущностей не всегда ограничивается разным набором полей для них. Вот дать возможность модулям определяющим новый тип сущности через хуки реализовать свою логику наследования (Т.е. реагировать на то когда пользователь создает\редактирует\удаляет наследуемый тип). Но там надо аккуратно все это продумать. Т.к. например в случае с нодами врядли нужно наследовать «настройки публикации».
Интересный модуль, спасибо!
Часть функционала правда можно решить и стандартным путем — в новых типах материалов можно ведь не только создавать новые поля, но и использовать существующие, созданные для других типов материалов.
Часть функционала правда можно решить и стандартным путем — в новых типах материалов можно ведь не только создавать новые поля, но и использовать существующие, созданные для других типов материалов.
Модуль так и работает. Дело в том что в Field API есть 2 разных понятия. Поле и экземпляр поля. Само поля не является привязанным ни к какому типу. Это просто поле. Когда Вы создаете поле первый раз происходит 2 вещи.
1. Создается само поле
2. Экземпляр этого поля прикрепляется к том типу для которого это поле изначально создавалось.
При этом настройки для поля и экземпляра поля различны. При наследовании модуль работает именно с экземплярами. Все отслеживание происходит также по отношению к настройкам экземпляров. Отслеживать сами поля нет смысла т.к. как уже говорилось ранее сами поля не привязаны к типу.
При этом интересно то, что само по себе поле удалить напрямую нельзя. Оно удаляется автоматически если не остается его экземпляров. Довольно элегантная система на мой взгляд.
1. Создается само поле
2. Экземпляр этого поля прикрепляется к том типу для которого это поле изначально создавалось.
При этом настройки для поля и экземпляра поля различны. При наследовании модуль работает именно с экземплярами. Все отслеживание происходит также по отношению к настройкам экземпляров. Отслеживать сами поля нет смысла т.к. как уже говорилось ранее сами поля не привязаны к типу.
При этом интересно то, что само по себе поле удалить напрямую нельзя. Оно удаляется автоматически если не остается его экземпляров. Довольно элегантная система на мой взгляд.
Простите, конечно, за эмоциональность, но специально логинился, чтобы выразить респект и уважуху. Хороший нужный модуль, включу в свою дефолтную сборку друпала.
Рад что Вы рады)
Чужой поток эндорфинов стимулирует мой заставляя дальше трудится на благо community )
Чужой поток эндорфинов стимулирует мой заставляя дальше трудится на благо community )
Мне интересно, что заставило Вас написать таки свой модуль? Я иной раз хочу, но всегда с толку сбивают мысли о том, что это слишком трудоёмко и время жалко. В результате порой костыли.
Я разрабатываю вторую версию коммерческой системы для своей компании (commerce и ubercart ввиду некой спецефичности нашей торговой площадки нас не устраивают). В первой версии все в основном решал костылями т.к. сильно жали сроки. Сейчас подошел к процессу более основательно. При этом решил те модули которые являются сервисными (т.е. не относятся к основной части системы и могут быть использованы отдельно от нее) делать открытыми и выкладывать в комюнити. Drupal очень помог нашему бизнесу и хочется отплатить чем-то хорошим )
Ага, т.е. Вы, по сути, работаете над одним проектом. Это, конечно, другое. У нас на нашем ковейере потратить время на основательную разработку модуля — увы, но роскошь. Хотя и хочется порой.
Сложно конечно говорить не зная особенностей Вашего конвейера, но во многих случаях на мой взгляд легче качественно разработать один модуль и потом свободно подключать его в нужные проекты, чем в виде костылей каждый раз подкручивать все заново.
Хотя бывают разные ситуации. Иногда нужно решить какую-то строго определенную задачу, и если реализовать это в виде костыля на это уйдет N строчек кода. Но если хочешь вынести этот функционал в отдельный модуль часто возникает проблема того, что модуль должен решать не только Вашу а широкий спектр связанных задач. Т.е. должен быть хорошо настраиваемым и расширяемым. А чтобы его таким сделать нужно уже писать N*X строчек кода.
Хотя бывают разные ситуации. Иногда нужно решить какую-то строго определенную задачу, и если реализовать это в виде костыля на это уйдет N строчек кода. Но если хочешь вынести этот функционал в отдельный модуль часто возникает проблема того, что модуль должен решать не только Вашу а широкий спектр связанных задач. Т.е. должен быть хорошо настраиваемым и расширяемым. А чтобы его таким сделать нужно уже писать N*X строчек кода.
Вот то-то и оно, что у нас нет такого, что написание модуля решило бы множество проблем. В каждом проекте какая-то своя вредная мелочь-особенность и решается костылями. Это вот минус разработки на CMS, который пока не удается побороть. Если и создается модуль, то для реализации какого-нибудь там хука типа alter_form().
Правда сейчас как раз, кажется, появились задачи, где нужны модули. Например, фотогалерея с возможностью комментировать отдельно каждую фотографию. Или вывод данных в виде интерактивных графиков.
Правда сейчас как раз, кажется, появились задачи, где нужны модули. Например, фотогалерея с возможностью комментировать отдельно каждую фотографию. Или вывод данных в виде интерактивных графиков.
Ясно.
А галерею через Views не сделать? Каждая фотография отдельная нода. Соответственно каждую можно комментировать.
А галерею через Views не сделать? Каждая фотография отдельная нода. Соответственно каждую можно комментировать.
Увы, делать каждую фотографию нодой — плохой вариант. Представьте себе, как редактор задерется все это дело заливать. Ни разу не удобно.
Тоже правда. На самом деле если рассматривать задачу в комплексе довольно интересно получается. Думал по этому поводу, есть такое неординарное решение.
Сделать тип поля которое бы было ссылкой на ноду.
Как будет работать:
Добавляете к материалу тип поля node_reference (назовем его так, кпримеру)
В настройках поля указываете на ноды какого типа будет ссылаться.
Также как и для любого поля можно указать чтобы количество элементов полей было N или неограничено.
Далее когда добавляете материал, можете сразу в процессе добавления этого материала, также как обычно заполняете поля, заполнить поле ассоциированных нод. После создания материала автоматически создаются эти ноды и связываются с ним. Потом также можно редактировать их либо по отдельности либо из родительского материала.
Вот такая идея. можно развить :)
Сделать тип поля которое бы было ссылкой на ноду.
Как будет работать:
Добавляете к материалу тип поля node_reference (назовем его так, кпримеру)
В настройках поля указываете на ноды какого типа будет ссылаться.
Также как и для любого поля можно указать чтобы количество элементов полей было N или неограничено.
Далее когда добавляете материал, можете сразу в процессе добавления этого материала, также как обычно заполняете поля, заполнить поле ассоциированных нод. После создания материала автоматически создаются эти ноды и связываются с ним. Потом также можно редактировать их либо по отдельности либо из родительского материала.
Вот такая идея. можно развить :)
Такой тип поля есть на самом деле: drupal.org/project/references
И все там есть, о чем говорите. Один минус — оно ссылается на уже созданную ноду. Т.е. чтобы сделать ссылки на фотографии, нужно сначала эти фотографии в виде отдельных нод создать.
И все там есть, о чем говорите. Один минус — оно ссылается на уже созданную ноду. Т.е. чтобы сделать ссылки на фотографии, нужно сначала эти фотографии в виде отдельных нод создать.
А вот вопрос автоматического создания нод решить таки хочется. Он мне для других затей нужен.
Поискал в запросах на функционал (feature requests): drupal.org/node/1004970
Там сказано что реализовывать данный функционал в рамках модуля References не планируется, но уже есть надстройки.
drupal.org/project/nodeconnect
вот вроде то что надо
Там сказано что реализовывать данный функционал в рамках модуля References не планируется, но уже есть надстройки.
drupal.org/project/nodeconnect
вот вроде то что надо
На данный момент на drupal.org нашел связку модулей которая позволяет организовать именно описанный случай.
-Entity reference
-Inline Entity Form
-Entity reference
-Inline Entity Form
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Drupal Bundle Inherit — модуль для наследования типов сущностей