Создать & quot; Движок & quot; разрешить интеграцию в основное веб-приложение?

Основываясь на вашем обновлении, я думаю, что вы описываете хороший пример для веб-приложения, которое должно стать модульным. Вы хотите иметь возможность легко добавлять новые модули (плагины), которые предоставляют различные функции, без необходимости каждый раз менять ядро ​​приложения.

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

---

Теоретическая сторона вещей

1. Плагины / модули

Каждый плагин включает набор специфических функций и должен работать независимо от других плагинов, которые включены в данный момент. Все плагины должны будут следовать общему набору правил и соглашений, чтобы их распознало ваше приложение. Это значительно упростит будущее обслуживание и расширение. Например, каждый плагин должен:

• Иметь свой собственный подкаталог в папке плагинов / модулей, которая соответствует предварительно определенной структуре (например, Backend / Portlets / InstallScripts и т. д.)

• Используйте отдельную песочницу для хранения в вашей базе данных, посвященный только этому плагину. Возьмите Kashflow — все таблицы, которые используются плагином, могут начинаться с префикса ksflw_.

• Принесите свою собственную частичную презентацию (ы) внешнего интерфейса (вместе с базовой логикой и моделью контроллера), которые реализуют определенные наборы функций (например, отображают предварительно выбранные книги в оранжевой рамке)

• Принесите свой собственный частичный Backend представление презентации (вместе с базовым контроллером и моделью), которые обрабатывают в бэкэнде сайта (в случае Kashflow у вас есть визуализация портлета, которая, возможно, отображает кнопку для ручной синхронизации, позволяет запланировать ее и отображает дату и время последней выполненной синхронизации)

• Есть установочный скрипт, который создает таблицы, вставляет пункты меню и инициализирует подписки хуков (см. следующий пункт)

• Инициализировать подписки Hooks — Все подписанные функции плагина вызываются всякий раз, когда зарегистрированное событие происходит где-то в системе.

---

2. Основные функциональные изменения

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

• Менеджер плагинов — GUI, который позволяет устанавливать, удалять, включать / отключать плагины и разрешать доступ к ним для ваших клиентов.

• Менеджер частичных просмотров — позволяет пользователям выбирать, какие частичные представления каких плагинов будут отображаться в каких существующих заполнителях (это будет работать в сочетании с хуками)

• Заполнители для частичных просмотров на страницах в тех местах, где вы хотите, чтобы ваши пользователи отображали пользовательский интерфейс плагина и информацию

• Крючки по всему приложению — Всякий раз, когда происходит «интересное» событие, система проверяет, подписаны ли какие-либо плагины в данный момент на это событие, и вызывает / уведомляет их, а затем отображает результат. Некоторые примеры событий, которые заслуживают Крюков, могут быть:

  • Визуализация заполнителя — это активирует все подписанные функции для отображения частичного представления внешнего интерфейса / внутреннего интерфейса.

  • Конкретные деловые мероприятия — например, Всякий раз, когда новая книга добавляется в каталог или продается

  • Администрирование меню рендеринга — В этом случае каждый установленный плагин выберет все пункты меню в таблице PLUGINNAME_AdminPluginMenu (плагин должен был создать эту таблицу во время установки) и вернет все их на экран для отображения.

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

---

Практическая сторона вещей (на основании второго обновления вопроса)

1. Использование HMVC для визуализации частичных представлений (виджетов) внутри существующих представлений

Как я уже говорил ранее, Kohana поддерживает HMVC или шаблон контроллера представления иерархической модели. Это означает, что вы можете иметь иерархию контроллеров, как это (уже описано в следующий вопрос):

Теперь это позволяет вам легко вызывать контроллеры с других контроллеров и даже прямо из ваших представлений! И это творит чудеса, когда нужно встраивать виджеты.

Вы можете внести небольшие изменения в boostrap.ini, чтобы включить такие маршруты, как widget_controller/controller_action/action_parameter (это подробно описано в уроке, который я вам дам ниже). Затем вы можете иметь следующий код внутри шаблона основного вида, где вы хотите отобразить вашу оранжевую книжную коробку:

<div class="widget_sidebar">
<?php echo Request::factory('widget_orangebook/display/3')->execute(); ?>
</div>

При выполнении это действует как ловушка и вызывает метод action_display контроллера widget_orangebook с параметром 3 — например, Вы хотите показать 3 книги.

Действие контроллера будет выглядеть примерно так:

public function action_display ($number_of_books){...}

В результате внутри <div>, вы увидите содержимое шаблона, установленного контроллером widget_orangebook после выполнения действия.

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

Ты можешь видеть этот урок чтобы увидеть подробное описание всех необходимых вам модификаций. Это немного интереснее — это рендеринг нескольких виджетов в разделе виджетов, но он следует той же логике.

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

2. Модули Кохана

Kohana поддерживает модули, которые позволяют упорядочивать ваши плагины. По мере реализации более сложных плагинов это станет важным. Ты можешь видеть больше о модулях Kohana здесь.