Функционал Features в Open Atrium

Аватар пользователя neochief neochief 5 мая 2010 в 17:25

Заметной проблемой при разработке Drupal приложений становится перенос настроек, сделанных в базе данных и фиксация системы в некотором стабильном состоянии с возможностью отката к нему в случае неудачных экспериментов с настройками. Во многом для решения этих вопросов предназначен пакет компонентов под общим названием Features («фичи»).

С другой стороны «фичи» представляют собой новый уровень абстракции в управлении возможностями системы, предназначенный как для администраторов сайта, так и для пользователей с расширенными возможностями (типа модераторов форумов, администраторов групп в соц. сетях и т.п.). Для этого он предоставляет пользовательские интерфейсы, связанные с настройками, касающимися «контентной» стороны сайта: доступность и расположение контентных блоков, базовые настройки текста.

На текущий момент Features (6.x-1.0-beta6) умеет сохранять:

  • Меню
  • Описание типа контента
  • Контексты
  • Views представления
  • Разрешения
  • Imagecache пресеты
  • Зависимости от других модулей

Если смотреть глубже, то в «Описании типа контента» могут входить поля созданные модулем CCK. А в «Контексты» также входит все что можно включить в контекст: Space type, переменные шаблона, настройки регионов, расположение блоков, пути, пункты меню и другое.

Реализация

На уровне реализации, «фича» представляет собой модуль Drupal, очень тесно интегрированный с несколькими другими модулями, а именно:

  • Views
  • CCK, Fieldgroups
  • Context 2.x, 3.x
  • CTools and CTools exportables implementers
  • ImageCache
  • Spaces 2.x, 3.x
  • Strongarm 2.x

из которых Features, Context, Spaces и Strongarm, разработаны компанией Development Seed.

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

Установка и настройка

Типичным примеров ситуации, когда использование «фич» может принести много пользы, может быть задача создания раздела Webinar на сайте под управлением Open Atrium одного из наших клиентов. В него входит два View с несколькими Display’ами, свой тип контента с расширенным набором атрибутов, специфическое расположение блоков, требующее отдельной настройки, меню, права пользователей по созданию и редактированию контента, а также собственный модуль под задачи этого раздела.

В принципе, в пакет «фичи» может входить и какая-то минимальная функциональность, типа определения View, но для примера лучше использовать множество связанных объектов, объединенных общей задачей.

Шаг 1. Предварительное создание и настройка компонентов.

Сначала делаем всё, как обычно: создаём нужные нам типы контента, расширяем их CCK аттрибутами, создаём нужные View со всеми необходимыми отображениями, формируем настройки контекстов, меню и т.п.

После того, как работа в какой-то мере может считаться сделанной, для того, чтобы её зафиксировать, можно приступить к упаковке всех компонентов в «фичу».

В разделе Features в админке можно видеть список реализованных «фич» с индикатором их состояния (disabled, default, overridden). Там же доступен интерфейс для добавление нового пакета.
features_1.png

Шаг 2. Сборка пакета.

При создании новой «фичи» нужно указать основные настройки, вроде названия и описания, ссылку на источник проверки обновлений (он является в некотором смысле цифровой подписью) и версию, если это нужно.
features_2.png

Далее собираем пакет в интерфейсе, который представляет собой экран выбора компонентов, обнаруженных в системе и доступных для экспорта. На этом этапе вы, хорошо подумав, вспоминаете, что именно должно входить в ваш пакет, отмечаете чекбоксами типы контента, модули, Views и всё остальное. Если что-то забыли, добавить можно будет и потом.
features_3.png

После нажатия на кнопку «Download feature» вы получаете запакованный в архив готовый код вашего пакета, оформленный в виде модуля Drupal, который нужно поместить в директорию с модулями и включить.

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

Шаг 3. Обновление и откат.

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

Вы можете откатить все изменения, если хотите вернуться к состоянию, которое зафиксировано в коде модуля. При этом вы можете выбрать только часть компонентов для отката (например, восстановить настройки только Views).

