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

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

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

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

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

2. ктулху (04.01.2012 / 13:11)
Ну сделай например папочку с модулями.
там в файликах что-то типа
$permissons[]='forum_thread_add';

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

3. Артур (04.01.2012 / 13:17)
Как организовать инсталяцию модулей в таком случае? Модуль имеет собственный инсталятор, сам себя подготавливает, а ядро просто записывает его возможные операции в таблицу и засовывает в папку?

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

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

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

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

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

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

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

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

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

9. Артур (04.01.2012 / 14:07)
Модули друг о друге не знают. Они знают только то, что дает ядро. На пример есть группа модулей - форум - ядро установило конкретный форум в качестве основного этой группы, а другой модуль знает только что существует такая группа и что с ней можно обращаться так то через ядро. Модуль обращается к ядру, а ядро уже определяет кому передать этот запрос. Если форум установлен, запрос передается ему, иначе не передается никому

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

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

11. Артур (07.01.2012 / 21:51)
Центр управления доступом.
Собственно сам является ресурсом, так как может быть легко заменен на другую реализуцию этого модуля.
Отвечает за управление учетными записями, полномочиями, ролями, а так же аутентифицирует пользователя и информирует центральный контроллер о его правах. Очень удобным в этом модуле является то, что перед обращением к конкретному ресурсу, центральный контроллер спрашивает разрешение у центра управления доступом. Если для данного пользователя доступ к данной операции данного ресурса запрещен, центральный контроллер генерирует исключение.
Отдельной плюшкой здесь является то, что с помощью центра управления доступом можно запретить обращаться конкретному пользователю к конкретной функции ресурса, а к другой разрешить. Так, на пример, можно разрешить писать сообщения в гостевой только зарегистрированным пользователям, а удалять их только модераторам.
Плюсами этой структуры являются:
1) Заменяемость ресурсов без изменения кода
2) Расширение возможностей системы путем создания новых унифицированных интерфейсов классов ресурсов
3) Простая и гибкая политика безопасности
4) Независимость ресурса от центрального контроллера (достаточно реализовать контроллер ресурса)
5) Полная независимость представления от модели и обратно (полностью заменить как представление так и модели без изменения кода).
Как система реагирует на действия пользователей показано на этой модели http://upwap.ru/1944262
А теперь прошу снять с меня розовые очки и показать минусы. Громоздскость не в счет, ибо система вполне таки легкая, основным его элементом является центральный процессор, все остальное либо сторонние ресурсы (модули, бибилиотеки), либо визуализации.

12. Ant0ha (07.01.2012 / 22:25)
Брр.. А может проблема в постановке изначальной задачи? Что же ты такое пишешь чтоб изобретать такой велодвиг? Распространенные фреймворки не справляются?

13. Артур (07.01.2012 / 22:32)
Распространенные фреймворки реализуют асинхронный интерфейс генеря его в пхп (иногда даже жс там генерится), а я сторонник разделения. Другие фреймворки, на мой взгляд, требуют инсталляцию модулей в ручную, а хотелось бы автоматически. Третье требуют очень строгой структуры модуля. В общем то не нашел такого, который бы удовлетворял все потребности. Собственно реализовать такое ядро задача не очень сложная, вот и решил не запорачиваться на спаривании сторонних библиотек и их переписывании, а воспользоваться своим решением

Добавлено через 01:18 сек.
Пишу довольно не маленький проект, который будет меняться чуть ли ни от клиента к клиенту, потому нужна максимальная гибкость и повторение кода

14. Артур (07.01.2012 / 22:46)
Вообще реализация очень удобная. Можно заставить модули требовать для нормальной работы другие модули. На пример модуль чата может потребовать установки модуля управления доступом и учетными записями, чтобы можно было использовать анкеты и тому подобное, при чем сам модуль чата содержит только логику работы чата, а для работы с анкетами он использует сторонний модуль

15. Ant0ha (07.01.2012 / 23:06)
Это можно запросто реализовать в той же кохане. Добавляешь модуль управления модулями, в котором делаешь класс Modules и добавляешь ему метод is_installed(), соответственно делаешь учет установленных модулей в БД (это у меня в движке реализовано).
По твоему примеру, в инсталляторе модуля чата делаешь проверку зависимостей:

<?php

if ( ! Modules::is_installed($module))
{
    exit('Необходимо установить модуль '. $module);
}

Это всё, включая инсталляторы модулей, у меня реализовано в MC PRO, где используется один из распространенных фреймворков.

16. Артур (07.01.2012 / 23:10)
А как взаимодействие модуля с модулем и центр управления доступом? Моя реализация делает разграничение доступа прозрачным для любого модуля

Добавлено через 02:25 сек.
Я плохо знаком с коханой, но судя из твоего поста довольно много делать придется ) и так каждый раз?

17. Ant0ha (07.01.2012 / 23:15)
Модули могут работать с моделями и другими классами других модулей, без каких либо ограничений и разграничений, не вижу в ограничениях какого либо смысла.

Добавлено через 01:28 сек.
> но судя из твоего поста довольно много делать придется ) и так каждый раз?

а с системами контроля версиями ПО знаком?)

Добавлено через 03:11 сек.
Мне никогда не приходится писать что-либо повторно, благо существует git и грамотная система переопределения кода в кохана + MC.

18. Артур (07.01.2012 / 23:20)
Знаком. Кохана с система взаимодействует и подстраивается под изменения? ) врядли. Потому и ввел унифицированный интерфейс группы ресурсов

URL: https://visavi.net/topics/28047