Ответ 1
Основываясь на вашем обновлении, я думаю, что вы описываете хороший пример для веб-приложения, которое должно стать модульным. Вы хотите иметь возможность легко добавлять новые модули (плагины), которые дают вам разные функциональные возможности без необходимости менять ядро приложения каждый раз.
Ниже приведено возможное решение вашей проблемы с концептуальной точки зрения. Мое намерение состоит в том, чтобы помочь вам понять идею и начать работу. Имейте в виду, что его можно упростить или стать более сложным, в зависимости от ваших потребностей.
Теоретическая сторона вещей
- Плагины/Модули
Каждый плагин будет включать набор конкретных функций и должен работать независимо от других плагинов, которые включены в данный момент. Все плагины должны будут соблюдать общий набор правил и соглашений, чтобы быть распознанными вашим приложением. Это упростит дальнейшее обслуживание и расширение. Например, каждый плагин должен:
-
Имеет свой собственный подкаталог в папке "Плагины/Модули", которая следует за предопределенной структурой (например, Backend/Portlets/InstallScripts и т.д.).
-
Используйте отдельную тестовую среду хранения в своей базе данных, предназначенную только для этого плагина. Возьмите Kashflow - все таблицы, которые используются плагином, могут начинаться с префикса ksflw_.
-
Принесите свои собственные частичные представления представления Frontend (вместе с базовой логикой контроллера и моделью), которые реализуют определенные наборы функциональных возможностей (например, отображать предварительно выбранные книги на оранжевой границе )
-
Принесите свои собственные частичные представления (-ы) представления Backend (-ов) (вместе с базовым контроллером и моделью), которые обрабатываются на бэкэнд сайта (в случае Kashflow у вас есть визуализация портлета, которая может отображать кнопка для ручного выполнения синхронизации, позволяет запланировать ее и отображать дату и время последней выполненной синхронизации)
-
Установщик script, который создает таблицы, вставляет элементы меню и инициализирует подписки на крючки (см. следующий маркер)
-
Инициализировать подписки на крючки. Все подписанные функции Plugin вызываются всякий раз, когда зарегистрированное событие происходит где-то в системе.
- Основные функциональные изменения
Для запуска плагинов вам понадобятся новые функции в вашем существующем приложении.
-
Менеджер плагинов - графический интерфейс, который позволяет устанавливать, удалять, включать/отключать плагины и разрешать доступ к ним для ваших клиентов.
-
Диспетчер частичных представлений - позволяет пользователям выбирать, какие частичные представления, какие плагины будут отображаться в существующих заполнителях (это будет работать в сочетании с крючками)
-
Заполнитель для частичных представлений на страницах в тех местах, где вы хотите, чтобы ваши пользователи отображали пользовательский интерфейс плагина и информацию
-
Крючки по всему приложению. Всякий раз, когда происходит "интересное" событие, система проверяет, подключены ли какие-либо плагины к этому событию и вызывает/уведомляет их, а затем отображает результат. Некоторые примеры событий, которые заслуживают "Крюки", могут быть:
-
Отказ от размещения - это приведет к тому, что все подписанные функции отображают частичный вид интерфейса /backend
-
Конкретные бизнес-события. Всякий раз, когда новая книга добавляется в каталог или продается
-
Отображение меню администрирования. В этом случае каждый установленный плагин выберет все пункты меню в таблице 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, но его выполнение выполняется на сервере без дополнительного вызова. Это довольно мощно, и я думаю, что это способ пойти на описанные вами случаи.
Вы можете увидеть этот учебник, чтобы увидеть подробное описание всех изменений, которые вам нужно сделать. Это немного причудливо - это об рендеринге нескольких виджетов в разделе виджета, но он следует той же логике.
Обратите внимание, что если вы настаиваете на использовании шаблонов усов и бездисковых, вы также можете выполнить этот вызов запроса в контроллере, установить результат в переменную, а затем передать эту переменную вашему шаблону усов.
2. Модули Kohana
Kohana поддерживает модули, которые позволяют организовывать организованные вами плагины. По мере внедрения более сложных плагинов это станет важным. Вы можете увидеть подробнее о Kohana Modules здесь.