Если изменения, сделанные после создания «фичи», по вашему мнению, оттестированы и полезны, их можно включить в пакет в интерфейсе «Recreate feature», который аналогичен интерфейсу создания. Здесь можно как изменить набор компонентов, так и просто зафиксировать измененное состояние системы. При этом вы получаете такой же пакет в виде модуля Drupal, которым заменяете существующий у вас на сайте. Таким образом, при условии интеграции с системой контроля версий, и при коммите каждого релиза «фичи», вы получаете возможность откатиться к любой версии настроек сайта и визуально контролировать какие именно изменения произошли в настройках от релиза к релизу.

Управление в Public интерфейсе.

В связке с модулями Spaces, Contexts модуль Feature может быть полезным не только для разработчиков, но и для администраторов сайтов, для которых предоставляется интерфейс управления функциональностью на другом уровне, чем в админке, более упрощенный и ограниченный. Такая возможность реализована, например, в системе Open Atrium, в которой можно управлять интерфейсом в контексте группы пользователей без доступа в админку.

features_5.png

Все, доступные как «фичи», пакеты авторизованный пользователь с нужными правами видит в открытой части сайта в панели управления.

Здесь можно включить или выключить пакет, поменять уровень доступа к нему (public/private), а также перейти к его настройкам.

На странице настроек пакета можно управлять расположением доступных в нем блоков, подписей и т.п.

features_6.png

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

Возможности использования

Для нас, как для разработчиков Drupal приложений, следует обратить внимание на возможности «фичи» как средства фиксации настроек, сделанных в БД в программном коде. Это намного упрощает процесс доставки выполненной работы на тестовые или production-системы. Большая польза в использовании возможности отката в случае нежелательных изменений.

С точки зрения конечного пользователя, «фичи» упрощают управлением функционалом, на примере системы Open Atrium видно как легко можно включить отключить блоги, вебинары, документы, календарь и прочее. Активацией всего одного чекбокса на сайте активируется несколько модулей, импортируется несколько views-представлений, добавляется новые типы материалов и в результате имеем связку модулей которые настроены и готовы к работе.

UPD: Вторая часть

via ShvetsGroup
Автор: Игорь Кучер

0 Thanks

Комментарии

Аватар пользователя mak-vardugin mak-vardugin 5 мая 2010 в 19:13

Спасибо, Александр. Давно хотел разобраться с фичес, еще с доклада про этот модуль на DrupalDay в прошлом году в Москве, но руки не доходили. Теперь я думаю будет проще, понятнее и быстрее!

Аватар пользователя Sinkora Sinkora 5 мая 2010 в 21:32

У меня такое чувство, что такие модули как Features создаются различными компаниями для решения своих конкретных задач. И наверняка, при использовании этого модуля будут возникать проблемы из-за его удивительной универсальности. И ни для кого не секрет, что при активном использовании сторонних модулей у больших проектов начинаются проблемы с совместимостью версий. Неужели это такая заметная проблема при разработке Drupal приложений как "перенос настроек, сделанных в базе данных и фиксация системы в некотором стабильном состоянии с возможностью отката к нему в случае неудачных экспериментов с настройками"? А чем не устраивает обычное резервирование системы? У Друпала и так куча популярных сторонних модулей имеет кучу незакрытых багов/лишнего кода, потому что многие разработчики модулей перестают со временем поддерживать свои модули для сообщества. По-моему, разработчикам больше всего нужен сам Друпал, его архитектура. А чужие модули мне не нужны, я им не доверяю:)

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

Аватар пользователя Dan Dan 5 мая 2010 в 22:33

Ай-яй! Очень зря рассматривать features сразу в Атриуме.
На мой взгляд надо сначала изучить сами features, в "диком" виде, потом в связке со spaces (+Strongarm), а уже потом, как пример конечной реализации - OpenAtrium.

Аватар пользователя Dan Dan 5 мая 2010 в 22:37
"Sinkora" wrote:

А чем не устраивает обычное резервирование системы?

Переносимостью. Я могу сделать фичу блоги, в которую будут входить: тип материала (с CCK-полями), списки (views), возможность ведения групповых блогов (OG), а потом могу всё это хозяйство включить как модуль (!) на другом сайте. А ты как себе представляешь перенос части функционала с другого сайта, если кроме этих блогов мне больше ничего не нужно?

