Общий вид архитектуры приложения с использованием RESTfull API отражен на рисунке 4.1
Рис4.1 – Клиент-серверное приложение, разработанное с использованием RESTfull API
Как на клиенте, так и на сервере имеется авторизация с возможностью ручного добавления пользователей в систему. Это необходимо для разделения прав между авторизованными и неавторизованными пользователями, а так же для разграничения прав между пользователями в пределах сисемы и проекта. К примеру, в дальнейшем это позволит создать роли “Администратор системы”, “Администратор проекта”, “Разработчик”. И все эти роли будут использовать данную систему авторизации для определения прав.
Рассмотрим пользовательский интерфей системы и его возможности. На программной реализации остановимся позднее.
Главная страница нашей системы выглядит так, как показано на рисунке 1
Рис 4.2 – Главная страница системы
На ней можно заметить панель инструментов, расположенную сверху. Данная панель доступна в пределах всего приложения. С помощью нее осуществляется навигация по следующим разделам:
- Проекты Теги Главная страница
В процессе проектирования пользовательского интерфейса данное разделение было выбрано с учетом того, что теги не принадлежат конкретному проекту, т. е. отношение между сущностями Теги -> Проекты многие ко многим. Данный вопрос будет подробнее освещен ниже при рассмотрении схемы базы данных.
В средней части главное страницы можно увидеть приветственное сообщение для пользователя. В данной области так же имеется кнопка, которая позволяет перейти на список проектов текущего пользователя.
Так же на панели инструментов, в крайней правой части, доступна ссылка для авторизации пользователя. При нажатии на данную ссылку пользователь переходит на страницу авторизации, где в качестве данных для авторизации используется адрес электронной почты и пароль. Все данные о пользователе вносятся вручную администратором базы данных. Внешний вид формы для авторизации предоставлен на рисунке 4.3.
Рис.4.3 – Внешний вид формы авторизации
После ввода корректных регистрационных данных пользователь перенаправляется на список проектов текущего пользователя. В случае неуспешной авторизации пользователю выдается соответствующее сообщение об ошибке и пользователь остается на странице авторизации. Расмотрим подробнее страницы, отвечающие за просмотр и редактирование списка проектов
Как уже было сказано, после успешной авторизации пользователь попадает на страницу со списком проектов. Заметим так же, что пользователю показываются проекты, которые принадлежат только ему. Это позволяет использовать базовые механизмы защиты.
Список проектов представляет собой таблицу, в которой в каждой строке имеется краткая информация о каждом проекте: ID, название, дата создания. Внешний вид списка проектов представлен на рисунке 4.4.
Рис. 4.4 – Внешний вид списка проектов
Как можно заметить, имеется возможность перейти по ссылке при клике на поле ID соответствующего проекта. При этом пользователь переходит на список задач, который относится к текущей задачи. Над таблицей имеется ссылка “Создать проект”, которая ведет на форму создания проекта.
В таблице “Список проектов” доступна краткая информация о проекте. Для получения более подробной информации, как уже было сказано, можно перейти по ссылке, которая находится в поле ID соответствующего проекта. При этом откроется карточка проекта, которая выглядит так, как показано на рисунке 4.5
Рис.4.5 – Внешний вид окна карточки проекта
В данной карточке, помимо названия и ID, указана так же дата создания проекта. Данные представлены в табличном виде. Так же имеется возможность перейти на список список задач, привязанных к данному проекту, посредством клика на ссылку “Список задач”.
Привязка проекта и задач к определенному пользователю осуществляется за счет вложеных url (nested routes). То есть, ссылки, представленные выше при описании RESTfull API дополняются, например, информацией о текущем пользователе или текущем проекте. Например, создание задачи, привязанной к определенному проекту, доступне по ссылке следующего вида:
POST /projects/:projectid/tasks
где :projectid - это уникальный идентификатор искомого проекта. Таким же образом создаются другие вложенные сущности в проекте.
Рассмотрим подробнее форму для создания проекта. Она представлена на рисунке 4.6
Рис. 4.6 – Внешний вид формы для создания проекта
Как можно заметить, форма достаточно простая, состоит всего из названия. Данные пользователя подставляются автоматически, основываясь на данных из сессии. Для названия проекта используется проверка на минимальную и максимальную длину в названии проекта. При успешном прохождении проверки и успешном добавлении пользователь перенаправляется обратно на форму со списком проектов.
Еще одной немаловажной сущностью приложения являются теги. Они позволяют добавлять к задачам определённые пометки, которые тем или иным образом характеризуют проект. Например, к задаче можно добавить тег “Критичный”, “Ядро”. И тем самым пользователь может сделать какие-то выводы без вникания в саму суть задачи.
В интерфейсе нашего приложения есть доступ к списку тегов. Теги доступны при клике по ссылке “Теги” в верхней панели нашего приложения. При этом открывается список тегов, который выглядит как на рисунке 4.7.
Рис. 4.7 – Внешний вид списка тегов
Список тегов представляет из себя таблицу с простой структурой: в качестве полей для тегов используется ID и название. В будущем планируется ассоциировать тег с каким либо цветом. Это позволит лучше акцентировать внимание на тегах при просмотре списка задач.
Для добавления дополнительных тегов в систему служит ссылка “Создать тег”. При клике по ссылке мы переходим на форму создания тега, которая состоит из единственного поля “Название тега”. Внешний вид формы добавления тега представлен на рисунке 4.8.
Рис. 4.8 – Форма добавления тега
Для названия тегов, как и для названия проектов, введена процедура проверки на минимальное и максимальное значение, что позволяет контролировать введенные пользователем параметры. Над формой добавления тега доступна ссылка “Список тегов” для перехода на список тегов. При успешном прохождении проверки на длину названия и успешного добавления тега в базу пользователь переходит на список тегов.
В отличии, например, от списка задач, теги не привязаны к конкретному пользователю и общедоступны в системе. Однако теги не имеют смысла без задач. Давайте рассмотрим структуру списка задач а так же способы его изменения.
Задачи - это сущность, с помощью которой осуществляется фиксация ошибок, новых возможностей и других действий в системе. Внешний вид списка задач изображен на рисунке
Рис. Внешний вид списка задач
В рамках единообразия интерфейса, список задач так же представлен в виде таблицы. Первая колонка в этой таблице - это уникальный идентификатор задачи, вторая колонка - названия задачи, третья - описание задачи. Описание задачи может быть достаточно большим, поэтому отображается только ограниченное количество символов. Так же, как и в других сущностях, доступно более полное описание задачи. Чтобы перейти к полному описанию задачи необходимо нажать на ссылку в поле ID соответствующей задачи. При это пользователь переходит на страницу, вид которой представлен на рисунке
Рис. Внешний вид карточки задачи
В данной форме, помимо полного описания задачи, имеются теги, которые привязаны к задаче. Это позволяет получить краткую характеристику задачи без подробного изучения ее сути. Пользователь может перейти обратно на список задач при нажатии на ссылку “Список задач”.
Из страницы списка задач так же можно добавить задачу. Данная функция доступна при клике на ссылку “Создать задачу”. При этом пользователь переходит на форму создания задачи. Интерфейс формы создания задачи очень похож на интерфейс создания других сущностей системы и представлен на рисунке.
Рис. Внешний вид интерфейса создания задачи.
Для заполнения доступны поля “Название”, “Описание” и “Теги”. При этом, для удобства пользователя, теги добавляются с использованием автодополнения. Оно доступном при введении пользователем определенного количества символов. При каждом нажатии формируется запрос на удаленный узел, от которого возвращается результирующий список тегов. Поле “Теги” носит опциональный характер, остальные поля обязательны для заполнения и так же, как и в других сущностях, имеют проверку на минимальное и максимальное количество символов. При нажатии на кнопку “Добавить”, в случае прохождения всех проверок и добавления задачи в базу, пользователь перенаправляется на список задач.
В заключении описания интерфейса пользователя хочется отметить, что переход по ссылкам осуществляется без полной перегрузки страницы. Это экономит трафик и ускоряет работу приложения, по сравнению с традиционными веб-приложениями. Опишем ниже, какие технологии и инструменты применялись для достижения такого результата.
Как уже было сказано выше, данное приложение относится к классу клиент серверных приложений, взаимодействующих между собой посредством RESTfull API. При такой архитектуре клиент получается достаточно умным и на него возлагается обязанности по проверке входных данных, их первичной обработке и отправки на сервер. Зачастую некоторые обязанности дублируют те, что имеются на сервере. Например, проверка данных обычно делается и на клиенте, и на сервере. Такое решение продиктовано попыткой клиента не нагружать сервер лишними запросами.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 |
