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

Нынешние системы управления содержимым сайта (CMS) придерживаются модульной архитектуры, что позволяет в какой-то мере достичь гибкости. К сожалению, этой гибкости недостаточно, чтобы легко изменять структуру содержимого сайта: даже незначительные изменения решаются либо поиском другого модуля, либо созданием нового. Причина в том, что в таких системах модули определяют структуру содержимого (например, модуль новостей, фотографий, комментариев и др.) и часто содержимое разных модулей очень сложно объединить и построить осмысленную связь между ними. Например, чего только стоит возможность размещать фотографии из фотогалереи в новостях! А если речь пойдёт о более специфических возможностях? Из-за применения не гибких технологий приходится с опасением выслушивать желания заказчиков сайтов, и заказчик бывает в недоумении, что на его сайте нельзя просто сделать то, что для него кажется вполне естественным.

В своё время прыжок к гибкости совершила система под названием Drupal. В Drupal единица содержимого представляет собой узел (node): и статья, и новость, и фотография, и всё остальное являются узлами, благодаря чему стало возможным объединение разного по типу содержимого в одну структуру. Более того, категоризация, называемая таксономией (taxonomy), позволила структурировать содержимое по смыслу. В системе Drupal структура сайта уже не определяется исключительно модулями, её стало легче изменять по своему усмотрению. Но трудности остаются, так как довольно сложно, оперируя одной категоризацией, конструировать сложно структурированные сайты. Нет желаемой свободы для воплощения всех идей. Творчески настроенный разработчик оказывается вынужденным создавать собственный модуль или вмешиваться в программный код найденных модулей частично соответствующих требованиям.

Сложные не шаблонные сайты сейчас создаются с нуля с программированием системы управления непосредственно для них. В этом помогают каркасные системы – framework’и, их сейчас предостаточно, но будет ли готовый сайт обеспечен гибкостью? Framework – отличное решение для программиста ускоряющее создание сайта с задуманным функционалом, но framework ничего не дает конечному пользователю и самое главное администратору сайта. Вряд ли программист будет закладывать функционал в сайт для быстрого и гибкого изменения структуры сайта без программирования, т.е. в разделе администрирования, ведь это требует немалые временные и финансовые затраты. Допустим, сайт сделан и работает, но со временем владельцу понадобилось добавить новые свойства у группы товаров в каталоге, естественно, чтобы и поиск по ним работал и любые другие функции реализованные для каталога. Здесь без программиста не обойтись.

Разрабатываемая система Boolive как раз ориентирована на гибкость управления содержимым сайта. Именно эта гибкость позволяет без труда добавлять новые свойства к желаемым товарам в каталоге, без программирования и изнурительного поиска модулей создавать сайт любой структуры – это могут быть и обычные ленты новостей, блоги, фотогалереи, а также форумы, каталоги, сообщества и даже самые оригинальные проекты.

Содержимое первостепенно!

В центре всего – содержимое. Единицей содержимого является объект, множество объектов с однотипными свойствами образуют класс, точнее наоборот, классом определяются объекты с конкретными свойствами. Понятия объекта и класса должны быть знакомы не только программистам, а каждому разумному человеку, потому что мы воспринимаем окружающий мир объектным, в наших умах выстраивается объектная модель огромного мира. Подобно тому, как мы организуем информацию в своих умах, должно быть организовано в системе управления содержимым, именно так будет достигнута супер гибкость. Здесь не нужно касаться вопросов искусственного интеллекта.

Система Boolive отличается отнюдь не тем, что применяет объектно-ориентированные технологии, главная особенность в том, что для создания классов данных и их объектов не нужно ничего программировать! Логика системы организует и управляет данными, моделируя их объектный смысл. Добавление новости на сайте – это создание нового объекта класса «новость». И в любой момент, пользователь, наделенный соответствующими правами, может изменить класс «новость», добавив например новое свойство. Создание сайта превращается в создание нужных классов, выстраивания между ними связей, при этом системой поддерживается все важные понятия объектных технологий: наследование классов, разновидность отношений между объектами, полиморфизм и другое, но с доступным для непосвященного в программирование смыслом. И всё доступно посредством веб интерфейса. Создание класса – это всего лишь определение свойств, которые будут у объектов данного класса, никакой логики программировать не надо. Важной особенностью является гибкость и легкость изменения уже созданных объектов и классов без программирования.

Данные (содержимое) управляется централизовано. Чтобы на сайте создать каталог или ленту новостей не нужно устанавливать соответствующие модули в систему. Нужно просто создать требуемые классы «каталог» и «лента новостей». А смысл наделяется уже от того, как данные будут использованы. Новость, комментарий, фотография, категория, раздел, пользователь, группа и многое другое является объектами. От того что всё управляется централизовано, как по законам вселенной, можно с легкостью установить отношение между новостью и фотографией, поместить новость в форум и она одновременно станет темой форума. Любые действия с группировкой пользователей, организации комментариев (лентой, иерархией или совсем оригинально), структуризацией фотогалереи и использования фотографий из фотогалереи для связывания с другими объектами. Полная свобода для творчества.

Разграничение доступа

Другой особенностью является разграничение доступа к данным. И тут тоже невероятная гибкость! Существующие системы в основном используют принцип «пользователь» → «группа» → «список разрешенных действий». В системе Boolive всё иначе. С данными можно выполнять всего четыре простых действия: создание, изменение, чтение и удаление. Условие выполнения действия – это любое логическое выражение, это может быть комбинацией условий, например, проверка текущего пользователя и его статуса, можно сделать условие на текущее время, чтобы фото «для взрослых» показывать только ночью, например. Смысл в том, что условие не привязано к пользователям или их группам. Условие – это проверка состояния системы, а состояние системы это вся модель данных, к примеру, доступ к статье (чтение) для незарегистрированных пользователей можно сделать, если у статьи положительный рейтинг.

