Какие системы плагинов для движков бывают?

Visman · 2011-06-22 19:41:46

Задумался тут:
А как реализуются расширения/изменения движков сайтов/фоумов без вмешательства в код ручной правкой?

На PunBB и некоторых сайтовых движках это хуки. А другие принципы какие? И где почитать можно о них?

hcs · 2011-06-23 06:27:42

Паттерн Observer - http://ru.wikipedia.org/wiki/Наблюдател … тирования)
В старом cohana это специальный объект Event - http://docs.kohanaphp.com/core/event , наверное можно назвать его делегатом.
Это ООП.
Если речь о процедурном подходе, то в fluxbb кто-то предлагал специальные комментарии в коде. При установке расширения, в места этих комментариев вставляется код расширений.
И хуки типа как в punbb.

hcs · 2011-06-23 06:33:48

Вот еще вариация на тему: http://fluxbb.org/forums/viewtopic.php?id=5410

artoodetoo · 2011-06-23 11:56:19

@hcs, наверное не будет ошибкой сказать что все системы плагинов реализуют паттерн Observer. Только делают они это по-разному.

То, что по ссылке, очень напоминает Drupal.
Drupal — уникальный случай успешного проекта без использования конструкции class. Это не значит, что ООП отсутствует, просто объектность реализуется особым манером.
Плагины и хуки в Drupal: если в системе зарегистрирован модуль с именем foo и просигналено некое событие по имени bar, то система попытается найти функцию с именем foo_bar. Если она определена, то будет вызвана.

Offtopic: на друпаловских сайтах популярен лозунг «All content management systems suck, Drupal just happens to suck less», т.е. «всё cms говно, друпал всего-лишь меньшее говно». Я бы перефразировал это и взял на вооружение для FluxBB. Флаксовая фраза «никто не знает что это за хрень пока не попробует» помоему полный провал в плане маркетинга.

artoodetoo · 2011-06-29 11:48:32

Как-то быстро сникло обсуждение. Тема реально богатая. Давайте рассмотрим такую схему:
Есть "события", к которым можно привязать свой обработчик. Там, где вызывается событие, пишем так (использую стандарт кодирования PunBB/FluxBB):

raise_event('my_event', $context);

здесь $context это данные, специфичные для этого события, больше никакой информации — обработчики должны знать что за данные они собираются обрабатывать.
При вызове raise_event() должны просматриваться списки всех заинтересованных в этом собитии. Значит должен быть способ зарегистрироваться:

function my_event_handler($event, $context)
{
// ... 
}

// ...

