Нора тигра [6]
[начало]
Так было и так будет: всякое сложное начинается с простого, так же как и всякое
незначительное становится, в конце концов, важным и значительным. "Кодекс самурая" |
Что касается виртуализации, то для CMS это не роскошь, а осознанная необходимость.
Поскольку контент-база для движка одна, а задач на CMS возлагается несколько,
часто противоречащих друг другу (по отношению к наиболее удобной структуре),
то оптимальным выходом из такой ситуации будет виртуализация контент-базы и
отделение физической структуры от ее логического представления. К примеру, если
от пользователя нужно скрыть детали организации контент-базы, то для администратора
CMS, наоборот, раскрыть. Но при этом администратору удобнее работать не с физической
структурой, а с логической, хотя CMS, со своей стороны, выполняет запросы над
физической структурой.
Стоп! Теперь еще раз и помедленней... Для начала примем, что для каждой задачи
мы используем собственную структуру контент-базы и способы ее абстракции. А
поскольку мы проектируем CMS для вполне конкретного сайта, а не универсальный
движок для абстрактного сайта, то можем позволить себе ассиметричную схему CMS.
В некоторых CMS, правда, идут по противоположному принципу - делают упор на
"универсальный скрипт", где все функции находятся "в одном флаконе",
а реализация различных задач состоит в урезании прав. Если администратор получает
доступ до всех функций, то обычный пользователь CMS лишен некоторых администраторских
функций, но при этом может работать с контент-базой (посетитель сайта получает
права "read only"). Дескать, нам это еще Оккам завещал - не плодить
лишних скриптов. Гибкость системы при этом, правда, нулевая.
Ассиметричность уровней абстракции гарантирует, что каждый
работает с нужным ему уровнем удобств, возможностей контроля над CMS и схемой
взаимодействия с движком (визуальная и исполняющая система).
Ассиметричностью, к примеру, обладает такая схема построения
движка:
Небольшое замечание
Надо сказать, что я пишу не учебный и не практический
курс по строительству CMS, а рассказываю философию CMS изнутри самой CMS, стараюсь
показать разные подходы к проектированию. Все примеры - "учебные",
и не стоит воспринимать их как руководство к действию.
BackOffice - это не только пульт управления CMS, но и основной инструмент работы с контентом. Какие же требования выдвигаются к "заднему офису"?