От того, что всё является объектами, а действия выполняются над объектами, разграничение можно определить на любой объект: хоть на раздел форума, хоть на конкретную тему, хоть на заголовок темы. К теме форума, например, прикрепляются файлы, можно свободно разграничить доступ ко всем файлам, а можно непосредственно к файлу выбранной темы. Соблюдается также иерархическая зависимость между данными. Если нельзя «читать» форум, то не будет доступа и к его темам и прикрепленным к ним файлам, даже при наличии связей с темой от других объектов системы.

Выборка содержимого

Имея гибкие возможности по созданию данных любой структуры, любой сложности, возникает вопрос, как же реализовать ещё и поиск по ним такой же гибкий и универсальный? А это уже сделано! В системе реализован механизм, что даже не требуется знать, как именно данные храниться в базе данных, главное иметь представление о самих данных. Все данные системы, всё содержимое взаимосвязано и называется моделью данных – это как примитивная «матрица» (из фильма Матрица). Мы можем получить любой объект из модели данных. Объект можно получить по его идентификатору, но чаще всего, как и в реальной действительности, мы опираемся на относительные параметры, например «найти первую фотографию из галереи Природа». Примерно с таким же смыслом строятся запросы на получение нужных объектов из модели данных. Сейчас запросы строятся на программном уровне, когда будет разработана административная часть, запросы можно будет формировать с помощью удобного веб интерфейса. Запросы или по другому «выборки» являются важнейшим соединительным звеном между данными и их отображением.

Отображение содержимого

Под отображением данных подразумевается передача их пользователю в одном из форматов, обычно это HTML. Применение объектной модели данных накладывает свою гибкость и на способ шаблонизации (формирование html). Для того чтобы объект был отображен в html формате, нужные значения его свойств вставляются в html шаблон. Здесь немного углубляюсь в детали реализации шаблонизации, так как простыми словами вряд ли можно объяснить суть гибкости формирования html.

Для каждого объекта имеется шаблон, но это не значит, что количество шаблонов равно количеству объектов. Поиск шаблона для объекта выполняется в два этапа, сначала проверяется наличие шаблона непосредственно для отображаемого объект (точное соответствие), если нет, то уже ищется шаблон по классу отображаемого объекта, т.е. шаблон для новостей будет использоваться каждой новостью, не имеющей собственный шаблон. Но здесь ещё учитывается наследование классов! Если не будет найден шаблон для новостей, то будет искаться шаблон по классу «материал» (если новость наследует материал). Как и в языках программирования в объектной модели системы Boolive имеется корневой класс, его имя «сущность». Если и для класса «материал» не будет найден шаблон, то уже точно будет использован шаблон класса «сущность», которым отобразится объект в самом простом виде. Без труда можно сделать новостную ленту, где каждая новость будет отображаться оригинальным образом, либо за минимум действий сделать общее отображение всех объектов. Так отображаются не только объекты новостей, статей, комментариев – любой объект даже не связанный с наполнением сайта может быть отображен.

В системе есть специальный класс «Раздел», из объектов которых формируется базовая структура сайта и разметка страниц. Например, имеются объекты этого класса, образно назовем их: «корень», «публичный», «управление». Когда запускается создание страницы по запросу от пользователя – делается выборка объекта «корень» и начинается его отображение, а в логике его шаблона из учета свойств этого объекта и в зависимости от URL делается выборка объекта «публичный», либо «управление» и производится его отображение. А там далее уже будет выборка меню, непосредственно материала, блоков и всего прочего соответствующего запросу. Шаблон объекта «корень» – это html с пустым тегом body, внутрь body уже вставляется html код от объекта «публичный» или «управление». Далее, в шаблонах «публичный» или «управление» определяется разметка (схема) страницы, т.е. где будет меню, шапка, футер и другое. Вы, наверно, догадались, что «публичный» – это сам сайт, а «управление» – это раздел администрирования. Можно создавать любое количество разделов и подразделов, если требуется, то можно сделать несколько разных по функционалу разделов администрирования – для программистов, менеджеров, секретарш.

Вспомните про разграничение доступа. Достаточно определить условие на «чтение» объекту «управление», чтобы разграничить доступ к административному разделу и это можно проделать с любым разделом, подразделом, блоком и т.п.

Вдаваться в подробности, как происходит определение, при каком URL что отображать, сейчас не буду – в общем, это те же процессы создания, изменения, удаления объектов, только с особым интерфейсом для удобства выстраивания всей структуры сайта. Вот она гибкость от централизации содержимого – через изменение содержимого, изменяется любой компонент системы!

Данные свободно могут быть представлены в любом формате, для этого используются соответствующие модули.

Заключение

Всё тип-топ Цель статьи – в общих чертах показать, чем же отличается система Boolive от тысячи других и каким же образом достигается супер гибкость.

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

Для пилотной версии с минимумом красивых штучек в функционале, остается сделать интерфейс администрирования, чем сейчас занимаюсь, ну и некоторые другие функции. Работа сложная, расходуется уйма калорий…

И ещё: оцените текущий дизайн раздела администрирования: http://boolive.ru/files/admin/ (не для IE6 и хуже!)