глава 1 типы cms

СОДЕРЖАНИЕ
Введение
Простой, не имеющий специальных знаний пользователь/владелец
сайта, часто сталкивается с неудобствами и ограничениями при изменении
сайта. А именно, владелец сайта желает изменить информацию на нём, но
далеко не всегда может сделать это сам. Он вынужден обращаться к
программисту – разработчику сайта, вынужден тратить деньги на доработку.
Причина в том, что традиционный подход к управлению информацией на
сайтах задает конкретные возможности изменения содержимого сайта на
этапе его разработки. По сути, существующие средства управления
содержимым входят в состав платформы (основы) для сайта. Если сайт уже
создан, и имеет ограниченный функционал для управления содержимым, то
использовать какое-либо стороннее средство для изменения нужной
информации не получится. В таком случае возможно либо расширить
существующий функционал, либо полностью перенести сайт на новую
платформу.
В идеале владелец сайта должен иметь возможность изменять любую
видимую информацию на нём, даже не смотря на то, что это не было
«технологически заложено» при создании сайта. При этом от него не
требовалось бы никаких особенных навыков, кроме элементарных. Проблема
состоит в том, что на сайтах присутствуют элементы, которые нельзя
изменить в процессе эксплуатации. Это может быть элемент оформления,
статический текст, или другой видимый элемент.
При создании сайта обычно определяется набор элементов, которые
будут изменяться в процессе эксплуатации. Этот набор зависит от
применяемых средств управления содержимым, и, как правило, органичен.
Иногда возникают ситуации, когда владельцу сайта приходится обращаться к
услугам фирмы-разработчика только для того, чтобы изменить несколько
графических или текстовых элементов.
Таким образом, основная цель дипломного проекта:
Задачи дипломного проекта:
1.Рассмотреть движки CMS
2. Научиться пользоваться системой CMS
3.Разработать несколько сайтов на основе CMS
ГЛАВА 1 ТИПЫ CMS
1.1 Платформы для сайта
Существующие системы управления содержимым сайтов можно
разделить на два типа по способу их интеграции с сайтом. Первый тип – это
системы, представляющие собой платформу для сайта, и вторые – это
генераторы HTML-страниц. Ниже приведены их основные достоинства и
недостатки.
Системы, представляющие собой платформу для будущего сайта, как
правило, содержат достаточный инструментарий для изменения информации.
Обычно такие системы имеют собственную базу данных, и генерируют
содержимое
сайта
на
основе
модели
данных.
Пользователю
же
предоставляется высокоуровневый интерфейс, посредством которого он
может изменять внутреннюю модель данных. Примерами являются Drupal,
TYPO3, С-Битрикс. Можно выделить следующие основные преимущества
таких систем, которые являются также отличительными особенностями
данного типа систем управления содержимым:
1.
Возможность хранения и изменения информации в БД.
2.
Возможность обработки информации, вводимой
посетителями на страницах сайта.
Хранение информации в специальной базе данных позволяет иметь на
сайте набор изменяющейся со временем информации, например ленты
новостей, форума, списка товаров и услуг и т.д. База данных также может
использоваться
для
подсчёта
статистики
посещений.
Возможность обработки информации позволяет располагать на сайте
различные интерактивные элементы, такие как формы, счётчики, и
программно обрабатывать взаимодействие пользователя с этими элементами.
Главный недостаток таких систем состоит в том, что готовый сайт перевести
на новую платформу без изменений практически невозможно. Обычно при
переносе отдельные функции сайта реализуются заново на новой платформе.
В отдельных случаях приходится даже менять дизайн, потому что
большинство платформ несовместимы между собой как по структуре сайта,
так и по его содержанию и оформлению.
Этот недостаток частично преодолевается наличием функции импорта
данных, которая позволяет перенести уже существующий сайт на новую
платформу. Но это может быть применено только к статическим сайтам, т.е.
к сайтам, не содержащим интерактивных и динамических элементов, таких
как формы, динамические списки и т.д. Учитывая эту особенность, можно
сказать, что данный класс систем управления содержимым нельзя
использовать
применительно
к
большому
количеству
сайтов,
уже
находящихся в процессе эксплуатации.
1.2 Генераторы HTML-страниц
Системы данного типа используются для генерации статических HTMLстраниц. Такие страницы могут быть объединены в сайт, вместе с различным
статическим содержимым (картинки, файлы, и пр.). Примером такого вида
программных средств является Microsoft Office FrontPage.
Преимуществ у них по сравнению с платформами практически нет, зато
есть недостатки, из-за которых такие программные средства всё реже
используются для создания современных сайтов.
Основной недостаток таких систем управления содержимым состоит в
том, что область их применения ограничена сайтами, которые содержат
только
статическую
информацию.
На
таких
сайтах
отсутствует
интерактивность между посетителями и содержимым сайта, а также нет
возможности хранить какую-либо информацию в базе данных.
1.3 Инструментарий
Принципиальный подход, используемый в существующих системах,
состоит в том, что инструментарий, с помощью которого можно изменить
отдельные элементы сайта, вынесен в отдельную рабочую область. Не
смотря на наличие функции предварительного просмотра, позволяющей
увидеть то, как сайт будет выглядеть после изменения, от пользователя
требуется условно соотнести инструментарий с теми элементами сайта,
которые им управляются.
Также в обзоре существующих систем управления содержимым
следует отметить такой параметр как сложность. Как инструмент для
редактирования сайта, они могут требовать специальной подготовки при
работе с ними. Эта подготовка должна включать знания о типичной
внутренней структуре сайта, умение работать с т.н. шаблонами – специально
подготовленными страницами, в которых надо поместить информацию, а
также характерными для отдельно взятой системы деталями. То есть
пользователю предлагается работать с моделью сайта, а не с внешним его
представлением, которое он привык видеть. Это требует обучения и может
создать
неудобства
отдельным
пользователям.
В
данной
работе
предполагается, что с системой управления содержимым может работать
любой, кто умеет пользоваться самим сайтом. То есть, для пользователя
достаточно его собственного представления о том, что такое сайт, и не
обязательно знать, как сайт устроен изнутри.
ГЛАВА 2. ТРЕБОВАНИЯ К СИСТЕМЕ
2.1 Основные требования.
1.
Внешняя система управления
2.
Собственное хранилище данных
3.
Визуальное редактирование
Внешняя система управления. Как видно, существующие средства
управления
содержимым
имеют недостатки,
которые
не
позволяют
применять их тогда, когда сайт уже находится в эксплуатации (в общем
случае). Чтобы использовать основные преимущества существующих систем
применительно к решаемой проблеме, и избавиться от их основных
недостатков, был предложен следующий набор требований.
Система управления содержимым должна быть внешней по отношению
к сайту. То есть она не должна представлять собой основу для сайта. Вместо
этого
требуется
информации
получить
на
дополнительное
уже
созданном
средство
и
для
изменения
работающем
сайте.
Такой подход позволит изменять информацию на сайтах, построенных
на любой платформе, и имеющих произвольную структуру. Также это
позволит использовать её в случае, когда сайт уже создан и находится в
эксплуатации. Таким образом, у владельца сайта появится возможность
изменять любой блок информации, вне зависимости от того, имеется ли на
сайте
встроенный
функционал
для
его
изменения
или
нет.
Собственное хранилище данных. Чтобы иметь возможность создавать
и изменять содержимое сайта, а также хранить всю дополнительную
информацию об изменениях, системе управления содержимым потребуется
иметь собственную базу данных.
Визуальное редактирование. Чтобы инструментом мог воспользоваться
человек, не имеющий специальной подготовки, необходимо предоставить
ему возможность изменять то, что он видит на сайте, просто выбрав нужный
элемент курсором мыши, и изменив содержимое этого элемента. В этом
случае то, каким становится сайт после изменений, видно сразу, и нет
необходимости использовать функцию предварительного просмотра. Такой
подход используется практически во всех текстовых редакторах, поэтому не
потребует от пользователей специальных знаний кроме тех, которые они
приобрели, работая с текстовыми документами, например, в формате
Microsoft Word.
2.2 Функциональные требования
Помимо обычных посетителей сайта, которые могут просматривать
информацию, взаимодействовать с ним обычным образом, должны быть те,
кому предоставляется возможность изменить эту информацию. Для того
чтобы
получить
такую
возможность,
необходимо
пройти
процесс
аутентификации, предоставив системе имя пользователя и пароль. Назовём
таких пользователей редакторами.
Для отдельно взятого сайта может понадобиться иметь более одного
редактора, и желательно, чтобы у каждого были свои уникальные данные,
которые позволят отличить одного от другого. За этим могут следить
администраторы системы, которые также могли бы отслеживать изменения,
которые производят редакторы на сайте.
Ниже приведены функциональные требования к системе в виде
вариантов
использования
для
пользователей
обеих
групп.
2.3 Редакторы содержимого
Вход в режим редактирования
Описа
ние
Пользователь
Таблица
активирует
режим
редактирования
на
странице.
Услови
я
Пользователь открыл страницу сайта с установленной
системой управления содержимым.
Собы
Нажатие на иконку CMS в правом нижнем углу экрана.
тие
Поряд
1.
ок
Рядом с иконкой CMS появляется форма с полями для
выполнения
идентификации (имя пользователя и пароль).
2.
Пользователь
вводит
необходимую
информацию
и
нажимает кнопку Войти.
3.
Система проверяет введённую информацию. В случае
несовпадения
с
имеющейся
информацией
выдаётся
сообщение об ошибке ввода и повторяется п.2.
4.
К
заголовку
страницы
добавляется
текст
“(режим
редактирования)”.
5.
Курсор изменяется на указатель.
6.
Рядом с иконкой CMS появляются ещё две – Сохранить и
Отмена, предназначенные для сохранения и отмены
изменений на странице соответственно.
Результаты Просматриваемая страница переведена в режим редактирования.
Замечания
Форма авторизации может исчезать автоматически, когда
пользователь нажал левую кнопку мыши где-либо на странице.
Если пользователь уже авторизован, то шаги -3 опускаются.
Выбор элемента страницы
Таблица 2
Описание
Пользователь выбирает элемент страницы для изменения.
Условия
Страница находится в режиме редактирования.
Событие
Пользователь выбирает указателем мыши нужный элемент и
нажимает левую кнопку мыши.
1.
^
Порядок
выполнения
Всё содержимое страницы блокируется для ввода.
2.
В центре страницы появляется окно с редактором, в
который помещается содержимое выбранного элемента. В
редакторе представлен стандартный набор функций для
изменения содержимого – изменения стиля (жирный,
наклонный,
подчёркнутый),
выравнивания,
отступа,
шрифта,
создания
размера,
маркированного
и
немаркированного списков, а также вставки и удаления
картинок и гиперссылок. Под редактором находятся две
кнопки – Изменить и Отмена для сохранения и отмены
изменений соответственно. Также рядом с кнопками
находится флажок “Изменить все похожие элементы на
сайте” для того чтобы пользователь мог определить
текущий редактируемый элемент как общий.
Результаты Выбранный блок доступен для редактирования.
Замечания
Блокировка страницы осуществляется обычным для оконных
приложений способом: окно редактора переводится в т.н.
модальный режим, при котором всё, что находится снаружи
окна, затеняется. При попытке пользователя обратиться к
затенённой области заголовок модального окна мигает, что
означает, что это окно необходимо закрыть, прежде чем
обращаться
к
заблокированному
содержимому.
Для того чтобы пользователю было легче выбрать нужный
элемент для редактирования, при перемещении указателя
текущий элемент должен выделятся цветом или бордюром.
Изменение элемента страницы
Таблица 3
Описание
Пользователь изменяет текст выбранного элемента.
Условия
Пользователь выбрал элемент для редактирования.
Событие
Нажата кнопка Изменить в редакторе.
1.
Порядок
Изменяется содержимое редактируемого элемента на
выполнения
странице.
2.
Закрывается окно редактора.
3.
Снимается блокировка страницы.
Результаты Пользователь
изменил
содержимое
выбранного
элемента.
Появилась возможность редактировать другую информацию на
странице.
Замечания
Если выбран флажок “Изменить все похожие элементы на
сайте”, то на шаге
также изменяется содержимое всех
элементов страницы, которые имели такое же содержимое, какое
было у выбранного элемента до начала редактирования.
При нажатии кнопки Отмена в редакторе выполняются только
шаги 2-3.
Сохранение изменений
Таблица 4
Описание
Пользователь сохраняет все изменения на странице.
Условия
Страница находится в режиме редактирования.
Событие
Нажатие на иконку Сохранить в правом нижнем углу экрана.
1.
^
Порядок
выполнения
Все активные элементы страницы, которые выделены для
редактирования, снимают выделение.
2.
Скрываются кнопки Сохранить и Отмена в левом нижнем
углу экрана.
3.
Пользователю сообщается о начале процесса сохранения.
4.
Вся информация страницы сохраняется на сервере.
5.
Пользователю сообщается о статусе сохранения. Если при
сохранении произошли какие-либо ошибки, и страница не
сохранена, показывается соответствующее уведомление.
Результаты Все изменения на странице сохранились и стали видны
посетителям сайта; страница вернулась в режим просмотра.
Замечания
В дальнейшем неплохо было бы сделать контроль изменений
для каждой страницы с целью фиксировать все изменения и
иметь возможность отката после сохранения страницы.
Отмена изменений
Таблица 5
Описание
Содержимое возвращается к исходному варианту.
Условия
Страница находится в режиме редактирования.
Событие
Нажатие на иконку Отмена в правом нижнем углу экрана.
1.
^
Порядок
Все активные элементы страницы, которые выделены для
выполнения
редактирования, снимают выделение.
2.
Скрываются кнопки Сохранить и Отмена в левом нижнем
углу экрана.
3.
Восстанавливается вся информация на странице, какая
была на момент начала редактирования.
Результаты Все изменения на странице отменены; страница вернулась в
режим просмотра.
Замечания
Для того чтобы ещё раз изменить содержимое страницы,
пользователю понадобится повторить действия из п. 5.2.
2.
Администраторы системы
Вход в систему
Таблица 6
Описание
Вход администратора в область администрирования
Событие
Переход на специальный адрес контент-сервера
1.
Порядок
Ввод имени пользователя и пароля
выполнения
2.
Посылка данных на сервер.
3.
Показ домашней страницы области администрирования.
Результаты Администратору предоставляется меню для управления списком
редакторов и просмотра изменений
Регистрация нового пользователя
Таблица 7
Описание
Администратор создаёт новую учётную запись пользователя
Событие
Выбор
команды
“Создать
учётную
запись”
в
списке
пользователей
1.
Порядок
выполнения
Ввод имени пользователя и пароля.
2.
Ввод контактных данных нового пользователя.
3.
Указание адресов сайтов, к которым новый пользователь
будет иметь доступ.
4.
Посылка данных на сервер.
Результаты В системе создаётся новая учётная запись. При этом посылается
оповещение на указанный email-адрес.
Замечания
Чтобы пользователь не ошибся при вводе пароля, необходимо
иметь поле для повторного ввода.
Изменение учётной записи пользователя
Описание
Таблица 8
Изменение пароля, контактной информации либо списка
доступных сайтов для зарегистрированного пользователя.
Событие
Выбор
команды
“Изменить
учётную
запись”
пользователей.
^
Порядок
Изменение соответствующей информации.
выполнения
Результаты Обновление учётной записи.
в
списке
Замечания
Те же, что и при регистрации нового пользователя.
Удаление пользователя
Таблица. 9
Описание
Удаление учётной записи пользователя
Событие
Выбор
команды
“Удалить
учётную
запись”
в
списке
пользователей.
Результаты Учётная запись удалена полностью.
Просмотр изменений
Таблица 0
Описание
Показ списка изменений с возможностью фильтрации по дате
Событие
Выбор
пункта
меню
“Просмотр
изменений”
в
области
администрирования
1.
Порядок
Выбор периода, за который следует показать информацию
выполнения
об изменениях.
2.
Выбор редактора, который произвёл изменения.
3.
Выбор из списка по дате и времени
Результаты Администратору показывается код страницы до и после
редактирования вместе с комментариями, которые оставил
редактор.
Замечания
Если редактор не выбран, то в списке должны быть отображены
все изменения за указанный период.
ГЛАВА 3. ОСНОВНЫЕ ОГРАНИЧЕНИЯ
3.1. DOM интерфейс
Существует несколько технических ограничений, которые были
выявлены при создании прототипа системы. Эти ограничения в основном
связаны с существующим на данный момент способом обработки вебстраниц браузерами. Так как ограничения носят технический характер, то
вполне возможно, что все они будут преодолены в следующих версиях
системы.
Прежде чем переходить к описанию ограничений, следует сказать, что
основной и единственный инструмент, который позволяет системе изменять
содержимое страницы – т.н. DOM (Document Object Model) интерфейс. Он
позволяет
представить
страницу
как
дерево,
содержащее
элементы
оформления и текст. Это дерево строится браузером, после того, как он
получит и обработает HTML-код с сервера.
3.2 Различия браузеров
В разных браузерах DOM-дерево может быть различным. Это может
быть результатом следующего:
Сервер генерирует содержимое страницы в зависимости от модели
браузера. При каждом запросе браузер посылает подробную информацию,
включающую название и
версию.
Сервер может использовать
эту
информацию, например, для генерации HTML-кода, оптимизированного под
конкретную модель браузера.
В широко распространённом браузере Microsoft Internet Explorer 6
содержимое страницы может быть изменено уже на клиенте, в результате
работы так называемых HTC-скриптов, которые не поддерживаются
остальными браузерами. Такие скрипты используются, например, для
корректного показа PNG-изображений, имеющих альфа-канал.
Браузеры
по-разному
обрабатывают
неправильно
оформленный
HTML-код. В результате такой обработки могут получиться различные
DOM-деревья для одной и той же страницы в разных браузерах.
Первый
вариант, при
котором
сервер
генерирует
содержимое
страницы, в зависимости от модели браузера довольно редко встречается на
реальных web-сайтах. В основном это может касаться решения проблемы с
PNG-изображениями, имеющими альфа-канал, описанной во втором пункте.
В этом случае структура DOM-дерева существенно не меняется, изменяются
только атрибуты элементов (IMG в примере), что не препятствует
идентификации этих элементов, т.к. их содержимое и абсолютный путь
остаются те же. Остальные случаи следует принять как исключительные, при
которых система действительно может работать не так, как планируется. В
силу крайней редкости таких ситуаций, их стоит отнести за рамки данной
системы.
В случае применения HTC-скриптов, используемых для корректного
показа PNG-изображений с альфа-каналом, DOM-дерево также не меняется,
как сказано выше. Остальные случаи работы HTC-скриптов следует также
отнести в разряд исключительных, т.к. их применение ограничено одним
браузером.
Случаи с неправильно оформленным HTML-кодом в большинстве
сводятся к отсутствию закрывающего тега у элементов страницы. В этом
случае наиболее распространённые браузеры, такие как Mozilla Firefox и
Microsoft
Internet
Explorer
поступают
одинаковым
образом
–
они
автоматически добавляют закрывающий тег и помещают все последующие
элементы внутрь данного элемента. Таким образом, в большинстве случаев
DOM-дерево будет одинаковым.
3.3 Динамические элементы
Сайт может иметь элементы, которые создаются динамически в
зависимости от каких-либо условий. Например, динамические списки
новостей, наполняемые информацией из базы данных. У внешней системы
управления содержимым нет контроля над источником этой информации
(предполагается, что об источниках информации для сайта ничего не
известно). Поэтому при редактировании таких элементов могут возникнуть
коллизии. На примере может произойти следующее: пользователь изменил
элемент списка новостей визуально в редакторе, и в тоже время обновил
информацию в БД. При этом возникает проблема: какие изменения принять?
Эта проблема на данный момент не имеет решения. Предполагается,
что если сайт имеет какие-либо источники информации помимо системы
управления
инструмента
содержимым,
для
то
изменения
пользователь
этой
ответственен
информации,
и
ему
за
выбор
просто
не
рекомендуется изменять одну и ту же информацию двумя разными
способами.
3.4 Поисковые системы
Данный пункт относится только к прототипу, в котором функция
замены
содержимого
была
реализована
на
клиенте.
Проблема
с
индексированием страниц в нём была частично решена, как написано ниже,
но новый подход с переносом функции замены содержимого на сервер
позволил полностью избавиться от этой проблемы.
Страницы с отдельно хранимым содержимым, которое заменяется при
открытии, не могут быть проиндексированы поисковыми роботами. В случае
если последние при индексации обнаружат перенаправление с одной
страницы на другую (например, с адреса содержимого на адрес страницы,
содержащей текст), поисковые системы автоматически заносят страницу в
чёрный список. В таком случае страница не сможет быть найдена с помощью
данной поисковой системы.
Для решения проблемы индексации используется специальная ссылка,
добавляемая на страницу, которую необходимо проиндексировать, сразу при
установке системы. Эта ссылка имеет определённый адрес, ведущий на
сервер содержимого (content-сервер), который может быть установлен там
же, где и основной сайт. Поисковая система, индексирующая страницу с
такой ссылкой, должна проиндексировать содержимое, хранящееся на
content-сервере. Далее, при поиске, поисковая система должна направлять
пользователей на адрес сервера содержимого. Сервер содержимого же
должен представлять информацию, а также ссылку на страницу, информация
которой была представлена. При этом пользователя необходимо уведомить о
том, что он просматривает не искомую страницу, а лишь часть содержимого
этой страницы, и что полная информация представлена на оригинальной
странице.
3.5 Архитектура программного средства
Как и большинство веб-приложений, система управления содержимым
сайтов (CMS) имеет архитектуру клиент-сервер. Серверная часть системы
имеет доступ к базе данных, и выполняет функции обработки и хранения
данных приложения. Клиентская часть системы это набор программных
модулей, исполняемых на странице сайта.
Рисунок 5.Схема взаимодействия частей приложения.
Принцип работы всего приложения выглядит следующим образом. При
обращении к странице сайта запрос перенаправляется на CMS сервер,
который в данном случае используется как своего рода прокси-сервер. CMS
сервер получает оригинальное содержимое сайта, обрабатывает его,
вставляет новую информацию, которая была изменена пользователем, и
возвращает
содержимое
клиенту
(браузеру).
При
вставке
нового
содержимого content-сервер также добавляет специальный программный
модуль, исполняемый на клиенте. Этот программный модуль создаёт на
странице функционал, необходимый для редактирования и последующей
замены
содержимого.
Также
этот
модуль
может
осуществлять
дополнительные действия, например, регулярно опрашивать сервер об
изменениях.
Рисунок 5.2. Схема работы приложения.
В итоге программный модуль, выполняемый на странице сайта,
реализует несколько функций. Какие-то из этих функций имеют наибольший
приоритет, и должны выполниться в первую очередь. Остальные функции
могут зависеть от результатов её выполнения. Между собой функции
практически не связаны. Поэтому весь программный модуль спроектирован
так, чтобы максимально разделить выполняемые функции, и осуществить
возможность изменять и дополнять набор этих функций. Для этого
использовано понятие общая шина данных (Data Bus), и взаимодействие всех
функции, включая ядро системы, организовано посредством этой шины
(рис.5.3). Работа с шиной представляется в виде подписки и публикации
событий, которые происходят в системе. Функция-подписчик определяет
набор событий, на которые она реагирует. Все функции, включая ядро
системы, могут публиковать свои события для их обработки другими
функциями. Таким образом, организовано событийное управление всей
клиентской частью приложения в целом.
Рисунок 5.3. Схема взаимодействия посредством общей шины данных.
В качестве первого этапа работы над проектом был создан прототип
системы, который включает следующие функции:
Изменение содержимого на отдельной странице сайта. Пользователю
предоставляется возможность изменить любой выбранный им элемент
страницы. При этом все изменения видны сразу и нет необходимости
перезагружать страницу или иметь функцию предварительного просмотра.
Для
редактирования
информации
используются
стандартные
компоненты, позволяющие изменять стиль текста (жирный, наклонный,
подчёркнутый),
шрифт,
размер,
выравнивание,
отступ,
создание
маркированного и немаркированного списков, а также вставки и удаления
картинок и гиперссылок.
Общие элементы страниц, такие как меню, верхняя и нижняя часть,
рассматриваются как один элемент, и редактируются один раз. Таким
образом, если пользователь изменит один из общих элементов на одной
странице, изменения затронут все страницы, содержащие этот элемент.
Показ изменений для посетителей сайта. После того как пользователь
(редактор)
изменит
содержимое
страницы,
и
сохранит
изменения,
обновлённая версия страницы незамедлительно становится доступной
посетителям сайта.
При реализации прототипа функция замены содержимого была
перенесена на клиентскую часть, что имеет свои достоинства и недостатки. В
рамках дипломной работы был предложен другой вариант реализации.
Сравнение двух вариантов реализации приведено в таблице . Из очевидных
плюсов нового подхода стоит выделить перенос вычислительных затрат с
клиента
на
сервер,
распараллеливания
возможность
вычислений,
кэширования
отсутствие
проблемы
результатов
с
и
поисковыми
системами и обычная с точки зрения посетителя работа сайта. Явным
минусом является доставка содержимого клиенту посредством контентсервера, а не напрямую.
ГЛАВА 4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
4.1 Реализация клиентской части
Клиентская часть реализована на языке JavaScript в виде набора
классов, распределённых по т.н. пакетам. Сам язык является объектноориентированным, но не поддерживает классы как таковые, так же как и
механизм наследования. Вместо этого в языке поддерживается прототипориентированный
подход,
неудобный
по
многим
причинам.
Для
осуществления класс-ориентированного подхода в проекте используется
специальный инструмент, преобразующий конструкции языка, используя
регулярные выражения. Этот подход позволяет создавать классы, объединять
их в пакеты, и наследовать классы од других.
Все классы приложения разбиты по нескольким вложенным пакетам.
Класс CmsApplication, представляющий собой ядро системы, вынесен в
корневой пакет cms. Классы, реализующие работу с общей шиной данных,
вынесены в пакет cms.events. Остальные функции системы, реализованные в
виде встраиваемых модулей (plug-in), находятся в пакете cms.plugins:
Пакет cms.plugins.auth содержит классы, реализующие механизм
аутентификации пользователя.
Пакет
cms.plugins.editor
содержит
классы,
реализующие
функцию
редактирования содержимого страницы.
4.2.Реализация серверной части
Серверная часть реализована в виде постоянно работающего сервиса,
принимающего
запросы
от
посетителей
сайтов,
и
возвращающего
содержимое после обработки. Также реализован отдельный сервис для
сохранения изменений, которые присылает клиентская часть.
Для оптимизации работы сервиса реализован кеш на диске, в котором
хранится содержимое сайтов с проведенными изменениями. Этот кеш
формируется при первом запросе к содержимому сайта, после этого
содержимое извлекается непосредственно из него.
Отдельная часть приложения обеспечивает функционал для управления
системой в целом. Здесь реализовано рабочее место администратора
системы.
4.3. Идентификация элементов
После того, как пользователь изменит содержимое отдельного элемента
DOM-дерева, необходимо отображать эти изменения при новом открытии
страницы. Для этого требуется однозначно идентифицировать элемент
страницы, который был отредактирован. Проблема состоит в том, что
страница может иметь несколько элементов, похожих друг на друга. Таким
образом, в DOM-дереве могут быть несколько совершенно одинаковых
поддеревьев, которые необходимо однозначно идентифицировать.
Ко всему этому, один сайт может состоять из нескольких страниц, на
каждой из которых могут быть одинаковые элементы, например, меню. Эти
элементы должны быть не только однозначно идентифицированы, но и
“распознаны” как общие элементы сайта, чтобы их изменение на одной
странице повлекло автоматическое на всех других страницах сайта.
Для идентификации таких поддеревьев в одном дереве страницы,
необходимо использовать информацию об остальной структуре страницы,
абсолютному пути от корня дерева, или положение поддерева относительно
других поддеревьев
Решение заключается в следующем. Каждый редактируемый элемент
дерева может быть идентифицирован двумя способами: путём запоминания
абсолютного пути из корня дерева и подсчётом значения хеш-функции от
содержимого этого элемента. Последний вариант помогает решить проблему
с идентификацией одинаковых элементов. Например, если на странице есть
два или более элементов с одинаковым содержимым, то они будут иметь
одинаковое значение хеш-функции. После загрузки страницы содержимое
всех подобных элементов может быть заменено, используя эти значения.
Для тех элементов, содержимое которых встречается в других
элементах, но подобная замена не требуется, используется абсолютный путь
из
корня
дерева
идентифицировать
как
данный
дополнительная
элемент.
Этот
информация,
путь
помогающая
состоит
из
пар
(Название_Вершины, Номер_Вершины), где Название_Вершины - это
название тега, и Номер_Вершины - это порядковый номер в списке всех
вершин с таким названием на одном уровне DOM-дерева. Например, путь
может выглядеть так: (‘body’,0), (‘table’,0), (‘tbody’,0), (‘tr’, 2), (‘td’, ), (‘a’,0).
Существует также проблема в том, что на странице сайта могут
присутствовать элементы, созданные с помощью JavaScript. Изменение
такого элемента требует изменения не HTML-кода страницы, а JavaScriptкода, находящегося на странице, что является достаточно трудным.
Чтобы решить эту проблему, каждый элемент сайта во время генерации
страницы на сервере помечается специальной меткой, по которой можно
определить, что данный элемент присутствует в HTML-коде. Далее
элементы, которые не имеют такой метки (элементы, созданные с помощью
JavaScript), редактируются и сохраняются особенным образом. Изменения
при этом не затрагивают HTML-код, и применяются отдельно, после
загрузки всей страницы.
ГЛАВА 5. ИНСТРУМЕНТЫ И ПРОГРАММНЫЕ СРЕДСТВА
5.1 Инструменты.
Enterprise Java Beans 3
В реализации серверной части приложения используется технология
Enterprise JavaBeans, 3rd Edition. Эта технология является частью платформы
Java Enterprise Edition и предназначена для создания и поддержки серверных
компонент, содержащих бизнес-логику на языке Java. Третья версия
спецификации в отличие от предыдущих версий признана Java-сообществом
как
наиболее
удобная
для
использования.
Сам язык Java был выбран из-за его особенностей, таких как широкая
поддержка
объектно-ориентированного
программирования
и
строгая
типизация, а также большого количества готовых библиотек, в том числе для
разбора и генерации HTML. Также вместе с языком поставляется
инструментарий
для мониторинга производительности системы, Java
Management
Extensions.
В общем и целом выбор языка Java и технологии EJB3 обусловлен
необходимостью стабильной и высокопроизводительной работы серверной
части. Это является критической частью системы, так как при нестабильной
работе посетители не будут иметь возможность получить информацию с
сайта.
Apache Geronimo
Сервер приложений с открытым исходным кодом, поддерживающий
технологию Enterprise Java Beans 3 и имеющий в составе контейнер для вебприложений Apache Tomcat.
JavaScript
Для реализации клиентской части приложения, выполняемой на
странице сайта, выбран язык JavaScript. JavaScript является универсальным
языком для написания сценариев, выполняемых на веб-страницах. Он
доступен практически в любом современном браузере без необходимости
установки каких-либо дополнительных средств. Таким образом, приложение,
реализованное на языке JavaScript, доступно большинству людей, имеющих
доступ к Интернету.
JavaScript является прототип-ориентированным языком. Это означает,
что в нём нет такого понятия как класс. Все сложные объекты создаются
путём копирования свойств и методов объекта-прототипа. Такой подход в
объектно-ориентированном программировании не удобен тем, что исключает
стандартный механизм наследования. Поэтому в проекте используется своего
рода расширение языка, позволяющее создавать свои классы, пакеты
классов,
и
поддерживающее
механизм
наследования.
Для взаимодействия клиентской и серверной части используется механизм
асинхронной передачи данных AJAX (Asynchronous JavaScript and XML).
MySQL
MySQL на данный момент является одной из наиболее широко
используемых СУБД для работы малых и средних веб-приложений.
Программное обеспечение для этой СУБД, как и она сама, свободно
распространяется. Как инструмент работы с базой данных MySQL сочетает
простоту и необходимую функциональность.
5.2 Системные требования
Сервер
Для
работы
программного
обеспечения
требуется
сервер
c
установленными программными компонентами:
1. Apache Geronimo v2
2. Java EE 5
3. MySQL 5
Клиент
Для работы с CMS-клиентом нужен браузер Mozilla Firefox версии 3.0
или выше.
О Движках
JOOMLA
Joomla! (произносится джу́мла) — система управления
содержимым (CMS), написанная на языках PHP и JavaScript, использующая в
качестве хранилища базы данных СУБД MySQL или другие индустриальностандартные реляционные СУБД. Является свободным программным
обеспечением, распространяемым под лицензией GNU GPL.
Система управления содержимым Joomla! является ответвлением
широко известной CMS Mambo. Команда независимых разработчиков
отделилась от проекта Mambo по причине несогласия в экономической
политике. 16 сентября 2005 года в свет вышла первая версия Joomla!,
являющаяся по сути переименованной Mambo 4.5.2.3 и включающая в себя
исправления найденных на тот момент ошибок и уязвимостей.
К лету 2008 года по числу ежедневных скачиваний Joomla! заняла
второе место после WordPress со значительным отрывом от других подобных
систем.[3]

