Ядро НПЖ — тесносплетённая структура, самостоятельное добавление функционала в которую сопряжено с вопросами целостности и проблемами перехода на более свежие версии ядра. Поэтому НПЖ поддерживает несколько способов наращивания функционала и один из них — расширение через модули --не касается «просто интеграции в существующую систему», а предназначен для подключения дополнительного функционала в НПЖ.
Этот документ описывает способы расширения функционала НПЖ через модули и содержит (возможно) краткую инструкцию по разработке модуля.
Что такое «модуль для НПЖ»?
Модуль в НПЖ — это независимая подструктура в рамках ПО НПЖ, реализующая какой-то специфичный, расширенный функционал.
Файлы модуля находятся за пределами папок core/ и npj/ дистрибутива и поэтому толерантны к обновлению ядра.
Программные механизмы модуля взаимодействуют с ядром по заранее определённым схемам, позволяя добиться разной степени интеграции модуля в среду НПЖ.
Зачем они вообще нужны, эти модули
Модули используются для решения двух типов задач:
для реализации какого-то не-НПЖ функционала в рамках среды НПЖ (т.е. в рамках системы адресации, комментирования, ещё чего-то) для конкретных проектов — это способ создания конкретной инсталляции, насыщенной специфичными модулями;
для создания более универсальных, переносимых и независимых (друг от друга и от обновления ядра) блоков функционала — это способ создания нового продукта на базе среды НПЖ.
Какие уже существуют модули
На момент написания данного документа существует уже более пяти модулей, большая часть которых используется в конкретных инсталляциях. Модуль NPJ Trako — напротив, является универсальным и переносимым.
Кроме существующих, планируется разработка модулей:
модуль настройки пространства НПЖ под специфичную социальную среду;
выделение комплекса настроек «НПЖ как блог» в модуль;
модуль для упорядочения коллекций фильмов и музыки
и другие модули.
Устройство модуля
Устройство модуля можно будет разобрать самостоятельно, скачав один или два из наших демо-модулей.
Пока это невозможно, поскольку инфраструктура находится в стадии рефакторинга. [to be supplied.]
Конфигурация модуля
Модуль подключается в НПЖ через свой файл конфигурации.
Все способы подключения базируются на внесении в файл config_modules.php строк
Важно, что subspace должно совпадать с псевдонимом модуля.
В таком случае вы можете передать управление в модуль в любом месте, дописав в URL или НПЖ-адрес указанное субпространство, например: npj-trako@pixelapes:Panel/Trako.
Впрочем, вы можете ограничить модуль только «корнем узла», прописав:
Такое подключение модуля не обеспечивает «прозрачности» работы стандартных механизмов НПЖ в этом субпространстве, зато даёт богатые возможности по встраиванию совершенно стороннего функционала.
Подключение модуля как аккаунт (прозрачный модуль)
Вы можете подключить модуль «как аккаунт» — чтобы вся работа с НПЖ-объектами в каком-то аккаунте «проходила» через ваш модуль.
В таком случае дополнительные параметры конфигурации выглядят как:
Важно, что таковой аккаунт должен существовать, иначе всё, что вы получите в своё распоряжение — ошибку 404.
Такое подключение делает возможным для модуля оставаться «прозрачным» для НПЖ, перехватывая лишь специфические запросы.
Модуль как «фантомный внешний узел»
Вы можете подключить модуль как «фантомный внешний узел» — чтобы вся работа с НПЖ-объектами в пространстве @phantom/node (где node — это ваш узел, а phantom — некоторое «фантомное» имя для модуля) «проходила» через ваш модуль.
К сожалению, с точки зрения НПЖ каждое подключение модуля возможно только одним из изложенных способов.
Но мы можем этого избежать, написав примерно такой код:
<? $this->modules["channels"] = array( // this module is subspace module "subspace" => "channels", // must be strict equal to modules[<SUBSPACE>] subspace
По-умолчанию, модуль субпространства доступен везде.
Можно это поведение ограничить для определённого класса аккаунтов опцией modules_override = array( “trako” ).
В массиве указывается перечень доступных для данного класса модулей.
«Прозрачный» модуль: внедрение в цикл «редактирование-сохранение»
Мы рассмотрим только случай внедрения для модуля, привязанного к аккаунту.
Для непрозрачного модуля субпространства это гораздо более запутано. На примере можете посмотреть в NPJ Trako.
Всё очень просто: у вашего класса модуля — потомка класса NpjModule необходимо override метод SpawnHelper, сделать так, чтобы он создавал ваш собственный хелпер (например, HelperTrakoIssue для рапортов в Траке) и возвращал его. А уже в хелпере модифицировать и построение форм редактирования, и цикл сохранения в БД.