register_event_handler('my_event', ''my_event_handler');

Остается придумать какое-то соглашение по подключению плагинов. Жаль слово "плагин" для Fluxbb уже имеет другой смысл … соглашение по подключению модулей. Можно так:

Заводим папку /modules/ и складываем в нее под-папки с файлами модулей. В каждой такой папке /modules/modulename/index.php будет содержать инициализацию модуля (регистрацию обработчиков событий + что там еще понадобится на старте).

В файл include/common.php добавим код просмотра под-папок в /modules/ и подключение оттуда index. Все! Наша система плагинов готова. Подключение плагина — это копирование его папки на сервер.

Как вам нравится?

Visman · 2011-06-29 11:56:25

@artoodetoo, как это скажется на быстродействии?

Может стоит "извратиться" с комментами-маркерами по коду движка и написать системку, которая на сервере будет вносить изменения в код.

artoodetoo · 2011-06-29 13:14:00

любой доп. функционал снижает быстродействие. но это должно работать лучше eval() + инициализация через xml

да, комменты-под-патч были бы самым щадящим способом (или «…всего-лишь меньшее говно» )

hcs · 2011-06-29 20:31:14

artoodetoo пишет:

Как вам нравится?

Инициализация через xml в punbb только при инсталировании расширения. После установки только eval. Если eval исполнит одну строку include\require, будет ли это так плохо?
Рикард в своё время настаивал на eval по причине общей области видимости переменных.
В случае же

raise_event('my_event', $context);

что передадим в $context ? Что вернем из обработчика? Будем передавать параметры по ссылке?
А обработчик например нуждается в $base_url и $forum_config - их тоже передавать в контексте? А зачем их передавать, если можно получить доступ через globals? Если вызывать событие из функции, то её контекст уместен, в противном случае зачем передавать контекст, если все доступно через globals?
Одним хэндлерам нужно формировать и передавать контекст, другим не нужно - разные типы хэндлеров?
Если бы этот вариант строго следовал Observer, то с контекстом было бы проще - передал ссылку на себя или на объект с нужным интерфейсом. Но в таком случае инициатор события должен быть сам объектом или работать с объектом, который следует передать по цепочке?
Вывод: для полноценного Observer'а движок должен быть построен на ООП.

Комменты-под-патч vs eval.
Пока нет псевдо-компилятора "пересобирающего" исполняемое ядро. Сколько нужно времени чтобы его создать? Какова будет его эффективность, т.е. насколько "пересобранное" ядро будет быстрее\легче аналогичного ядра расширенного аналогичной функциональностью но с использованием eval?
Не получится ли это экономией на спичках, с большими трудозатратами в разработке?
Я думаю что так и будет. Для маркетинга хорошо - обычный скрипт выполняется 20мс, а наш 10!

Visman · 2011-06-29 20:35:48

@hcs, какой механизм расширений будет в PunBB 2.0?

artoodetoo · 2011-06-29 21:47:17

hcs пишет:

artoodetoo пишет:
Как вам нравится?
Инициализация через xml в punbb только при инсталировании расширения. После установки только eval. Если eval исполнит одну строку include\require, будет ли это так плохо?
Рикард в своё время настаивал на eval по причине общей области видимости переменных.

Рикард признал, что этот механизм неудачный.

Проблемы с видимостью -- это проблемы плохого планирования.

hcs пишет:

В случае же
raise_event('my_event', $context);
что передадим в $context ? Что вернем из обработчика? Будем передавать параметры по ссылке?

Зависит от того, что мы хотим в итоге. Если цель сгенерировать некий кусок HTML, то ничего не возвращаем, просто делаем echo. Если этот вызов должен подготовить данные для последующих событий (on_before.. | on_after... чего-то-там), то вероятно он должен заполнить какие-то внутренние структуры, не надо ничего возвращать. В общем, "зависит от контекста"

hcs пишет:

А обработчик например нуждается в $base_url и $forum_config - их тоже передавать в контексте? А зачем их передавать, если можно получить доступ через globals? Если вызывать событие из функции, то её контекст уместен, в противном случае зачем передавать контекст, если все доступно через globals?

Сам факт существования глобальных переменных в движке это болезнь. Лекарства есть: проще всего решается через паттерн Реестр.

hcs пишет:

Одним хэндлерам нужно формировать и передавать контекст, другим не нужно - разные типы хэндлеров?
Если бы этот вариант строго следовал Observer, то с контекстом было бы проще - передал ссылку на себя или на объект с нужным интерфейсом. Но в таком случае инициатор события должен быть сам объектом или работать с объектом, который следует передать по цепочке?
Вывод: для полноценного Observer'а движок должен быть построен на ООП.

Согласен. Если бы был ООП, было бы проще. Из того, что проблемы есть НЕ следует, что не надо стремиться к лучшему. Меня в последнее время занимает именно этот вопрос: как эволюционировать к бОльшему ООП. Причем я четко понимаю: объектность это не частое употребление слова "class", а продуманное разделение данных. Drupal написан "объектно", а PunBB/FluxBB нет.

hcs пишет:

Комменты-под-патч vs eval.
Пока нет псевдо-компилятора "пересобирающего" исполняемое ядро. Сколько нужно времени чтобы его создать? Какова будет его эффективность, т.е. насколько "пересобранное" ядро будет быстрее\легче аналогичного ядра расширенного аналогичной функциональностью но с использованием eval?
Не получится ли это экономией на спичках, с большими трудозатратами в разработке?
Я думаю что так и будет. Для маркетинга хорошо - обычный скрипт выполняется 20мс, а наш 10!

Изначально этот движок и позиционировался так: он не очень функционален, зато быстрый и нетребовательный к памяти. В текущем состоянии PunBB стал несколько более функциональный, но точно потерял в скорости и вырос в памяти. То есть он должен позиционироваться как-то иначе. По настоящему расширяемым он не стал, т.к. он не-ООП и по прежнему не имеет полноценных шаблонов вывода.

Возможно FluxBB 2.0 будет более удачной попыткой перейти в новую весовую категорию. А может быть и нет.

artoodetoo · 2011-06-30 01:44:09

Если eval исполнит одну строку include\require, будет ли это так плохо?

i.f.a.i.k. этого достаточно чтобы кешер опкода отказался работать с этим файлом (с вызывающим, а не с подключаемым), а если евалы присутствуют везде, значит не будет кешироваться ничего.

Freeman · 2011-07-03 16:47:19

Мне кажется, что в способе, описанном artoodetoo, ключевым является понятие контекста. Чтобы в движке появились контексты, нужен анализ, соглашения по API и т. п. Если эта работа будет проделана, она точно не будет лишней, и код выиграет в любом случае.

artoodetoo пишет:

да, комменты-под-патч были бы самым щадящим способом

Можно сделать и так: для только что открывшегося форума -- гибкий вариант с папкой, для высоконагруженного, когда уже всё оттестировано -- вставка кода в место вызова, inline. Для него ведь достаточно комментариев с ключами в коде? Можно/нужно сделать штатной фичей, как ngen в .NET.

Главное -- не физический способ подключения модулей, главное -- декомпозиция и API.

Русское сообщество fluxbb

Объявление

#1 2011-06-22 19:41:46

Какие системы плагинов для движков бывают?

#2 2011-06-23 06:27:42

Re: Какие системы плагинов для движков бывают?

#3 2011-06-23 06:33:48

Re: Какие системы плагинов для движков бывают?

#4 2011-06-23 11:56:19

Re: Какие системы плагинов для движков бывают?

#5 2011-06-29 11:48:32

Re: Какие системы плагинов для движков бывают?

#6 2011-06-29 11:56:25

Re: Какие системы плагинов для движков бывают?

#7 2011-06-29 13:14:00

Re: Какие системы плагинов для движков бывают?

#8 2011-06-29 20:31:14

Re: Какие системы плагинов для движков бывают?

#9 2011-06-29 20:35:48

Re: Какие системы плагинов для движков бывают?

#10 2011-06-29 21:47:17

Re: Какие системы плагинов для движков бывают?

#11 2011-06-30 01:44:09

Re: Какие системы плагинов для движков бывают?

#12 2011-07-03 16:47:19

Re: Какие системы плагинов для движков бывают?

Подвал доски