Аватар пользователя neochief neochief 6 мая 2010 в 0:18
"Dan" wrote:

На мой взгляд надо сначала изучить сами features, в "диком" виде

Есть еще вторая часть, в которой об этом. Она будет завтра.

Аватар пользователя neochief neochief 6 мая 2010 в 0:23
"Sinkora" wrote:

У меня такое чувство, что такие модули как Features создаются различными компаниями для решения своих конкретных задач.

Да, примерно так все всегда и происходит. Никто не пишет большие модули просто на интерес. Что касается переносимости этих решений — это уже в руках других компаний, который улучшают модуль своими патчами функциональности. Когда оно превращается в что-то стоящее, но слишком кривое, все дело переписывается с нуля на каком-то спринте на очередной конференции. Заметьте однако, что первая версия собирает фидбек и решения, т.к. изначально толком-то никто не знает что и как решать.

Аватар пользователя Sinkora Sinkora 6 мая 2010 в 2:30
"Dan" wrote:

Переносимостью. Я могу сделать фичу блоги, в которую будут входить: тип материала (с CCK-полями), списки (views), возможность ведения групповых блогов (OG), а потом могу всё это хозяйство включить как модуль (!) на другом сайте.

Это проверено на практике? Если да, то интересно получается.
Судя по описаниям, модуль весьма навороченный)
Но, что в итоге с производительностью? Т.е. в итоге мы получаем "хозяйство-модуль", и насколько в нем все гладко?..

"Dan" wrote:

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

Если честно, я об этом ни разу еще не задумывался. Я бы реализовал нужный функционал на новом сайте по аналогии с сайтом-образцом)

"neochief" wrote:

Есть еще вторая часть, в которой об этом. Она будет завтра.

Ждем продолжения! Что-то меня эти фичи заинтересовали. Сразу, когда прочитал топик, не придал ему особого значения. А теперь вижу, что обзор познавательный. Даже если и не буду этими фичами пользоваться, то хотя бы буду знать, что что-то подобное существует в природе...

"neochief" wrote:

Заметьте однако, что первая версия собирает фидбек и решения, т.к. изначально толком-то никто не знает что и как решать.

Действительно, первооткрывателям большой респект!

Аватар пользователя Oleksa@drupal.org Oleksa@drupal.org 6 мая 2010 в 8:47
"Sinkora" wrote:

Но, что в итоге с производительностью? Т.е. в итоге мы получаем "хозяйство-модуль", и насколько в нем все гладко?..

Причем здесь производительность. Вы не поняли суть модуля

Аватар пользователя Dan Dan 6 мая 2010 в 10:41
"Sinkora" wrote:

Но, что в итоге с производительностью? Т.е. в итоге мы получаем "хозяйство-модуль", и насколько в нем все гладко?..

Модуль импортирует/экспортирует функционал. После импорта/экспорта можете модуль удалить, если очень хочется, хотя если он останется, то тоже есть профит - можно отслеживать обновления. Для этого есть features server, о чём тоже неплохо бы рассказать :)

Аватар пользователя PVasili PVasili 6 мая 2010 в 17:34

Жаль, что данные не сохраняются :(
Всё это счастье нужно только для создания сборок, настройки и конфигурирования функциональных частей, при частом их использовании только до начала работы сайта.

Аватар пользователя Dan Dan 6 мая 2010 в 19:32
"PVasili" wrote:

Жаль, что данные не сохраняются :(

А как же уникальный контент? :)
Настройки переменных можно сохранить с помощью strongarm, а вот контент, ноды и т.д. не сохраняется конечно.

"PVasili" wrote:

только до начала работы сайта.

Features можно обновлять, как и модули. Очень удобно для изменения функционала. Накатил новую версию, если вдруг глюки или клиенту вдруг разонравилось - откатываемся. Или можно вести тестирование фичи отдельно, как только отладили и сдали заказчику функционал - можно переносить на боевой сайт путём обновления.

Аватар пользователя Oleksa@drupal.org Oleksa@drupal.org 6 мая 2010 в 20:59

тоже работали с features, но в итоге решили, что стандартных:
preset export
content copy
views export
panels export и т.п. вполне хватает

Здесь кому как удобней, дело вкуса. Хотя с features все это конечно можно сделать значительно быстрее - но, почему то как то не срослось ) Может после этой статьи попробую их снова.

