Как организовать возможность установки плагинов в своих скриптах?

[WebPHPDev]

Есть скрипты, которым требуется поддержка расширениями. Подскажите пожалуйста, хотя бы в общих чертах на теории, каким образом можно подгружать плагины в собственные скрипты - что необходимо учесть в собственных скриптах, что в плагинах?

1. Регистрировать определённые имена функций в плагинах, которые вызывать в скриптах?
2. Если проект на ООП, плагином расширять какой-то основной класс и добавлять нужный функционал?
3. Может какие ещё есть интересные решения?

 

[Mols]

На самом деле описание задачи довольно размытое.
Вот здесь можете посмотреть как реализованы помощники видов.
Может быть подойдет.

 

[WebPHPDev]

Аа.. а если приложение спроектировано по MVC паттерну, то для запуска плагина, наверное достаточно заменить Модель (логику проекта) на другую Модель (из плагина)?

 

[Вурдалак]

Что ты понимаешь тут под плагином?

 

[WebPHPDev]

Что ты понимаешь тут под плагином?

Ну некоторый скрипт, который позволит расширить функционал базового проекта. Как например плагины в WordPress, Joomla, Drupal, которые (легко устанавливаясь/интегрируясь в проект) позволяют получать новые возможности, коими проект до этого не обладал.

 

[A1x]

Аа.. а если приложение спроектировано по MVC паттерну, то для запуска плагина, наверное достаточно заменить Модель (логику проекта) на другую Модель (из плагина)?

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

 

[Духовность™]

Очень интересный вопрос, подпишусь на тему.

Аа.. а если приложение спроектировано по MVC паттерну, то для запуска плагина, наверное достаточно заменить Модель (логику проекта) на другую Модель (из плагина)?

Нет, это совсем не выход. Возможно, придется трогать и контроллер и шаблон страницы.

 

[С.]

Надо различать. Если плагином называть некое [почти] самостоятельное дополнительное приложение, то все просто -- это вызов новой модели.

Другое дело, если плагин это расширение функциональности внутри модели. Например добавить/сменить капчу при отсылке комментария. Вот здесь начинается сущий ад. В общем случае надо разбивать алгоритм на некие атомарные части и проверать, надо ли вызывать какой-нибудь плагин до и поле этого атома.

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

 

[AmdY]

наследование и observer(слушатель)

 

[grigori]

достаточно заменить Модель (логику проекта)

модель - это не логика модель - это данные

С., можно в базовых классах создать система колбеков для реализации поведения (mixin), через них можно выкручивать очень многое
правда, ТС-у это не поможет

 

[Absinthe]

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

Кода строк 10, все очень просто.
Так сделано в вордпрессе.

 

[WebPHPDev]

модель - это не логика модель - это данные

Извиняюсь за апанье старой темы, но всё-таки.

А какие такие это данные в модели? Разве в модели не все подсчёты и внутренний функционал проекта? А контроллер только распределяет какие методы вызывать (из отображения (View) и контроллера) и передаёт им параметры...

 

[Redjik]

Я поддержу, ибо тема и правда интересная. Может нужно было расширяемость декоратором сделать?

 

[grigori]

А какие такие это данные в модели? Разве в модели не все подсчёты и внутренний функционал проекта? А контроллер только распределяет какие методы вызывать (из отображения (View) и контроллера) и передаёт им параметры...

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

 

[Soyer Fintch]

Очень интересно добавлена поддержка плагинов в Flexo CMS, можно просто закинуть в папку с плагинами новый файл и активировать через админку. Кстати исходный код именно ООП ориентирован.

 

[С.]

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

 

[Soyer Fintch]

Раз уж если брать ООП ориентирование, то мне кажется легче всего будет предоставить некий интерфейс с определенными контрактами для классов управляющих плагинами. А уже в скриптах просто вызывать интерфейс с определенными агрументами. Т. е я имею ввиду чтобы, доступ к базовым классам модели и контроллера проходил только через интерфейс.

 

[флоппик]

MONGODB IS WEB SCALABLE :-/

 

[Exilibris]

Ответ на вопрос топикстартера полностью зависит от архитектуры решения (системы), поэтому рассуждать на тему действительно конструктивно, наверное, не получится.
Я считаю, нужно отталкиваться как минимум от взаимозависимостей в логике системы.
Под плагином можно также понимать различные вещи, например, плагин отображения может быть напрямую вызван как отдельная структура, перехватывающая "эстафету"; под плагином непосредственно для логики можно считать более изощренную "инъекцию", основанную на перегрузе функционала (насчет адекватности РНР в этом плане не уверен).
При использовании паттерна MVC влияет не только все вышесказанное, но еще и степень "размазанности" логики между MVC (имхо далеко не везде контроллеры тонкие, а компилируемые шаблоны без переизбытка логики).

P.S. Тема очень актуальна.

 

[stopkran]

Это ключевой вопрос качества фреймворка: насколько сложно добавлять/заменять функционал, затрагивающий уровень сущностей. Спрашивать об этом "как сделать" - всё равно что спрашивать "как сделать хороший фреймворк". Вопрос беспокоит всех, но ответы на него из двух слов выглядят как-то... ни о чём