СИСТЕМЫ CONTENT MANAGEMENT НОВОГО ПОКОЛЕНИЯ

СИСТЕМЫ CONTENT MANAGEMENT НОВОГО ПОКОЛЕНИЯ

Системы Content Management (CM) появились вместе с большими информационными Internet-ресурсами. Именно тогда возникла острая необходимость простого и удобного управления информационным наполнением сайтов, а также обеспечения их навигационной целостности. Первые CM-системы как правило работали по принципу «раздел-статья», при котором навигационное дерево строилось из объектов двух типов – «разделов», представляющих собой набор атрибутов для формирования на основе HTML-темплейта веб-страницы и одновременно могущие быть подобием директорий (Folder-ов) для других «разделов» и «статей», отличающихся от «разделов» лишь тем, что от них невозможно дальнейшее ответвление дерева. При этом темплейт для «раздела» и «статьи» чаще всего был одинаковым. Как выяснилось со временем, такой подход к архитектуре БД не давал достаточной гибкости. Во-первых, ограничением количества темплейтов он загонял в очень жесткие рамки дизайн (многие сайты того времени были очень похожи друг на друга не по причине скудности дизайнерской мысли, а по причине несовершенности программных продуктов). Во-вторых, – препятствовал развитию сайта (если со временем «статья» перерастала в «раздел», приходилось создавать новый объект, удалять старый и отслеживать битые ссылки на страницу, поскольку автоматически менялся ее URL).

Также отличительной особенностью первых CM-систем было хранение всех сопутствующих файлов в общей куче, без привязки к статьям или разделам, а также без присвоения уникальных имен. Таким образом, отслеживание уникальности было целиком и полностью на совести администратора. Не сложно догадаться, что это, во- первых, создавало проблемы при добавлении новых элементов, а во-вторых, не позволяло отслеживать актуальность того или иного файла. Кроме того, для первых CM-систем была характерна генерация страниц «влет», то есть в момент загрузки пользователем. Это негативно отражалось на быстродействии сервера. Страницы сайта, использующего такие CM-системы, имели динамический URL, представляющий собой открытый запрос с указанием скрипта-обработчика и идентификатора объекта. При создании нового поколения CM-систем требовалось учесть все недостатки предшественников. Таким образом вырисовался список требований:

􀂃 Возможность использования неограниченного количества темплейтов

􀂃 Возможность ветвления навигационного дерева в любой точке

􀂃 Необходимость привязки сопутствующих файлов к страницам

􀂃 Автоматическое обеспечение уникальности имен сопутствующих файлов

􀂃 Необходимость облегчить нагрузку на сервер при отображении страницы

􀂃 Использование традиционного вида для URL (не динамический)

Базируясь на этих требованиях можно предложить много решений. В качестве примера приведем одно. Соответствующие требования реализованы в нем следующим образом:

􀂃 Все сопутствующие файлы размещаются в одной, либо нескольких (в зависимости от типа файла) директориях. Уникальность имени обеспечивается насильственным переименованием всех файлов. Новые имена файлам выдаются по какому-либо принципу, не допускающему повторений, например численные названия, каждый новый файл имеет название «на единицу большее предыдущего».

􀂃 Уменьшить серверную нагрузку можно, сняв задачу генерации страницы «влет». Для этого файлы должны лежать на сервере уже «собранными», то есть имеющими расширение .html. Это, кстати, автоматически решает проблему традиционного вида URL. Чтобы удовлетворить этому требованию, администраторское приложение должно после внесения любых изменений производить операцию сшивки всех страниц, которые изменения затрагивают, а также последующую выкладку получившихся страниц в виде HTML-файлов в соответствующую директорию на сервере.

Литература

1. Михаил Евдокимов. Динамический Web-сайт КомпьютерПресс, №6, 2001.

2. Леонид Черняк. Порталы и динамические циклы, Открытые системы, №2,

2003