Создание web-приложения "Виртуальный музей"

дипломная работа

3.1 Реализация основного функционала подсистемы

Начать стоит с т. н. разводной страницы, являющейся своеобразным начальным пунктом (см. рис. 3.1), из которого посетитель сможет перейти на одну из экспозиций или войти в специальную панель администрирования, в которой присутствует функционал управления содержимым виртуального музея. Каждая экспозиция здесь представлена в виде плитки с некоторым изображением, которое может дать первое представление о том, о чем данная экспозиция может рассказывать. Генерацию этих плиток берет на себя подсистема. Отсутствие непосредственного сцепления плитки с местом на странице дает множество вариантов динамической генерации содержимого разводной страницы: первыми можно выводить новейшие экспозиции или сортировать их расположение по любому другому критерию.

Для того, чтобы получить доступ к панели администрирования необходимо иметь логин и пароль от подсистемы (см. рис.3.2). Это обусловлено тем, что данная панель дает доступ непосредственно к хранилищу данных, содержимое которого и предоставляется для просмотра на страницах Виртуального музея. Доступом к этой панели должны обладать только музейные работники, которые и будут управлять всем имеющимся содержимым. Управляющие элементы данной формы авторизации создаются самим браузером. Управление учетными записями пользователя возложено, согласно диаграмме прецедентов, на системного администратора сервера приложений, на котором работает Виртуальный музей.

Рисунок 3.1 Разводная страница виртуального музея (динамическая часть)

Рисунок 3.2 Форма авторизации

Нажимая на плитку одной из экспозиций, посетитель попадает на страницу этой экспозиции, причем эта страница каждый раз генерируется заново и нигде не хранится в жестком закодированном виде. Генерация осуществляется с помощью шаблона, который определяет всю разметку страницы, начиная с контейнера содержимого "content".

Шаблон представляет из себя текстовый файл, похожий на формат XML, но с небольшим отличием. Он может иметь специальный тег "frame" с обязательным атрибутом "name", который будет восприниматься системой как место для замены тега конкретной реализацией. Пример шаблона можно увидеть ниже (см. рис. 3.3).

Рисунок 3.3 Пример шаблона

Встретив такой тег, система запомнит его и все его атрибуты в памяти, а затем, когда шаблон будет применен к какой-либо сущности (Экспозиция, Артефакт) подсистема будет просматривать фреймы, которые имеет сущность и вставлять их на место в шаблоне. Вставка будет осуществляться при совпадении атрибутов тега "name" из шаблона и сущности. Если фрейм с именем, описанным в шаблоне, в сущности будет не найден, подсистема на месте этого фрейма выведет сообщение об его отсутствии, или любое другое сообщение, которое будет реализовано на соответствующее событие в классе фрейма подсистемы. Это говорит о том, что сущность должна реализовывать абсолютно все фреймы, описанные в шаблоне, для корректного отображения. Такое поведение также присутствует в механизме работы интерфейсов языков программирования. Сама реализация фрейма подсистему абсолютно не волнует, и она отобразит именно то, что описано в реализации конкретного фрейма, находящегося в отображаемой сущности (см. рис. 3.4).

Рисунок 3.4 Пример отсутствующего фрейма

Результатом работы подсистемы будет сгенерированная страница, заполненная содержимым некоторого объекта (см. рис.3.5). Код функции замены тегов шаблона на конкретную реализацию фрейма представлен в Приложении 2.

Рисунок 3.5 Пример заполнения шаблона

Как видно из примера, некоторые фреймы были найдены в отображаемом объекте (intro, outro, image) и были заменены конкретной реализацией. Более того, атрибуты фреймов, в частности атрибут "alt", также был перенесен в реализацию помимо самого изображения. Однако, можно заметить, что некоторые фреймы не смогли найти реализации в данном объекте, о чем они проинформировали выведением сообщения об отсутствующем фрейме. Способов решения данной проблемы два: применение другого шаблона для отображения объекта, либо редактирование содержания этого объекта путем добавления нереализованных фреймов, описанных в шаблоне.

Помимо главного функционала необходимо было предоставить возможность сотрудникам Виртуального музея управлять его содержимым прямо внутри браузера. Для этой цели была разработана специальная административная панель, которая выводит на страницу все содержимое музея и позволяет совершать над ним CRUD-операции. Список артефактов музея можно увидеть ниже (см. рис. 3.6).

Рисунок 3.6 Список артефактов музея

Для того, чтобы артефакты можно было использовать в каких-либо экспозициях, их необходимо вставлять во фреймы. Для этого необходимо создать фрейм, содержимым которого и будет желаемый артефакт или артефакты (см. рис. 3.7).

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

Рисунок 3.7 Создание нового фрейма

После того, как необходимые фреймы были созданы, можно приступать к созданию экспозиции (см. рис. 3.8). Данный процесс напоминает сбор "лего" по кусочкам Музейный работник должен сразу же выбрать шаблон, который будет использоваться подсистемой для генерации веб-страницы новой экспозиции. Сами шаблоны хранятся в файловой системе сервера приложений. Подсистема находит их по ссылкам, которые хранятся в базе данных, и выводит их в виде выпадающего списка.

Рисунок 3.8 Добавление новой экспозиции

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

Рисунок 3.9 Пустой шаблон экспозиции

Также на этапе проектирования было выявлено требование, которое говорило о том, что подсистема должна поддерживать процесс импорта новых шаблонов. Данный функционал также был реализован на панели администрирования рядом со списком всех имеющихся в подсистеме шаблонов (см. рис. 3.10). Для выполнения этого действия необходимо выбрать нужный шаблон и ввести его описание (для каких типов экспозиций планируется применять данный шаблон, к примеру). После нажатия на кнопку "загрузить" произойдет закачивание файла шаблона на сервер приложений. Действие может закончиться неудачно, если размер выбранного файла превысит максимально допустимый размер, оговоренный в частном техническом задании (3МБ). Возможность выбора файлов некорректного формата исключается путем использования маски формата при выборе файла из файловой системы, однако есть вероятность, что даже при правильном формате содержимое выбранного файла может не соответствовать синтаксическим правилам (отсутствие закрывающих тегов там, где они должны быть, к примеру), что приведет к выводу ошибки при разборе файла.

Рисунок 3.10. Импорт шаблонов

Делись добром ;)