В структуру БД только что развернутого проекта после выполнения команды:
make pgsql_template
уже входит некоторое количество таблиц, пользоваться которыми (и до определенной степени модифицировать) можно и нужно. Эти таблицы отражают основные отношения, создаваемые между данными в любом приложении.
[options]. Дерево параметров проекта
Эту таблицу переопределять нельзя!
В данной таблице свернуты все данные из блока "Редактирование параметров сайта" в разделе Администрирование. Это, в первую очередь:
- Алиасы секций для быстрого доступа к их id
- Алиасы отдельных документов, также для быстрого доступа к их id
- Словарь произвольных глобальных параметров
Все перечисленные данные наполняются и управляются из системы администрирования; в программном коде они доступны через объект $project. Объект $project объявлен в Contenido::Globals, доступен в виде глобальной переменной и доступен в mason-компонентах и в pm-модулях при включении:
use Contenido::Globals;
Для доступа к данным используются методы s_alias, d_alias, params. В качестве мнемоники любая perl-строка.
[sections]. Дерево разделов (секций) проекта
Эту таблицу при необходимости можно дополнять. Невозможно создать кастомную таблицу секций, так как дерево секций в проекте – одно!
Дерево секций проекта – это основа структуры данных любого проекта на Contenido. Любой документ, если его необходимо видеть и редактировать в системе администрирования, должен иметь поле sections (по умолчанию intarray!) и фильтр по секции (_s_filter). Если документ не привязан ни к какой секции, найти его можно только по классу.
Данную таблицу описывает класс-дескриптор SQL::SectionTable, а обслуживает класс Contenido::Section и его производные, а также . Методы, применимые, к работе с секциями:
- $keeper->get_sections – выбор секции или группы секций
- $keeper->get_section_tree – получение дерева секций
В общем случае секции являются стандартным объектом, наследуются и подчиняются всем правилам, применимым к прото-классу Contenido::Object. И их применение не сводится к одной лишь раскладке документов в системе администрирования. На базе секций можно строить:
- Проектные меню
- Рубрикаторы
- Контейнеры для поиска объектов по группе свойств (на базе ряда хаков и переопределения фильтра _s_filter)
- Разделы в данной документации
- ...придумайте сами...
Вкратце – у вас есть дерево для описания произвольной структуры проекта, и вы вольны его использовать. Однако, не слишком разумно сильно раздувать структуру секций, так как наличие более чем 200 элементов в нем усложняет и навигацию по системе администрирования, и редактирование строковых идентификаторов (алиасов) и работу функции get_section_tree.
Структура полей таблицы секций:
- id – идентификатор секции. Секция с id=1 является корневой секцией проекта и входит в начальный шаблон БД проекта;
- pid – id родительской секции;
- class – класс секции. Система управления позволяет раскладывать секции различных классов по различным вкладкам, тем самым облегчая навигацию и повышая удобство пользования системой администрирования. Подробнее – в разделе "Профили проекта";
- ctime – дата/время создания секции. Заполняется автоматически при первом сохранении;
- mtime – дата/время моификации секции. Заполняется автоматически при каждом сохранении;
- sorder – поле со скрытой механикой заполнения, используемое для определения порядка секций в дереве;
- name – название раздела;
- alias – web-alias. Обычно используется для создания ЧПУ – человекопонятных url;
- status –стандартное поле статуса. Чаще всего используется для активации/деактивации секций, но может быть переопределено для хранения любых числовых статусов;
- data – meta-поле для хранения extra-полей
.
[documents]. Таблица произвольных документов
Таблицу documents можно произвольно дополнять и расширять, дополняя и расширяя соответствующий класс-дескриптор (SQL::DocumentTable). На базе дескриптора можно создавать произвольные таблицы (кастомные таблицы), наиболее приспособленные для работы с системой администрирования. Кроме того, с помощью дескриптора SQL::ProtoTable можно описывать вообще любые таблицы.
Таблица documents описывает произвольный документ, являющийся основой для конечной страницы сайта или лдя чего-нибудь еще. Например, новость, собрание контактных данных, профиль проекта и т.д.
Немного забегая вперед – для того, чтобы созданная таблица нормально опознавалась и без ругани в error-log работала с системой управления в ней необходимо и достаточно иметь три поля:
- id – идентификатор документа (по умолчанию сквозной для всех объектов в БД)
- class – класс документа.
- name – название
- sections – секция или группа секций, к которой привязан объект
Структура полей стандартного документа:
- id– идентификатор документа (по умолчанию сквозной для всех объектов в БД);
- class – класс документа;
- ctime – время создания;
- mtime – время модификации;
- dtime – время документа. В отличие от двух других полей модифицируется через форму редактирования;
- name – название
- status – статус
- sections – секция или группа секций, к которой привязан объект
- data – мета-поле для хранения extra-полей
Подробнее о создании и описании документов и кастомных таблиц читайте в соответствующем разделе документации.
[links]. Таблица связей
Таблицу links можно произвольно дополнять и расширять, дополняя и расширяя соответствующий класс-дескриптор (SQL::LinkTable). На базе дескриптора можно создавать произвольные таблицы (кастомные таблицы) связей, наиболее приспособленные для работы с системой администрирования.
Таблица хранит произвольный набор связей многие-ко-многим как между документами из одной таблицы, так и между документами из разных таблиц. Стандартный набор полей для таблицы связей:
- id– идентификатор документа (по умолчанию сквозной для всех объектов в БД)
- ctime – время создания
- mtime – время модификации
- source_id – id исходного объекта
- source_class – класс исходного объекта
- dest_id – id объекта-получателя
- dest_class – класс объекта-получателя
- status – статус
- sections – секция или группа секций, к которой привязан объект
- data – мета-поле для хранения extra-полей
Роли объект-источник / объект-получатель условны и зависят от логики приложения. Классы необходимы для идентификации таблиц, участвующих в join-операциях. Для работы с таблицей ссылок используются два метода:
- $keeper->get_links – для извлечения данных из самой таблицы ссылок
- $keeper->get_documents с параметрами lclass, ldest, lsource, lstatus – для извлечения документов join-ом с таблицей ссылок
A bit of information – класс документа в конечном счете однозначно связывается с таблицей, в которой хранится документ. Подробнее – в соответствующем разделе документации.
[users]. Таблица системных пользователей
Эту таблицу при необходимости можно дополнять.
Таблица является служебной и обслуживает только пользователей системы администрирования (системных пользователей). Для ведения учета пользователей сайта используйте плагин users или классы, построенные на базе данного плагина. Сущность системного пользователя – это объект класса Contenido::User; для доступа к объектам данного класса используются
- метод $keeper->_get_users – получающий одного пользователя или список пользователей в зависимости от переданных параметров
- глобальная переменная $user, описанная в Contenido::Globals, доступная для всех компонент системы администрирования, хранящая в себе объект текущего залогиненного пользователя.
.
