#php #frameworks #module
#php #фреймворки #модуль
Вопрос:
Я ищу способы внедрения модульной системы в мой фреймворк приложения, модули были бы файлами классов, которые каким-то образом изменяют дизайн, чтобы они автоматически интегрировались при вмешательстве пользователя.
Мой фреймворк — это пользовательский фреймворк, но он очень похож на codeigniter, только немного легче.
Идея, которая у меня есть, находится в файлах шаблонов, заключается в том, чтобы вызывать позиции модулей и автоматически загружать и анализировать модули
<html>
<head>
<title>Welcome to my site</title>
</head>
<body>
<header>
....
<?php $this->call_modules('header') ?>;
</header>
<section>
<aside>
<?php $this->call_modules('sidebar') ?>;
</aside>
</section>
</body>
</html>
Чтобы вызывались следующие модули и содержимое помещалось туда:
/system/applications/admin/modules/header/a.php
/system/applications/admin/modules/header/b.php
/system/applications/admin/modules/sidebar/a.php
/system/applications/admin/modules/sidebar/b.php
Так что мне кажется, что это будет работать нормально, но проблема в том, что я никогда раньше не создавал модульную систему, и я чувствую, что они больше классифицируются как хуки.
В моей голове я в основном хочу простую систему, состоящую из 1 файла класса и шаблонов, если требуется, файл calss, вероятно, будет выглядеть следующим образом:
class Module_HelloWorld extends Module
{
public static function info()
{
return array(
'name' => 'Hello Word',
'version' => '1.0.0',
'description' => 'Dispalys "hello World"',
'author' => 'Robert Pitt',
);
}
public function execute($context,$action)
{
//$context would be the current view at the point of execution for the view
//$action would be header / sidebar
}
}
Итак, мой вопрос в двух словах, каков был бы наилучший способ спроектировать модульную систему для моего фреймворка, позволяющий удалять сторонние модули в каталоге, а затем устанавливать от администратора, без особого вмешательства пользователя?
Ответ №1:
удачи с вашим mvc и cms. Я реализовал то же самое, думаю, некоторое время назад, мой подход был простым, первый, который пришел мне в голову.
- Основывайте свою систему на страницах и модулях (виджетах).
- Информация о страницах сохраняется в таблице базы данных с надписью «страницы».
- Модуль (виджеты) — это класс, содержащий метаданные (определение) и бизнес-логику.
- Если вы добавляете модуль на страницу, его конкретная информация сохраняется в базе данных.
- В следующий раз, если вы захотите иметь его экземпляр, просто передайте соответствующие параметры его классу, и он у вас есть.
- Таким образом, вы можете использовать одно определение модуля в разных местах и для разных экземпляров.
- Вы можете добавить столько страниц в базу данных.
- Пользователь может добавлять любое количество виджетов на одной странице.
Комментарии:
1. Спасибо за ваш ответ, я посмотрю, что смогу придумать позже, хотя хранилище базы данных — это не тот путь, по которому я хочу пойти.
2. @RobertPitt, это может сработать для вашего сценария, имеющего однозначное соответствие между классом и модулем, но у меня сработала база данных.
Ответ №2:
Я не уверен, что это помогло бы, но для меня я хотел фреймворк, который я мог бы расширить функциональностью с точки зрения модулей, когда это необходимо, но с минимальным количеством взаимодействия с базой данных с точки зрения хранения информации о модуле. Итак, у меня есть настройка, в которой у меня есть модули в папках с файлами настроек, css, js и самим классом, которые должны соответствовать очень специфическим соглашениям об именовании. При добавлении модуля мне нужно добавить папку, а затем обновить список модулей в базовых настройках фреймворка.
Один из параметров определяет, для какой страницы (ов) необходимо загрузить модуль. Если модуль требуется на каждой странице, тогда это a (*). Мой базовый контроллер фреймворка проверяет список модулей, а затем проверяет настройки страницы для модуля, чтобы увидеть, следует ли его загружать.
Мой фреймворк отображает страницу, загружая шаблон в выходной буфер и сохраняя в общедоступном var, к которому затем может быть доступен любой код во всем фреймворке. Итак, тогда я могу просто использовать str_replace для определения разделов, которые нуждаются в загрузке (например, в шаблоне есть тег интерфейса, который обозначает основное содержимое страницы), а затем заменить на содержимое модуля. Итак, модуль gallery заменил бы тег интерфейса на gallery на странице gallery, тогда как модуль article создал бы статью по тегу интерфейса на странице articles.
Хотя я этого не делаю, я думаю, что большинство людей используют теги smarty для замены.
Я думаю, это прекрасно работает, когда вам нужен фреймворк, который вы используете лично для доставки сайтов клиентам. Вероятно, это не сработало бы так хорошо, если бы разные люди должны были иметь возможность использовать ваш фреймворк.