МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» (НГУ)
____________________________________________________________________________________________________________________
Кафедра… систем информатики ………………………………………………………………
(название кафедры)
Согласовано
Утверждаю
Гл. специалист предприятия
Зав.кафедрой…………………
(для которого выполнена реальная работа)
…………/ Семенов И.А. …….
…………/ Лаврентьев М.М.….
(подпись, инициалы, фамилия)
(подпись, инициалы, фамилия)
«___»_______________2009г.
«___»_______________2009г.
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К ДИПЛОМНОМУ ПРОЕКТУ (РАБОТЕ) НА ТЕМУ
Разработка внешней системы управления содержимым сайтов……………………………...
……………………………………………………………………………………………………...
Автор дипломного проекта (работы) …………………………………………………………...
(подпись студента, выполнившего дипломный проект или работу)
Анисимов А.О. …………………………………………… Группа 6209.……………………...
(фамилия, инициалы студента)
(в которой обучался студент)
ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
СПЕЦИАЛЬНОСТЬ 230105.65 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНОЙ
ТЕХНИКИ И АВТОМАТИЗИРОВАННЫХ СИСТЕМ
Руководитель проекта (работы)……………………/ Васючкова Т.С.……………………….
(подпись, инициалы, фамилия)
…………………/ Семенов И.А..……………………….
Новосибирск, 2009г.
2
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ....................................................................................................................................3
1. ЦЕЛИ И ЗАДАЧИ .................................................................................................................4
2. АНАЛИЗ СУЩЕСТВУЮЩИХ РЕШЕНИЙ.......................................................................5
2.1. Платформы для сайта .....................................................................................................5
2.2. Генераторы HTML-страниц ...........................................................................................6
2.3. Инструментарий ..............................................................................................................6
3. ТРЕБОВАНИЯ К СИСТЕМЕ ...............................................................................................8
3.1. Внешняя система управления ........................................................................................8
3.2. Собственное хранилище данных ...................................................................................8
3.3. Визуальное редактирование ..........................................................................................8
3.4. Функциональные требования ........................................................................................9
3.4.1. Редакторы содержимого .........................................................................................9
3.4.2. Администраторы системы ....................................................................................11
4. ОСНОВНЫЕ ОГРАНИЧЕНИЯ ..........................................................................................13
4.1. DOM интерфейс ............................................................................................................13
4.2. Различия браузеров .......................................................................................................13
4.3. Динамические элементы ..............................................................................................14
4.4. Поисковые системы ......................................................................................................14
5. АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА ..........................................................16
6. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ .....................................................................................21
6.1. Реализация клиентской части ......................................................................................21
6.2. Реализация серверной части ........................................................................................21
6.3. Идентификация элементов...........................................................................................22
6.4. Инструменты и программные средства ......................................................................23
6.4.1. Enterprise Java Beans 3 ...........................................................................................23
6.4.2. Apache Geronimo ....................................................................................................23
6.4.3. JavaScript ................................................................................................................23
6.4.4. MySQL ....................................................................................................................24
6.5. Системные требования .................................................................................................24
6.5.1. Сервер .....................................................................................................................24
6.5.2. Клиент .....................................................................................................................24
ЗАКЛЮЧЕНИЕ............................................................................................................................25
СПРАВОЧНИК ТЕРМИНОВ .....................................................................................................26
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ....................................................................27
ПРИЛОЖЕНИЕ A. ИНТЕРФЕЙС ПРОГРАММЫ ..................................................................28
3
ВВЕДЕНИЕ
Дипломная
работа
выполнена
в
ООО
«Интернет
Сервис»
в
рамках
экспериментального исследовательского проекта. Тема диплома связана с актуальной
областью знаний – совершенствованием интернет технологий.
Простой, не имеющий специальных знаний пользователь/владелец сайта, часто
сталкивается с неудобствами и ограничениями при изменении сайта. А именно, владелец
сайта желает изменить информацию на нём, но далеко не всегда может сделать это сам.
Он вынужден обращаться к программисту – разработчику сайта, вынужден тратить деньги
на доработку.
Причина в том, что традиционный подход к управлению информацией на сайтах
задает конкретные возможности изменения содержимого сайта на этапе его разработки.
По сути, существующие средства управления содержимым входят в состав платформы
(основы) для сайта. Если сайт уже создан, и имеет ограниченный функционал для
управления содержимым, то использовать какое-либо стороннее средство для изменения
нужной информации не получится. В таком случае возможно либо расширить
существующий функционал, либо полностью перенести сайт на новую платформу.
Цель дипломной работы – снятие подобных ограничений.
В идеале владелец сайта должен иметь возможность изменять любую видимую
информацию на нём, даже не смотря на то, что это не было «технологически заложено»
при создании сайта. При этом от него не требовалось бы никаких особенных навыков,
кроме элементарных представлений о том, что такое сайт и как им пользоваться.
Для достижения цели решалась задача построения системы, отвечающей
указанным выше условиям.
Дипломная работа базируется на результатах курсовой работы, проведённой в
2007-2008 учебном году, в ходе которой была изучена проблема, проведен сравнительный
анализ существующих систем управления содержимым сайтов, предложен способ
решения
проблемы,
учитывая
недостатки
существующих
систем,
определены
функциональные требования и реализован прототип.
В 2008-2009 учебном году был проведен анализ результатов курсовой работы,
выявлены основные недостатки ранее созданного прототипа, выбран способ устранения
этих недостатков, реализована новая версия программы и проведена опытная
эксплуатация.
4
ЦЕЛИ И ЗАДАЧИ
Проблема состоит в том, что на сайтах присутствуют элементы, которые нельзя
изменить в процессе эксплуатации. Это может быть элемент оформления, статический
текст, или другой видимый элемент.
При создании сайта обычно определяется набор элементов, которые будут
изменяться в процессе эксплуатации. Этот набор зависит от применяемых средств
управления содержимым, и, как правило, органичен. Иногда возникают ситуации, когда
владельцу сайта приходится обращаться к услугам фирмы-разработчика только для того,
чтобы изменить несколько графических или текстовых элементов.
Таким образом, основная цель дипломного проекта – избавить владельца сайта от
необходимости прибегать к услугам специалистов только для того, чтобы изменить
отдельный элемент на сайте.
Задача состоит в разработке программного средства, которое позволит своему
пользователю изменять любые видимые элементы сайта. При этом необходимо учесть
сайты, которые уже находятся в процессе эксплуатации. Желательно также, чтобы этим
инструментом мог воспользоваться обычный посетитель сайта, не имеющий никаких
представлений о том, как сайт устроен изнутри.
Это задачу можно разделить на несколько подзадач, которые перечислены ниже:
1. провести анализ проблемы;
2. провести анализ существующих решений;
3. предложить собственный метод решения;
4. определить основные требования к системе;
5. создать программную реализацию;
6. провести опытную эксплуатацию созданного инструмента с пользовательской
оценкой его возможностей.
5
АНАЛИЗ СУЩЕСТВУЮЩИХ РЕШЕНИЙ
Существующие системы управления содержимым сайтов можно разделить на два
типа по способу их интеграции с сайтом. Первый тип – это системы, представляющие
собой платформу для сайта, и вторые – это генераторы HTML-страниц. Ниже приведены
их основные достоинства и недостатки.
1.1. Платформы для сайта
Системы, представляющие собой платформу для будущего сайта, как правило,
содержат достаточный инструментарий для изменения информации. Обычно такие
системы имеют собственную базу данных, и генерируют содержимое сайта на основе
модели данных. Пользователю же предоставляется высокоуровневый интерфейс,
посредством которого он может изменять внутреннюю модель данных. Примерами
являются Drupal, TYPO3, 1С-Битрикс.
Можно выделить следующие основные преимущества таких систем, которые
являются также отличительными особенностями данного типа систем управления
содержимым:
1. Возможность хранения и изменения информации в БД.
2. Возможность обработки информации, вводимой посетителями на страницах
сайта.
Хранение информации в специальной базе данных позволяет иметь на сайте набор
изменяющейся со временем информации, например ленты новостей, форума, списка
товаров и услуг и т.д. База данных также может использоваться для подсчёта статистики
посещений.
Возможность обработки информации позволяет располагать на сайте различные
интерактивные элементы, такие как формы, счётчики, и программно обрабатывать
взаимодействие пользователя с этими элементами.
Главный недостаток таких систем состоит в том, что готовый сайт перевести на
новую платформу без изменений практически невозможно. Обычно при переносе
отдельные функции сайта реализуются заново на новой платформе. В отдельных случаях
приходится даже менять дизайн, потому что большинство платформ несовместимы между
собой как по структуре сайта, так и по его содержанию и оформлению.
Этот недостаток частично преодолевается наличием функции импорта данных,
которая позволяет перенести уже существующий сайт на новую платформу. Но это может
6
быть применено только к статическим сайтам, т.е. к сайтам, не содержащим
интерактивных и динамических элементов, таких как формы, динамические списки и т.д.
Учитывая эту особенность, можно сказать, что данный класс систем управления
содержимым нельзя использовать применительно к большому количеству сайтов, уже
находящихся в процессе эксплуатации.
1.2. Генераторы HTML-страниц
Системы данного типа используются для генерации статических HTML-страниц.
Такие страницы могут быть объединены в сайт, вместе с различным статическим
содержимым (картинки, файлы, и пр.). Примером такого вида программных средств
является Microsoft Office FrontPage.
Преимуществ у них по сравнению с платформами практически нет, зато есть
недостатки, из-за которых такие программные средства всё реже используются для
создания современных сайтов.
Основной недостаток таких систем управления содержимым состоит в том, что
область их применения ограничена сайтами, которые содержат только статическую
информацию. На таких сайтах отсутствует интерактивность между посетителями и
содержимым сайта, а также нет возможности хранить какую-либо информацию в базе
данных.
1.3. Инструментарий
Принципиальный подход, используемый в существующих системах, состоит в том,
что инструментарий, с помощью которого можно изменить отдельные элементы сайта,
вынесен в отдельную рабочую область. Не смотря на наличие функции предварительного
просмотра, позволяющей увидеть то, как сайт будет выглядеть после изменения, от
пользователя требуется условно соотнести инструментарий с теми элементами сайта,
которые им управляются.
Также в обзоре существующих систем управления содержимым следует отметить
такой параметр как сложность. Как инструмент для редактирования сайта, они могут
требовать специальной подготовки при работе с ними. Эта подготовка должна включать
знания о типичной внутренней структуре сайта, умение работать с т.н. шаблонами –
специально подготовленными страницами, в которых надо поместить информацию, а
также характерными для отдельно взятой системы деталями.
7
То есть пользователю предлагается работать с моделью сайта, а не с внешним его
представлением, которое он привык видеть. Это требует обучения и может создать
неудобства отдельным пользователям.
В данной работе предполагается, что с системой управления содержимым может
работать любой, кто умеет пользоваться самим сайтом. То есть, для пользователя
достаточно его собственного представления о том, что такое сайт, и не обязательно знать,
как сайт устроен изнутри.
8
ТРЕБОВАНИЯ К СИСТЕМЕ
Как видно, существующие средства управления содержимым имеют недостатки,
которые не позволяют применять их тогда, когда сайт уже находится в эксплуатации (в
общем случае). Чтобы использовать основные преимущества существующих систем
применительно к решаемой проблеме, и избавиться от их основных недостатков, был
предложен следующий набор требований.
1.4. Внешняя система управления
Система управления содержимым должна быть внешней по отношению к сайту. То
есть она не должна представлять собой основу для сайта. Вместо этого требуется
получить дополнительное средство для изменения информации на уже созданном и
работающем сайте.
Такой подход позволит изменять информацию на сайтах, построенных на любой
платформе, и имеющих произвольную структуру. Также это позволит использовать её в
случае, когда сайт уже создан и находится в эксплуатации. Таким образом, у владельца
сайта появится возможность изменять любой блок информации, вне зависимости от того,
имеется ли на сайте встроенный функционал для его изменения или нет.
1.5. Собственное хранилище данных
Чтобы иметь возможность создавать и изменять содержимое сайта, а также хранить
всю дополнительную информацию об изменениях, системе управления содержимым
потребуется иметь собственную базу данных.
1.6. Визуальное редактирование
Чтобы инструментом мог воспользоваться человек, не имеющий специальной
подготовки, необходимо предоставить ему возможность изменять то, что он видит на
сайте, просто выбрав нужный элемент курсором мыши, и изменив содержимое этого
элемента. В этом случае то, каким становится сайт после изменений, видно сразу, и нет
необходимости использовать функцию предварительного просмотра. Такой подход
используется практически во всех текстовых редакторах, поэтому не потребует от
пользователей
специальных знаний кроме тех, которые они приобрели, работая с
текстовыми документами, например, в формате Microsoft Word.
9
1.7. Функциональные требования
Помимо обычных посетителей сайта, которые могут просматривать информацию,
взаимодействовать с ним обычным образом, должны быть те, кому предоставляется
возможность изменить эту информацию. Для того чтобы получить такую возможность,
необходимо пройти процесс аутентификации, предоставив системе имя пользователя и
пароль. Назовём таких пользователей редакторами.
Для отдельно взятого сайта может понадобиться иметь более одного редактора, и
желательно, чтобы у каждого были свои уникальные данные, которые позволят отличить
одного от другого. За этим могут следить администраторы системы, которые также
могли бы отслеживать изменения, которые производят редакторы на сайте.
Ниже приведены функциональные требования к системе в виде вариантов
использования для пользователей обеих групп.
1.7.1. Редакторы содержимого
Вход в режим редактирования
Таблица 1
Описание
Пользователь активирует режим редактирования на странице.
Условия
Пользователь открыл страницу сайта с установленной системой управления
содержимым.
Событие
Нажатие на иконку CMS в правом нижнем углу экрана.
Порядок
1. Рядом с иконкой CMS появляется форма с полями для
выполнения
идентификации (имя пользователя и пароль).
2. Пользователь вводит необходимую информацию и нажимает кнопку
Войти.
3. Система проверяет введённую информацию. В случае несовпадения
с имеющейся информацией выдаётся сообщение об ошибке ввода и
повторяется п.2.
4. К заголовку страницы добавляется текст “(режим редактирования)”.
5. Курсор изменяется на указатель.
6. Рядом с иконкой CMS появляются ещё две – Сохранить и Отмена,
предназначенные для сохранения и отмены изменений на странице
соответственно.
Результаты
Просматриваемая страница переведена в режим редактирования.
Замечания
Форма авторизации может исчезать автоматически, когда пользователь
нажал левую кнопку мыши где-либо на странице.
Если пользователь уже авторизован, то шаги 1-3 опускаются.
Выбор элемента страницы
Таблица 2
Описание
Пользователь выбирает элемент страницы для изменения.
Условия
Страница находится в режиме редактирования.
Событие
Пользователь выбирает указателем мыши нужный элемент и нажимает
левую кнопку мыши.
10
Порядок
выполнения
Результаты
Замечания
1. Всё содержимое страницы блокируется для ввода.
2. В центре страницы появляется окно с редактором, в который
помещается содержимое выбранного элемента. В редакторе
представлен стандартный набор функций для изменения
содержимого – изменения стиля (жирный, наклонный,
подчёркнутый), шрифта, размера, выравнивания, отступа, создания
маркированного и немаркированного списков, а также вставки и
удаления картинок и гиперссылок. Под редактором находятся две
кнопки – Изменить и Отмена для сохранения и отмены изменений
соответственно. Также рядом с кнопками находится флажок
“Изменить все похожие элементы на сайте” для того чтобы
пользователь мог определить текущий редактируемый элемент как
общий.
Выбранный блок доступен для редактирования.
Блокировка страницы осуществляется обычным для оконных приложений
способом: окно редактора переводится в т.н. модальный режим, при
котором всё, что находится снаружи окна, затеняется. При попытке
пользователя обратиться к затенённой области заголовок модального окна
мигает, что означает, что это окно необходимо закрыть, прежде чем
обращаться к заблокированному содержимому.
Для того чтобы пользователю было легче выбрать нужный элемент для
редактирования, при перемещении указателя текущий элемент должен
выделятся цветом или бордюром.
Изменение элемента страницы
Таблица 3
Описание
Пользователь изменяет текст выбранного элемента.
Условия
Пользователь выбрал элемент для редактирования.
Событие
Нажата кнопка Изменить в редакторе.
Порядок
1. Изменяется содержимое редактируемого элемента на странице.
выполнения
2. Закрывается окно редактора.
3. Снимается блокировка страницы.
Результаты
Пользователь изменил содержимое выбранного элемента. Появилась
возможность редактировать другую информацию на странице.
Замечания
Если выбран флажок “Изменить все похожие элементы на сайте”, то на
шаге 1 также изменяется содержимое всех элементов страницы, которые
имели такое же содержимое, какое было у выбранного элемента до начала
редактирования.
При нажатии кнопки Отмена в редакторе выполняются только шаги 2-3.
Сохранение изменений
Таблица 4
Описание
Пользователь сохраняет все изменения на странице.
Условия
Страница находится в режиме редактирования.
Событие
Нажатие на иконку Сохранить в правом нижнем углу экрана.
Порядок
1. Все активные элементы страницы, которые выделены для
выполнения
редактирования, снимают выделение.
2. Скрываются кнопки Сохранить и Отмена в левом нижнем углу
экрана.
3. Пользователю сообщается о начале процесса сохранения.
11
Результаты
Замечания
4. Вся информация страницы сохраняется на сервере.
5. Пользователю сообщается о статусе сохранения. Если при
сохранении произошли какие-либо ошибки, и страница не сохранена,
показывается соответствующее уведомление.
Все изменения на странице сохранились и стали видны посетителям сайта;
страница вернулась в режим просмотра.
В дальнейшем неплохо было бы сделать контроль изменений для каждой
страницы с целью фиксировать все изменения и иметь возможность отката
после сохранения страницы.
Отмена изменений
Таблица 5
Описание
Содержимое возвращается к исходному варианту.
Условия
Страница находится в режиме редактирования.
Событие
Нажатие на иконку Отмена в правом нижнем углу экрана.
Порядок
1. Все активные элементы страницы, которые выделены для
выполнения
редактирования, снимают выделение.
2. Скрываются кнопки Сохранить и Отмена в левом нижнем углу
экрана.
3. Восстанавливается вся информация на странице, какая была на
момент начала редактирования.
Результаты
Все изменения на странице отменены; страница вернулась в режим
просмотра.
Замечания
Для того чтобы ещё раз изменить содержимое страницы, пользователю
понадобится повторить действия из п. 5.2.
1.7.2. Администраторы системы
Вход в систему
Таблица 6
Описание
Вход администратора в область администрирования
Событие
Переход на специальный адрес контент-сервера
Порядок
1. Ввод имени пользователя и пароля
выполнения
2. Посылка данных на сервер.
3. Показ домашней страницы области администрирования.
Результаты
Администратору предоставляется меню для управления списком редакторов
и просмотра изменений
Регистрация нового пользователя
Таблица 7
Описание
Администратор создаёт новую учётную запись пользователя
Событие
Выбор команды “Создать учётную запись” в списке пользователей
Порядок
1. Ввод имени пользователя и пароля.
выполнения
2. Ввод контактных данных нового пользователя.
3. Указание адресов сайтов, к которым новый пользователь будет иметь
доступ.
4. Посылка данных на сервер.
Результаты
В системе создаётся новая учётная запись. При этом посылается
оповещение на указанный email-адрес.
Замечания
Чтобы пользователь не ошибся при вводе пароля, необходимо иметь поле
для повторного ввода.
12
Изменение учётной записи пользователя
Таблица 8
Описание
Изменение пароля, контактной информации либо списка доступных сайтов
для зарегистрированного пользователя.
Событие
Выбор команды “Изменить учётную запись” в списке пользователей.
Порядок
Изменение соответствующей информации.
выполнения
Результаты
Обновление учётной записи.
Замечания
Те же, что и при регистрации нового пользователя.
Удаление пользователя
Таблица. 9
Описание
Удаление учётной записи пользователя
Событие
Выбор команды “Удалить учётную запись” в списке пользователей.
Результаты
Учётная запись удалена полностью.
Просмотр изменений
Таблица 10
Описание
Показ списка изменений с возможностью фильтрации по дате
Событие
Выбор пункта меню “Просмотр изменений” в области администрирования
Порядок
1. Выбор периода, за который следует показать информацию об
выполнения
изменениях.
2. Выбор редактора, который произвёл изменения.
3. Выбор из списка по дате и времени
Результаты
Администратору показывается код страницы до и после редактирования
вместе с комментариями, которые оставил редактор.
Замечания
Если редактор не выбран, то в списке должны быть отображены все
изменения за указанный период.
13
ОСНОВНЫЕ ОГРАНИЧЕНИЯ
Существует несколько технических ограничений, которые были выявлены при
создании прототипа системы. Эти ограничения в основном связаны с существующим на
данный момент способом обработки веб-страниц браузерами. Так как ограничения носят
технический характер, то вполне возможно, что все они будут преодолены в следующих
версиях системы.
1.8. DOM интерфейс
Прежде чем переходить к описанию ограничений, следует сказать, что основной и
единственный инструмент, который позволяет системе изменять содержимое страницы –
т.н. DOM (Document Object Model) интерфейс. Он позволяет представить страницу как
дерево, содержащее элементы оформления и текст. Это дерево строится браузером, после
того, как он получит и обработает HTML-код с сервера.
1.9. Различия браузеров
В разных браузерах DOM-дерево может быть различным. Это может быть
результатом следующего:

Сервер генерирует содержимое страницы в зависимости от модели браузера. При
каждом запросе браузер посылает подробную информацию, включающую название
и версию. Сервер может использовать эту информацию, например, для генерации
HTML-кода, оптимизированного под конкретную модель браузера.

В широко распространённом браузере Microsoft Internet Explorer 6 содержимое
страницы может быть изменено уже на клиенте, в результате работы так
называемых HTC-скриптов, которые не поддерживаются остальными браузерами.
Такие
скрипты
используются,
например,
для
корректного
показа
PNG-
изображений, имеющих альфа-канал.

Браузеры по-разному обрабатывают неправильно оформленный HTML-код. В
результате такой обработки могут получиться различные DOM-деревья для одной
и той же страницы в разных браузерах.
Первый вариант, при котором сервер генерирует содержимое страницы, в
зависимости от модели браузера довольно редко встречается на реальных web-сайтах. В
14
основном это может касаться решения проблемы с PNG-изображениями, имеющими
альфа-канал, описанной во втором пункте. В этом случае структура DOM-дерева
существенно не меняется, изменяются только атрибуты элементов (IMG в примере), что
не препятствует идентификации этих элементов, т.к. их содержимое и абсолютный путь
остаются те же. Остальные случаи следует принять как исключительные, при которых
система действительно может работать не так, как планируется. В силу крайней редкости
таких ситуаций, их стоит отнести за рамки данной системы.
В случае применения HTC-скриптов, используемых для корректного показа PNGизображений с альфа-каналом, DOM-дерево также не меняется, как сказано выше.
Остальные
случаи
работы
HTC-скриптов
следует
также
отнести
в
разряд
исключительных, т.к. их применение ограничено одним браузером.
Случаи с неправильно оформленным HTML-кодом в большинстве сводятся к
отсутствию закрывающего тега у элементов страницы. В этом случае наиболее
распространённые браузеры, такие как Mozilla Firefox и Microsoft Internet Explorer
поступают одинаковым образом – они автоматически добавляют закрывающий тег и
помещают все последующие элементы внутрь данного элемента. Таким образом, в
большинстве случаев DOM-дерево будет одинаковым.
1.10. Динамические элементы
Сайт может иметь элементы, которые создаются динамически в зависимости от
каких-либо
условий.
Например,
динамические
списки
новостей,
наполняемые
информацией из базы данных. У внешней системы управления содержимым нет контроля
над источником этой информации (предполагается, что об источниках информации для
сайта ничего не известно). Поэтому при редактировании таких элементов могут
возникнуть коллизии. На примере может произойти следующее: пользователь изменил
элемент списка новостей визуально в редакторе, и в тоже время обновил информацию в
БД. При этом возникает проблема: какие изменения принять?
Эта проблема на данный момент не имеет решения. Предполагается, что если сайт
имеет какие-либо источники информации помимо системы управления содержимым, то
пользователь ответственен за выбор инструмента для изменения этой информации, и ему
просто не рекомендуется изменять одну и ту же информацию двумя разными способами.
1.11. Поисковые системы
15
Данный пункт относится только к прототипу, в котором функция замены
содержимого была реализована на клиенте. Проблема с индексированием страниц в нём
была частично решена, как написано ниже, но новый подход с переносом функции замены
содержимого на сервер позволил полностью избавиться от этой проблемы.
Страницы с отдельно хранимым содержимым, которое заменяется при открытии,
не могут быть проиндексированы поисковыми роботами. В случае если последние при
индексации обнаружат перенаправление с одной страницы на другую (например, с адреса
содержимого на адрес страницы, содержащей текст), поисковые системы автоматически
заносят страницу в чёрный список. В таком случае страница не сможет быть найдена с
помощью данной поисковой системы.
Для решения проблемы индексации используется специальная ссылка, добавляемая
на страницу, которую необходимо проиндексировать, сразу при установке системы. Эта
ссылка имеет определённый адрес, ведущий на сервер содержимого (content-сервер),
который может быть установлен там же, где и основной сайт. Поисковая система,
индексирующая страницу с такой ссылкой, должна проиндексировать содержимое,
хранящееся на content-сервере. Далее, при поиске, поисковая система должна направлять
пользователей на адрес сервера содержимого. Сервер содержимого же должен
представлять информацию, а также ссылку на страницу, информация которой была
представлена. При этом пользователя необходимо уведомить о том, что он просматривает
не искомую страницу, а лишь часть содержимого этой страницы, и что полная
информация представлена на оригинальной странице.
16
АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА
Как и большинство веб-приложений, система управления содержимым сайтов
(CMS) имеет архитектуру клиент-сервер. Серверная часть системы имеет доступ к базе
данных, и выполняет функции обработки и хранения данных приложения. Клиентская
часть системы – это набор программных модулей, исполняемых на странице сайта.
Клиент и сервер взаимодействуют друг с другом как показано на рисунке 5.1.
Рисунок 5.1. Схема взаимодействия частей приложения.
Принцип работы всего приложения выглядит следующим образом. При обращении
к странице сайта запрос перенаправляется на CMS сервер, который в данном случае
используется как своего рода прокси-сервер. CMS сервер получает оригинальное
содержимое сайта, обрабатывает его, вставляет новую информацию, которая была
изменена пользователем, и возвращает содержимое клиенту (браузеру). При вставке
нового содержимого content-сервер также добавляет специальный программный модуль,
исполняемый на клиенте. Этот программный модуль создаёт на странице функционал,
необходимый для редактирования и последующей замены содержимого. Также этот
модуль может осуществлять дополнительные действия, например, регулярно опрашивать
сервер об изменениях. Схема работы всей системы показана на рисунке 5.2.
17
Рисунок 5.2. Схема работы приложения.
В итоге программный
модуль, выполняемый на странице сайта, реализует
несколько функций. Какие-то из этих функций имеют наибольший приоритет, и должны
выполниться в первую очередь. Остальные функции могут зависеть от результатов её
выполнения. Между собой функции практически не связаны. Поэтому весь программный
модуль спроектирован так, чтобы максимально разделить выполняемые функции, и
осуществить возможность изменять и дополнять набор этих функций. Для этого
использовано понятие общая шина данных (Data Bus), и взаимодействие всех функции,
включая ядро системы, организовано посредством этой шины (рис.5.3). Работа с шиной
представляется в виде подписки и публикации событий, которые происходят в системе.
Функция-подписчик определяет набор событий, на которые она реагирует. Все функции,
включая ядро системы, могут публиковать свои события для их обработки другими
функциями. Таким образом организовано событийное управление всей клиентской частью
приложения в целом.
18
Рисунок 5.3. Схема взаимодействия посредством общей шины данных.
В качестве первого этапа работы над проектом был создан прототип системы,
который включает следующие функции:

