Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Профессиональное создание сайтов с помощью CMS SiteEdit" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
| ← Апрель 2006 → | ||||||
|
1
|
2
|
|||||
|---|---|---|---|---|---|---|
|
4
|
5
|
6
|
7
|
9
|
||
|
11
|
12
|
13
|
15
|
16
|
||
|
18
|
19
|
20
|
21
|
22
|
23
|
|
|
25
|
26
|
27
|
28
|
29
|
30
|
|
Статистика
0 за неделю
Принципы создания движка сайта (CMS) // Структура операционной системы сайтов // выпуск 3
Структура операционной системы сайтов // выпуск 3В текущем выпуске: продолжаем тему про структуру операционной системы сайтов (ОСС). Немного замечаний по выпуску. В выпуске будет использоваться понятие CMF (content manager framework). Чем оно отличается от CMS (content manager system) я точно не знаю. Получается что CMF это конструктор CMS, а CMS конструктор сайтов. Пусть подправят меня, кто знает это лучше. И еще, предполагается, что читатель знаком с понятиями XML и XSL. Письма приходят все интересней и интересней. И даже полезные. Начну с самого полезного письма: Здравствуйте, khusamov. Честно скажу, не ожидал я подобного письма. Но оно меня очень порадовало. Действительно, излагаю свои мысли пока не так хорошо, как хотелось бы. Буду исправляться. Я подготовил несколько небольших плакатов, иллюстрирующие основные идеи моей ОСС. Также будут и примеры, ибо уже давно понял, что сухая теория не сразу понятна. Общая схема веб-сервераПеред началом договоримся об упрощениях. Под веб-запросом и веб-ответом я буду подразумевать, соответственно, http-запрос и html-страницу. То есть, обычный http-запрос любым броузером, в ответ на который сервер выдает html-страницу. Данные сайта могут хранится в разных по структуре хранилищах. В своем повествовании буду упоминать только о файловой системе ОС сервера и базы данных. Начну с представления операционной системы сайта (ОСС) в структуре обыкновенного веб-сервера. На рисунке 3.1 представлена схема такого сервера, на котором установлена пока гипотетическая ОСС. Схема показывает соподчиненность программного обеспечения и процесс обработки веб-запроса.
Данная схема проста и наверняка знакома многим. Но, с ее помощью я хочу показать одну из идей построения ОСС. Так как ОСС это скорей всего CMF, то сразу хочу уточнить что такое CMF в данном случае. Подразумевается, что ядро ОСС состоит из множества компонентов. И не все компоненты нужны для решения определенной задачи. Так вот, совокупность всех возможных компонент дает CMF, а набор компонент для решения конкретной задачи дает нам CMS. В этом случае, ОСС это ядро (или CMS) и установленные в него приложения. Ядро обрабатывает веб-запрос, вызывая нужные приложения и доставая разные данные из доступных хранилищ (в данном случае файлы и базы данных). Итак, в чем собственно первая идея заключается? А в том, что можно выпускать разные версии ядра ОСС. Под разные специализированные задачи. Первая задача состоит в создании универсального ядра, в котором уникальность будут давать специализированные приложения. Далее буду вести повествование исходя, что ядро будет именно универсальным. Структура ОССРассмотрим ОСС покрупнее. Будем считать, что в ядро ОСС входят все компоненты, кроме приложений. Кроме того, есть обязательные компоненты. Считается, что компоненты зарегистрированы и всегда доступны другим компонентами и приложениям. В качестве регистратора компонент выступает специальный компонент именуемый Диспетчер компонент. На рисунке 3.2 представлен процесс обработки веб-запроса обязательными компонентами.
Ключевым здесь является компонент обработки запроса. Он выбирается диспетчером компонентов в зависимости от веб-запроса. Получается, что разные ядра ОСС будут отличаться разным набором компонентов обработки запросов. В универсальном ядре таких компонент будет как минимум два: сайт и консоль управления. О них чуть позже. На рисунке 3.2 представлены не все обязательные компоненты (в частности нет таких компонент как Журнал событий, Права доступа, Почта и пр.). О других компонентах я расскажу в последующих выпусках. Также расскажу зачем они нужны. Например, не всем будет сразу понятно зачем нужен компонент Почта. Такого компонента в существующих движках сайтов вообще не существует. Диспетчер компонент имеет список всех установленных в систему компонент и соответствующие им строки с регулярными выражениями, определяющими множество веб-запросов, при которых эти компоненты будут запущены. Приведу пример такого списка для нашего универсального ядра: <components> <component id="site"> <title>Универсальный компонент обработки запросов</title> <file src="/components/site.p" class="componentSite"/> </component> <component id="console"> <title>Консоль управления ОСС</title> <file src="/components/console.p" class="componentConsole"/> </component> </components> <startupComponents default="site"> <component pattern="/console/.*" select="console"/> </startupComponents> В элементе components представлены установленные в систему компоненты. Сейчас там описаны компоненты Сайт и Консоль управления ОСС. В элементе startupComponents представлен список запуска компонент в зависимости от запроса. В аттрибуте startupComponents/@default установлен id компонента по-умолчанию, на случай если запрос не будет соответствовать ни одному шаблону (@pattern). Кстати, обо всех компонентах подробно будет в последующих выпусках. Сейчас только общее описание. Задача диспетчера приложений проста. На входе подается номер (id) приложения, его режим и параметры, на выходе снимаются результаты выполнения этого приложения. Приложение это программный код, который имеет несколько стандартных и пользовательских режимов выполнения с разными параметрами на входе. Диспетчер приложений также обеспечивает инсталяцию, деинсталяцию и настройку приложений. Это возможно через API (программный интерфейс) самого диспетчера. А для пользователя это производится через консоль управления или через контрольную панель управления. Остальные, представленные на схеме, компоненты рассматривать сейчас не будем. Интуитивно понятно что они делают. А более подробно я все равно буду излагать в следующих выпусках. Универсальный компонент обработки запросов «Сайт»Рассмотрим покрупнее один из компонентов обработки запросов, а именно Сайт. На рисунке 3.3 представлен процесс обработки веб-запроса этим компонентом.
Здесь ключевым является субкомпонент Навигация (рисунок 3.4). Этот компонент в своих конфигурационных файлах хранит для каждого сайта большую таблицу со структурой сайта (в виде нескольких деревьев навигации) и списком разделов. Мы вплотную подошли к таким понятиям как Сайт, Навигация, Дерево навигации и Раздел сайта. Поясню что я понимаю под этими терминами.
Сайт в рамках ОСС это совокупность доменного имени и различных конфигурационных файлов, соответствующих этому имени. В частности, к этим файлам относится таблица со структурой сайта и списком разделов. То есть субкомпонент Навигация загружает конфигурационные файлы для сайта, соответсвующего доменному имени в веб-запросе. Навигация это совокупность деревьев навигации. На выходе выдает активное дерево, активный раздел, заголовок активного раздела и список соответствий областей вывода (подробнее ниже) и строк запуска в них приложений. Дерево навигации это совокупность вложенных друг в друга разделов сайта. На выходе выдает активный раздел, заголовок активного раздела и список соответствий областей вывода (подробнее ниже) и строк запуска в них приложений. Итак, навигация сайта (см. рисунок 3.5) это совокупность деревьев навигации, которые в свою очередь состоят из множества вложенных друг в друга разделов сайта. Веб-запросу может соответствовать только одно дерево навигации и один раздел сайта, соответственно они называются активное дерево навигации и активный раздел.
Раздел сайта это основная информационная иерархическая единица структуры сайта (см. рисунок 3.6). Совокупность разделов образует Дерево навигации. В таблице навигации может присутствовать несколько деревьев навигации. Что на выходе выдает, думаю догадаетесь. Так как разделу сайта соответствует некое множество веб-запросов, то ответы на них в совокупности составляют страницы раздела. То есть разделу соответствует одна или несколько страниц.
Теперь подробнее о разделе сайта. Как видно на рисунке 3.6 разделу соответствует некий XSL-шаблон, который по-умолчанию подключается при трансформации XML-ответа компоненты в HTML-ответ (см. рисунок 3.2). А сам XML-ответ генерируется Генератором блоков страницы (см. рисунок 3.3). Для этого генератор берет из раздела список процессов раздела и список распределения результатов этих процессов по областям.Область вывода это участок в XSL-шаблоне, куда по задумке дизайнера должно выводится результаты выполнения какого-либо приложения. На рисунке 3.7 показана примерная конфигурация XSL-шаблона раздела.
Один из процессов раздела является главным ( master). Это логично, ибо на одной странице представлен обычно один документ (например, каталог товаров или список новостей). А вспомогательные процессы выводят какую-либо дополнительную информацию (например, последние три новости из новостной ленты). Можно устанавливать связи между вспомогательными процессами и главным (например, главный процесс выводит биографию актера, а вспомогательный — последние три фотографии из его фотоальбома, в данном случае связью будет индентификатор актера).РезюмеГлавной изюминкой ОСС является Навигация. Я предлагаю универсальный способ организации как структуры сайта, так и функциональности разделов отдельно и в совокупности посредством налаживания различных связей между ними. На мой взгляд организация формирования HTML-страниц посредством вывода результатов выполнения отдельных приложений через области вывода шаблонов разделов весьма универсальна и подходит ко всем видам и типам сайтов. А визуальная структура сайта в виде древа разделов и списков процессов у каждого раздела достаточно легко понятна непрограммисту, то есть конечному пользователю системы. ОСС предполагается быть многосайтовой, модульной (компоненты ядра и приложения), с многовариантным ядром (для создания систем под разные задачи), с универсальной системой навигации, с мощной концепцией связей между разделами, приложениями и компонентами системы. Ого, а я ведь еще не рассказал, что придумал с шаблонами дизайна. Скоро расскажу. Так что добавлю, ОСС предполагает наличие XSL-шаблонов для разделов, тем дизайна (для стандартизации пользовательского интерфейса по подобию обычных ОС) и шаблонов приложений и компонент. Дам на последок скриншот рубрикатора прототипа моей системы:
Ну, как, красиво выглядит? Пока не очень, но уже, думаю, виден прогресс в сторону удобного и понятного интерфейса по созданию сайта на ОСС. Скоро вы это будете пробовать на своих компьютерах. Дам все исходные коды и инструкцию по установке. На сегодня все. Я постарался на плакатах подать материал как можно более информативно, так что основная суть именно на них и изображена. Потому так мало текста. Готовился в выпуску вечерами аж четыре дня. То есть очень долго. Прошу оценить подачу материала и мне написать. Очень прошу! Следующий выпуск сделаю в зависимости от присланных вами писем. Ответы на ваши письма читайте в приложении к данному выпуску, которое выйдет завтра. В следующем выпуске: ой, не знаю что в следующем выпуске... нет, вы не подумайте, у меня еще много материала, мне еще столько надо рассказать, ого-го. Еще ведь прототип системы я не опубликовал. А еще про такое понятие как Служба надо рассказать, про подсистему прав доступа, журналирование событий, задания по расписанию, выводные режимы и прочие компоненты. А еще ведь целая куча задумок по приложениям, связям между ними. И много-много плакатов будет. Значит так, следующий выпуск будет на неделе до выходных. А что именно будет, вы подскажете своими письмами. Итак, вопросы есть? Есть — тогда пишите! Всего доброго!
|
| В избранное | ||