Версия 1.0 считается устаревшей, её официальная поддержка прекращена
1 июля 2009 года.

Поддержка версии 1.6 прекращена 19 августа 2011 года.

Поддержка версии 1.7 прекращена 24 февраля 2012 года.[4]

Поддержка версии 1.5 прекращена 27 сентября 2012 года.
Текущая версия системы — 2.5.х, выпуск которой состоялся в начале
февраля 2012 г. Тестовая версия системы — 3.0.х, выпуск которой состоялся
27 сентября 2012 г.
CMS Joomla! включает в себя различные инструменты для разработки
веб-сайта. Важной особенностью системы является минимальный набор
инструментов при начальной установке, который дополняется по мере
необходимости. Это снижает загромождение административной панели
ненужными элементами, а также снижает нагрузку на сервер и экономит
место на хостинге.
Joomla! позволяет отображать интерфейс фронтальной и
административной части на любом языке. Каталог расширений содержит
множество языковых пакетов,[5] которые устанавливаются штатными
средствами администрирования. Доступны пакеты русского, украинского,
белорусского и ещё некоторых языков стран СНГ.

Функциональность можно увеличивать с помощью дополнительных
расширений (компонентов, модулей и плагинов).

Имеется модуль безопасности для многоуровневой аутентификации
пользователей и администраторов (используется собственный алгоритм
аутентификации и «ведения» сессий).