Аватар пользователя PVasili PVasili 6 мая 2010 в 22:06
"Dan" wrote:

А как же уникальный контент? :)

Dan, ну это при чем? читай внимательно...
Есть работающий сайт. Делаем "снимок". Правим поля CCK, добавляем/удаляем материалы. Решили откатить к "снимку". Конфигурация на месте - часть данных потеряна.

Аватар пользователя orb orb 6 мая 2010 в 22:38
"PVasili" wrote:

Правим поля CCK, добавляем/удаляем материалы.

если в рабочем сайте добавлять и удалять поля, то уровень сайта мягко говоря попахивает неправильным подходом.
А такие правки как переименования ССК полей, перестановка их весов - никак не влияет на Features-модуль и количество созданного/правленого/удаленного материала тоже

Аватар пользователя PVasili PVasili 6 мая 2010 в 23:50
"orb" wrote:

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

скорее наоборот, если сайт постоянно развивается, а не блог с набором полей + всегда хочется что-то улучшить, попробовать оптимизировать и т.д.

Аватар пользователя orb orb 7 мая 2010 в 0:25
"PVasili" wrote:

если сайт постоянно развивается, а не блог с набором полей + всегда хочется что-то улучшить, попробовать оптимизировать

давай мыслить последовательно
есть сайт который работает и все довольны. Через год сайт спланировал как ему развиваться и есть план по добавлению полей ССК и смены оформления, блог расширился и все такое :)
1. Разработчик берет старый features-модуль, настраивает новые поля строго по плану развития, настраивает Виевс и все что там меняется ... после этого всего он получает новый features-модуль (новую версию)
2. Новый модуль устанавливается и это получается контрольная точка.
3. в течении месяца админы могут донастраивать, менять, тасовать и если нужен откат, то откат будет именно на п.2, т.е. на новую версию, правильно ;) Зачем делать откат на ту версию которая была год назад, это уже не откат а деградация :)

в п.3 я написал именно "админы" настраивают сайт, а у админов нет полномочий добавлять/удалять поля ССК.

Аватар пользователя orb orb 7 мая 2010 в 0:27

кстати, а на самом деле данные не удалятся если в п.1 разработчик уберет поля из features-модуля. Данные останутся висеть в БД мертвым грузом
правильно?

Аватар пользователя Dan Dan 7 мая 2010 в 3:12

Что значит "висеть в БД мертвым грузом"? У вас все поля ССК висят мёртвым грузом? Либо они есть и используются, либо их нет и никто не висит.

"PVasili" wrote:

скорее наоборот, если сайт постоянно развивается, а не блог с набором полей + всегда хочется что-то улучшить, попробовать оптимизировать и т.д.

Для этого есть dev-версия сайта. А вообще решений затронутой тобой проблемы с версионностью в БД я хорошего и адекватного решения (в контексте друпала) не вижу. Для полноценного отката надо для каждого модуля писать схемы логики, по которым он меняют данные в БД. Иначе, если мы будем отслеживать всю активность в БД, получим кучу мусора ненужного (watchdog, cache*, session и т.д.) и косвенно задействованные записи (history, node_comments_statistics и т.д.), которые к модулю могут не иметь значения.

Аватар пользователя orb orb 7 мая 2010 в 16:08

есть еще такие наброски http://wst.su/drupal/atrium
справа список с разделами
это пока тестил атриум писал мысли что бы не запутаться.
На статью оно не тянет, но там есть немного про ХУКи

нужно будет как-то обновить эту информацию и оформить как статью

Аватар пользователя orb orb 7 мая 2010 в 16:10
"Dan" wrote:

У вас все поля ССК висят мёртвым грузом? Либо они есть и используются, либо их нет и никто не висит

если создать новый тип материалов с 5ю ССК полями, после чего создать 1000 нод где эти поля заполнены.
Теперь убираем одно из полей ССК из типа материалов, в базе мускула контент этого поля останется?