Изменение
содержимого
на
отдельной
странице
сайта.
Пользователю
предоставляется возможность изменить любой выбранный им элемент страницы.
При этом все изменения видны сразу и нет необходимости перезагружать страницу
или иметь функцию предварительного просмотра.

Для
редактирования
информации
используются
стандартные
компоненты,
позволяющие изменять стиль текста (жирный, наклонный, подчёркнутый), шрифт,
размер, выравнивание, отступ, создание маркированного и немаркированного
списков, а также вставки и удаления картинок и гиперссылок.

Общие
элементы
страниц,
такие
как
меню,
верхняя
и
нижняя
часть,
рассматриваются как один элемент, и редактируются один раз. Таким образом,
если пользователь изменит один из общих элементов на одной странице,
изменения затронут все страницы, содержащие этот элемент.

Показ изменений для посетителей сайта. После того как пользователь (редактор)
изменит содержимое страницы, и сохранит изменения, обновлённая версия
страницы незамедлительно становится доступной посетителям сайта.
19
При реализации прототипа функция замены содержимого была перенесена на
клиентскую часть, что имеет свои достоинства и недостатки. В рамках дипломной работы
был предложен другой вариант реализации.
Сравнение двух вариантов реализации
приведено в таблице 11. Из очевидных плюсов нового подхода стоит выделить перенос
вычислительных затрат с клиента на сервер, возможность кэширования результатов и
распараллеливания вычислений, отсутствие проблемы с поисковыми системами и
обычная с точки зрения посетителя работа сайта. Явным минусом является доставка
содержимого клиенту посредством контент-сервера, а не напрямую.
Сравнение двух подходов к реализации.
Замена
Таблица 11
содержимого
на Замена
клиенте
содержимого
сервере
Доставка содержимого Непосредственно
Посредством CMS-сервера
клиенту
Вычислительные
Высокие
Низкие
Низкие
Средние
Нет
Да
Нет
Да
С задержкой
Как обычно
затраты на клиенте
Вычислительные
затраты на сервере
Возможность
кэширования
результатов
замены
содержимого
Возможность
распараллеливания
вычислений
Особенности
рендеринга
содержимого
на
клиенте
Индексация страниц
Затруднена из-за того, что Возможна
поисковые
индексируют
системы
не
результаты
выполнения кода на клиенте.
на
20
Для того чтобы CMS-сервер мог обрабатывать запросы к сайту раньше, чем сам
сайт, была предложена следующая схема.
Обычно при запросе к сайту сперва обрабатывается его доменное имя (domain
name), которое преобразуется в IP-адрес DNS-сервером. После этого, используя
полученный IP-адрес, браузер открывает соединение с Web-сервером сайта, и получает
его содержимое. Чтобы “перехватить” оригинальное содержимое, доменное имя сайта
должно быть преобразовано в IP-адрес нашего контент-сервера, который, в дальнейшем,
зная оригинальный IP-адрес, мог бы получить и обработать оригинальное содержимое.
Таким образом, имеем следующую схему обработки запросов к сайту. Вместе с
CMS-системой устанавливается и настраивается DNS-сервер, адрес которого указывается
в настройках зоны. На запрос адреса сайта по доменному имени DNS-сервер возвращает
адрес контент-сервера, который после этого получает и обрабатывает запрос на
предоставление содержимого сайта.
Чтобы получить оригинальное содержимое, контент-сервер формирует запрос по
известному ему IP-адресу, после чего получает оригинальное содержимое и обрабатывает
его, как было сказано ранее.
21
ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
1.12. Реализация клиентской части
Клиентская часть реализована на языке JavaScript в виде набора классов,
распределённых по т.н. пакетам. Сам язык является объектно-ориентированным, но не
поддерживает классы как таковые, так же как и механизм наследования. Вместо этого в
языке поддерживается прототип-ориентированный подход, неудобный по многим
причинам. Для осуществления класс-ориентированного подхода в проекте используется
специальный инструмент, преобразующий конструкции языка, используя регулярные
выражения. Этот подход позволяет создавать классы, объединять их в пакеты, и
наследовать классы од других.
Все классы приложения разбиты по нескольким вложенным пакетам. Класс
CmsApplication, представляющий собой ядро системы, вынесен в корневой пакет cms.
Классы, реализующие работу с общей шиной данных, вынесены в пакет cms.events.
Остальные функции системы, реализованные в виде встраиваемых модулей (plug-in),
находятся в пакете cms.plugins:

Пакет cms.plugins.auth содержит классы, реализующие механизм аутентификации
пользователя.
 Пакет cms.plugins.editor содержит классы, реализующие функцию редактирования
содержимого страницы.
1.13. Реализация серверной части
Серверная
часть
реализована
в
виде
постоянно
работающего
сервиса,
принимающего запросы от посетителей сайтов, и возвращающего содержимое после
обработки. Также реализован отдельный сервис для сохранения изменений, которые
присылает клиентская часть.
Для оптимизации работы сервиса реализован кеш на диске, в котором хранится
содержимое сайтов с проведенными изменениями. Этот кеш формируется при первом
запросе к содержимому сайта, после этого содержимое извлекается непосредственно из
него.
Отдельная часть приложения обеспечивает функционал для управления системой в
целом. Здесь реализовано рабочее место администратора системы.
22
1.14. Идентификация элементов
После того, как пользователь изменит содержимое отдельного элемента DOMдерева, необходимо отображать эти изменения при новом открытии страницы. Для этого
требуется
однозначно
идентифицировать
элемент
страницы,
который
был
отредактирован. Проблема состоит в том, что страница может иметь несколько элементов,
похожих друг на друга. Таким образом, в DOM-дереве могут быть несколько совершенно
одинаковых поддеревьев, которые необходимо однозначно идентифицировать.
Ко всему этому, один сайт может состоять из нескольких страниц, на каждой из
которых могут быть одинаковые элементы, например, меню. Эти элементы должны быть
не только однозначно идентифицированы, но и “распознаны” как общие элементы сайта,
чтобы их изменение на одной странице повлекло автоматическое на всех других
страницах сайта.
Для идентификации таких поддеревьев в одном дереве страницы, необходимо
использовать информацию об остальной структуре страницы, абсолютному пути от корня
дерева, или положение поддерева относительно других поддеревьев
Решение заключается в следующем. Каждый редактируемый элемент дерева может
быть идентифицирован двумя способами: путём запоминания абсолютного пути из корня
дерева и подсчётом значения хеш-функции от содержимого этого элемента. Последний
вариант помогает решить проблему с идентификацией одинаковых элементов. Например,
если на странице есть два или более элементов с одинаковым содержимым, то они будут
иметь одинаковое значение хеш-функции. После загрузки страницы содержимое всех
подобных элементов может быть заменено, используя эти значения.
Для тех элементов, содержимое которых встречается в других элементах, но
подобная замена не требуется, используется абсолютный путь из корня дерева как
дополнительная информация, помогающая идентифицировать данный элемент. Этот путь
состоит из пар (Название_Вершины, Номер_Вершины), где Название_Вершины - это
название тега, и Номер_Вершины - это порядковый номер в списке всех вершин с таким
названием на одном уровне DOM-дерева. Например, путь может выглядеть так: (‘body’,0),
(‘table’,0), (‘tbody’,0), (‘tr’, 2), (‘td’, 1), (‘a’,0).
Существует также проблема в том, что на странице сайта могут присутствовать
элементы, созданные с помощью JavaScript. Изменение такого элемента требует
изменения не HTML-кода страницы, а JavaScript-кода, находящегося на странице, что
является достаточно трудным.
23
Чтобы решить эту проблему, каждый элемент сайта во время генерации страницы
на сервере помечается специальной меткой, по которой можно определить, что данный
элемент присутствует в HTML-коде. Далее элементы, которые не имеют такой метки
(элементы, созданные с помощью JavaScript), редактируются и сохраняются особенным
образом. Изменения при этом не затрагивают HTML-код, и применяются отдельно, после
загрузки всей страницы.
1.15. Инструменты и программные средства
1.15.1. Enterprise Java Beans 3
В реализации серверной части приложения используется технология Enterprise
JavaBeans, 3rd Edition. Эта технология является частью платформы Java Enterprise Edition и
предназначена для создания и поддержки серверных компонент, содержащих бизнеслогику на языке Java. Третья версия спецификации в отличие от предыдущих версий
признана Java-сообществом как наиболее удобная для использования.
Сам язык Java был выбран из-за его особенностей, таких как широкая поддержка
объектно-ориентированного программирования и строгая типизация, а также большого
количества готовых библиотек, в том числе для разбора и генерации HTML. Также вместе
с языком поставляется инструментарий для мониторинга производительности системы,
Java Management Extensions.
В общем и целом выбор языка
Java и технологии
EJB3 обусловлен
необходимостью стабильной и высокопроизводительной работы серверной части. Это
является критической частью системы, так как при нестабильной работе посетители не
будут иметь возможность получить информацию с сайта.
1.15.2. Apache Geronimo
Сервер приложений с открытым исходным кодом, поддерживающий технологию
Enterprise Java Beans 3 и имеющий в составе контейнер для веб-приложений Apache
Tomcat.
1.15.3. JavaScript
Для реализации клиентской части приложения, выполняемой на странице сайта,
выбран язык JavaScript. JavaScript является универсальным языком для написания
24
сценариев, выполняемых на веб-страницах. Он доступен практически в любом
современном браузере без необходимости установки каких-либо дополнительных средств.
Таким образом, приложение, реализованное на языке JavaScript, доступно большинству
людей, имеющих доступ к Интернету.
JavaScript является прототип-ориентированным языком. Это означает, что в нём
нет такого понятия как класс. Все сложные объекты создаются путём копирования
свойств и методов объекта-прототипа. Такой подход в объектно-ориентированном
программировании не удобен тем, что исключает стандартный механизм наследования.
Поэтому в проекте используется своего рода расширение языка, позволяющее создавать
свои классы, пакеты классов, и поддерживающее механизм наследования.
Для взаимодействия клиентской и серверной части используется механизм
асинхронной передачи данных AJAX (Asynchronous JavaScript and XML).
1.15.4. MySQL
MySQL на данный момент является одной из наиболее широко используемых
СУБД для работы малых и средних веб-приложений. Программное обеспечение для этой
СУБД, как и она сама, свободно распространяется.
Как инструмент работы с базой
данных MySQL сочетает простоту и необходимую функциональность.
1.16. Системные требования
1.16.1. Сервер
Для работы программного обеспечения требуется сервер c установленными
программными компонентами:
1. Apache Geronimo v2.1.4
2. Java EE 5
3. MySQL 5
1.16.2. Клиент
Для работы с CMS-клиентом нужен браузер Mozilla Firefox версии 3.0 или выше.
25
ЗАКЛЮЧЕНИЕ
В процессе дипломной работы удалось выполнить необходимый объём работ,
конкретно было сделано следующее:
1. изучена проблема;
2. поставлена задача для её решения;
3. проведен анализ существующих систем, определены их основные достоинства
и недостатки;
4. определены требования к создаваемой системе и основные ограничения;
5. разработаны проектные решения;
6. в соответствии проектными решениями реализована программная система;
7. проведена её опытная эксплуатация.
Как возможный вариант развития системы, существует возможность расширить её
функционал. Помимо создания и изменения простых элементов сайта, есть возможность
реализовать создание универсальных интерактивных компонентов сайта, например
проигрыватель видео файлов, сводки новостей, постоянно обновляющийся курс валют и
т.д.
Также есть возможность реализовать подсчёт и обработку статистики посещений
сайта, качественный и количественный анализ этой информации. Это поможет
пользователям оценить, насколько эффективен их сайт целиком и отдельные изменения,
которые были произведены.
По результатам опытной эксплуатации созданной системы можно сказать, что
внешняя система управления содержимым сайтов может быть востребована компаниями,
которые предоставляют своим пользователям возможность создать собственную страницу
или сайт. Это могут быть различные хостинг-провайдеры, порталы, или сервисы для
ведения блогов.
По материалам данной работы был сделан доклад на Международной научной
студенческой конференции 26 - 30 апреля 2008 года.
26
СПРАВОЧНИК ТЕРМИНОВ
1. AJAX (сокр. Asynchronous JavaScript and XML) – способ асинхронной передачи
данных между клиентом (браузером) и сервером.
2. CMS (от англ. Content Management System) – система управления содержимым.
3. DOM (от англ. Document Object Model) - интерфейс управления содержимым XML и
HTML документов.
4. HTML (от англ. Hypertext Markup Language) – язык разметки web-содержимого.
5. HTTP (от англ. Hypertext Transfer Protocol) – протокол взаимодействия клиента с
сервером, описывающий формат пересылки web-содержимого.
6. PNG (от англ. Portable Network Graphics) – растровый формат хранения графической
информации.
7. Альфа-канал - процесс комбинирования изображения с фоном с целью создания
эффекта частичной прозрачности.
8. Браузер (от англ. Browser) – программа, исполняющаяся на стороне клиента,
посылающая на сервер HTTP-запросы и обрабатывающая ответы сервера.
9. Индексация - процесс добавления сведений о сайте в базу данных для дальнейшего
поиска информации.
10. Поисковая система – web-сайт, предоставляющий возможность поиска информации в
Интернете.
11.Поисковый робот - программа, являющаяся составной частью поисковой системы и
предназначенная для обхода страниц Интернета с целью занесения информации о
ключевых словах в базу поисковика.
27
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Каталог
CMS
—
сравнение,
аналитика,
опыт
использования.
http://www.cmsmagazine.ru/catalogue/.
2. CMS с открытым исходным котом. http://opensourcecms.com/.
3. “Матрица сравнения” различных CMS. http://cmsmatrix.org/.
4. HTML Editor Comparison Table.
http://en.wikipedia.org/wiki/Comparison_of_HTML_editors
5. A known WYSIWYG editor directory. http://www.htmlarea.com/.
6. Microsoft Front Page.
http://office.microsoft.com/ru-
ru/help/HA100750411049.aspx.
7. Сайт Drupal. http://drupal.org/.
8. Сайт TYPO3 Association. http://www.typo3.com/.
9. Сайт 1С-Битрикс. http://www.1c-bitrix.ru/.
10. Параллельный доступ к элементам DOM-модели.
http://weblogs.mozillazine.org/roc/archives/2007/09/parallel_dom_ac.html.
11. Статья “Списки поисковых систем: смогут ли пауки проиндексировать ваш webсайт?”. http://www.interface.ru/home.asp?artId=2444.
12. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of
Reusable Object-Oriented Software. Addison Wesley, Longman Inc. 1997.
13. Описание шаблонов проектирования. http://c2.com/.
14. Документация по СУБД MySQL. http://dev.mysql.com/doc/.
15. Enterprise Java Beans 3rd Edition. http://java.sun.com/products/ejb/.
16. James Noble (ed.), Antero Taivalsaari (ed.), Ivan Moore (ed.), ed (1999). Prototype-Based
Programming: Concepts, Languages and Applications. Springer-Verlag.
28
ПРИЛОЖЕНИЕ A. ИНТЕРФЕЙС ПРОГРАММЫ
(рекомендуемое)
Обычные посетители сайта видят только небольшую иконку в правом нижнем углу
страницы (рис.A.1). Нажав на эту иконку, пользователь может ввести логин и пароль
(рис.A.2) чтобы войти в режим редактирования.
Рисунок A.1. Сайт с небольшой иконкой для входа в режим редактирования.
29
Рисунок A.2. Вход в режим редактирования.
После входа в режим редактирования пользователю предлагается выбрать нужный
элемент курсором мыши, как показано на рисунке A.3.
Рисунок A.3. Выбор элемента для редактирования.
После этого пользователю предоставляется текстовый редактор, в котором он
может изменить выделенный фрагмент текста (рис.A.4).
30
Рисунок A.4. Изменение содержимого страницы.
После изменения текста новая информация сразу становится доступной
посетителям сайта (рис.A.5).
Рисунок A.5. Вид сайта после изменений.