Система шаблонов позволяет легко изменять внешний вид сайта или
создать свой уникальный. В сети существует огромный выбор готовых
шаблонов, как платных, так и бесплатных.

Предусмотрены настраиваемые схемы расположения модулей, включая
левый, правый, центральный и любое другое произвольное положения
блока. При желании содержимое модуля можно включить в содержимое
материала. Например, выражение {loadposition mod_fpslideshow}
введенное (вместе с фигурными скобками) в произвольное место в статье
выведет содержимое модуля, которому задана позиция вывода как
«mod_fpslideshow».

К преимуществам системы можно отнести то, что все компоненты,
модули, плагины и шаблоны можно написать самому, разместить их в
структурированном каталоге расширений или отредактировать
существующее расширение по своему усмотрению.

Происходит регулярный выход обновлений. Существует публичный «багтрекер» (система отслеживания ошибок). (См.список официальных
трекеров.) Существуют также трекеры миграции со старых версий Joomla,
трекер пожеланий расширения функционала и так далее, где пользователи
Joomla могут оставлять замечания по поводу работы CMS, которые
впоследствии изучаются её разработчиками, при необходимости
включающими в очередное обновление Joomla исправления, решающие те
или иные проблемы.

Начиная с версии 1.6 встроена многоязычность.

Начиная с версии 2.5 расширена поддержка баз данных. Реализована
поддержка Microsoft SQL Server, а с версии 3.0 — PostgreSQL[6]. В
дальнейшем планируется добавить поддержку Oracle, SQLite.
WORDPRESS
WordPress — система
управления
содержимым сайта
с открытым
исходным кодом, распространяемая под GNU GPL. Написана на PHP, в
качестве базы данных использует MySQL. Сфера применения — от блогов до
достаточно сложных новостных ресурсов и интернет-магазинов. Встроенная
система «тем» и «плагинов» вместе с удачной архитектурой позволяет
конструировать практически любые проекты. WordPress выпущен под
лицензией GPL версии 2.
12 июня 2001 года Мишель Вальдриги начал разработку движка b2,
впоследствии к проекту присоединились Мэтт Мюлленвег ruen и Майк
Литтл[2]. В январе 2003 года Вальдриги прекратил разработку[3], поэтому
автором WordPress считается Мэтт Мюлленвег, ему же принадлежат права на
товарную марку «WordPress»[4].
В 2003 году компания CNET стала использовать WordPress для своих
проектов. Мюлленвег встречался с вице-президентом компании и принял
предложение о сотрудничестве. В 2005 году он ушел из CNET, основал
Аutomattic и посвятил себя разработке проектов на движке WordPress.
JIMDO
Jimdo — конструктор сайтов, созданный в 2004 году 3 основателями
Кристианом (Christian Springub), Фридтьёфом (Fridtjof Detzner) и Маттиасом
(Matthias Henze).
Jimdo предлагает пользователям создать собственный сайт за несколько
минут. Пользователю доступны: 11 языковых версий, загрузка картинок,
flash-
и
html-галереи,
комментарии,
загрузка youtube-видео,
интеграция
блог,
с социальными
гостевая
книга,
сетями,
например, Вконтакте, Twitter, Facebook, интернет-магазин. Подробнее о всех
функциях конструктора можно узнать в онлайн-помощи или видео-туре
Jimdo. Сайт на Jimdo может создать любой пользователь, в том числе и не
имеющий навыков программирования. Jimdo предлагает 3 пакета: Jimdo Free,
Jimdo Pro и JimdoBusiness. Jimdo Free - бесплатная версия конструктора.
Отлично подходит для начинающих интернет-пользователей. Преимущества:
пользование конструктором бесплатно, включает в себя 500 МБ памяти,
разнообразные шаблоны, интернет-магазин с 5 товарами, блог, гостевую
книгу, галереи и т.д. Недостатки: реклама компании Jimdo на сайте,
отсутствие почты, домена и единственный способ оплаты в интернетмагазине - Paypal. Jimdo Pro - платная версия, стоимость 60 евро в год
(приблизительно
2400
рублей
для
жителей
РФ).
Преимущества:
собственный домен и Email-адрес, 15 товаров в магазине, нет рекламы Jimdo,
более быстрая тех. поддержка. Jimdo Business - платная версия, стоимость
пакета 180 евро в год (приблизительно 6000 рублей для жителей РФ).
Преимущества: 2 собственных домена и возможность создать 20 Emailадресов, ответы службы тех. поддержки в течение суток и неограниченное
количество товаров в интернет магазине.
ЗАКЛЮЧЕНИЕ
В процессе дипломной работы удалось выполнить необходимый
объём
работ,
конкретно
было
сделано
следующее:
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
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/HA
007504 049.aspx.
7.
Сайт Drupal. http://drupal.org/.
8.
Сайт TYPO3 Association. http://www.typo3.com/.
9.
Сайт С-Битрикс. http://www. c-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. 997.
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 (
999). Prototype-Based Programming: Concepts, Languages and Applications.
Springer-Verlag.