Организация ядра и инсталятора

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

Добавлено через 02:18 сек.
Собственно организовать эту систему не сложно, она уже почти готова. Сложность в организации системы учета ресурсов. Система счета полномочий должна связывать учетную запись с возможными операциями над ресурсом (разрешенно создание тем на форуме, разрешенно редактирование сообщений форума и т.д.). Для этого нужно как то организовать механизм учета ресурсов и их интерфейсов. Чем то напоминает ось?!

Добавлено через 04:45 сек.
Так вот, нужен некий механизм, который будучи установленным в качестве ядра сайта, позволит инсталировать на сайт ресурсы (форум, чат и т.д.) и вести их учет. При этом система управления полномочиями тоже является (я так думаю) ресурсом, который позволяет связывать права с пользователями и обеспечивает закрытость некоторых ресурсов или даже операций ресурсов от конкретных пользователей

Добавлено через 07:49 сек.
И так функциональные требования таковы:
учет имеющихся ресурсов, инсталяция ресурсов, удаление ресурсов (управление ресурсами); учет операций, доступных каждому ресурсу (для форума это будет на пример создание тем или удаление сообщений). Понимаю что вопрос довольно объемный и сложный, а так же понимаю что простого ответа "на коленке" нет, потому, если кому интересно, готов поделиться разработками для совместного использования в будущем

Ну сделай например папочку с модулями.
там в файликах что-то типа
$permissons[]='forum_thread_add';

в итоге получим массив с всеми возможными действиями.
И табличку с правами, при установке "модуля" просто добавляем нужные поля (опять же берём из файлика).
Ну и в админке столбик чекбоксов, у меня примерно так сделано.
Хотя писал я это года 3 назад.

Как организовать инсталяцию модулей в таком случае? Модуль имеет собственный инсталятор, сам себя подготавливает, а ядро просто записывает его возможные операции в таблицу и засовывает в папку?

Добавлено через 07:31 сек.
И как организовать взаимодействие модулей? Предположим один модуль должен для своих коварных целей обратится к операций другого модуля, он обращается к ядру и запрашивает известные операций того модуля. После выбирает подходящий и запрашивает его через ядро. Напоминает контролер. Может организовать фабрику комманд и при вызове операций ресурса другим ресурсом через ядро, вызывать соответствующую комманду?

> Модуль имеет собственный инсталятор
достаточно в каждый модуль запихивать 3 файла
1) вызываемый при установке
2) при удалении
3) при обновлении.

> И как организовать взаимодействие модулей?
зависимости. т.е. если 1 модуль требует два других, то их ставить автоматом. Но тут уже необходим единый репозиторий с модулями.

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

Вот и я о том же. Зависимости можно организовать без автоматической установки, а просто с проверкой на наличие уже установленного необходимого ресурса (модуля). Сделать то можно, конечно не идеально, но хоть как то. По поводу установки я в той же части думаю

Добавлено через 01:09 сек.
По поводу зависимостей это проверка наличия необходимых модулей, а вопрос о том, как организовать вызов метода одного модуля из другого? Ведь модули ничего друг о друге не знают и общаются через ядро

Да как угодно можно сделать. В зависимости все от того что тебе нужно.
Вообще или мне кажется автор пытается ООП изобрести заново... Ибо то что в 5 посте хочется очень на полиморфизм смахивает. (Можно создать новый класс и переназначить ф-ции базового класса допустим).

Ну от полиморфизма я не отхожу. Я хочу использовать контролер для взаимодействия между модулями. Вот подходящая статья http://www.ruseller.com/lessons.php?rub=37&id=674 но там все в ручную ставится, а не хотелось бы

Не особо понял, как модули должны "знать друг о друге", но, как я понял, по сути модули могут принадлежать определённому пользователю. Верно? Так где-то в бд в таблице пользователя вписывать, включен определённый модули или нет, назвав колонку а-ля module_*. При создании какого-то нового модуля дописывать колонку. Потом проверять по ключу module, какие модули подключены.
Запутанно написал я, но должно быть понятно =)

Модули друг о друге не знают. Они знают только то, что дает ядро. На пример есть группа модулей - форум - ядро установило конкретный форум в качестве основного этой группы, а другой модуль знает только что существует такая группа и что с ней можно обращаться так то через ядро. Модуль обращается к ядру, а ядро уже определяет кому передать этот запрос. Если форум установлен, запрос передается ему, иначе не передается никому

Добавлено через 00:49 сек.
Как организовать разрезление прав доступа пользователей и модули я знаю, не решил еще как организовать хранение и установку самих модулей

Собственно решил остановиться на такой вот структуре:
http://upwap.ru/1944260
Опишу каждый элемент отдельно.
Предстваление и модель визуализации.
Представим что мы работаем с таблицей, которую можно сортировать, добавлять в нее записи и удалять их. Вся эта таблица хранится в модели визуализации, а представление лишь отвечает за ее отображение пользователю. При этом ни представление, ни модель визуализации друг о друге не знают, а взаимодействуют на уровне событий, генерируемых пользователем.
Плюсы этого подхода:
1) Можно без проблем заменить одно представление другим, достаточно лишь изменить событийные связи (а иногда и без этого можно обойтись). На пример смена дизайна сайта или метода отображения таблицы.
2) Данные могут быть обработаны без обращения к серверу. Так, сортировка таблицы не требует обращения к серверу, потому что это может быть выполнено самим JS в модели представления.
3) Модель представления так же может быть легко заменена на другую.
4) Визуализаций для одной модели представления может быть множество, на пример представление таблицы в форме таблицы и одновременно диаграммы.
Ресурс.
Модуль выполняющий определенные задачи в системе. На пример полноценный модуль гостевой книги, который может взаимодейтсвовать с БД используя собственные классы или сторонние бибилиотеки. Единственно требование для ресурсов, это то, что для него должен быть реализован контроллер ресурса. То есть класс, который реализует интерфейс класса ресурсов (о классе ресурсов расскажу дальше) и управляет всем ресурсом по средствам обращения к этому интерфейсу.
Важно понимать, что ресурсами могут быть только такие модули, которые не генерируют страницу по средствам echo, а используют более кашерные методы (речь как ни как идет о асинхронном взаимодействии с сервером). Если любой написанный вами модуль имеет контроллер (не сложно дописать) и не генерирует страницы, то его можно использовать в моей структуре.
Центральный контроллер и унифицированный интерфейс класса ресурсов.
Центральный контроллер принимает команды от визуальной модели и направляет их соответствующему контроллеру ресурсов. Для решения этой задачи он должен знать:
1) Какой интерфейс имеет контроллер ресурса
2) Где находится контроллер ресурса
Для решения первой задачи и используется унифицированный интерфейс класса ресурсов. На пример класс ресурсов "Гостевая книга" это все возможные гостевые книги. Этот интерфейс содержит основные опреации, такие как добавление сообщения, удаление онного и его редактирование.
Для простой замены одного ресурса другим (одна гостевая книга заменяется другой) необходимо чтобы их контроллеры реализовывали интерфейс класса ресурсов "Гостевая книга" (ведь центральный контроллер не должен зависить от конкретной реализации гостевой книги).