Создаем таблицы страниц, контроллеров и связей

В центральной таблице системы — rs_map, будут храниться все страницы наших сайтов. У данной таблицы будут следующие поля:

• map_id — это поле будет содержать уникальный id страницы. Поле является автоинкрементным
• map_parent — указание на родителя страницы. Это поле является внешнем ключом на поле map_id. Тем самым мы получаем древовидную структуру хранение страниц.
• map_alias — псевдоним страницы. Участвует в реализации ЧПУ на сайтах
• map_name — имя страницы.
• map_view — шаблон который участвует в формировании вида этой страницы
• map_system — системная ли страница. Страницы бывают системными (порожденные разработчиком) или не системными (порожденными модулем). Разницы между ними никакой. Необходимо разделение лишь для то-го что бы разработчику не удалось удалить страницы через редактор разработчика (такое удаление может порождать очень много мусора в базе данных) Сейчас рано пока забивать голову этой информацией, так как редактора пока никакого нет.
• map_type — динамическая страница или же статичная. Про типы страниц мы уже говорили.

Не маловажная таблиц содержащая имена контроллеров — rs_controller. Содержит всего два поля:

• controller_id — автоинкрементное поле
• controller_name — имя контроллера. Это поле самое важное в этой таблице. Имена контроллеров должны строится по заведомо обговоренной схеме и будут являться путем до этого самого контроллера в файловой системе. Например имя pub.test.intro говорит нам о том, что контроллер лежит вот по такому пути: /project/pub/test/controller/intro.class.php. Почему первая папка project а не rs-mini? Элементарно, в папке rs-mini нет и не должно быть папки pub

Ну и таблица, без которой две другие просто справочники и не более. Назвал я ее rs_connect. С помощью этой таблицы, RS-MINI сможет определить какие именно контроллеры и в каком порядке подключать на той или иной странице.

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

• верхний блок
• центральный
• и нижний

Вы кстати могли это видеть в RS-SITE 1.x.x. Смысл этих блоков как раз в очереди запуска. То есть с начало будут запущены контроллеры верхнего блока, после центрального а под конец нижнего. По задумке, все проверяющие права контроллеры должны подключаться в верхний блок. Все контроллеры отвечающие за вывод и обработку каких либо данных, должны подключаться к центральному блоку. А контроллеры которые не особо важны, но все же нужны (например контроллер модуля метатегов), должны подключаться в последнею очередь.

Так же у каждого блока будет реализована сортировка. То есть можно будет регулировать очередь запуска контроллеров внутри блоков.

В состав этой таблицы вошли вот такие поля:

• connect_id — автоинкрементное поле
• map_id — внешний ключ на таблицу rs_map
• connect_value — поле для хранения параметров контроллера. Параметры нужны для регулировки поведения контроллеров. Например у контроллера который выводит список постов на блоге есть параметр кол-во выводимых заметок на странице (на моем блоге например по 5 постов на странице). То есть регулируя этот параметр можно вывести на одной странице 5 постов из (например) 100, получив при этом 20 страниц. Или вывести 50 постов на странице, получив при этом только две странички.
• controller_id — внешний ключ на таблицу rs_controller.
• connect_block — как раз те самые блоки про которые я говорил чуть выше.
• connect_inherit — это поле хранит указание наследовать ли контроллер для внутри вложенных страниц сайта или нет. Например если у нас есть контроллер проверяющий доступ к сайту, то будет очень грустно подключать его на каждой странице, ведь определять права нужно везде где бы пользователь не находился. С возможностью наследовать контроллеры, будет достаточно подключить его на главной, и указать что этот контроллер необходимо наследовать на внутри вложенные страницы, тем самым обеспечить работу алгоритма определения доступа по всему сайту.
• connect_position — поле определяет порядок вызова внутри блоков. Про эту возможность я тоже уже говорил чуть выше.

Заключение

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

Если будут какие-либо вопросы, то пишите постараюсь на них ответить

Всего Вам наилучшего, на сегодня все!