Имплементација на случаи на употреба

Заклучно со оваа фаза се имплементирани сите предвидени кориснички сценарија, односно:

ID	Use Case
1	Регистрација на корисник
2	Најава на корисник
3	Пребарување на рецепти
4	Филтрирање на рецепти
5	Клик на копчето за пребарување на рецепти
6	Клик на одреден рецепт
7	Правење на нарачка на состојки
8	Оставање на оцена и коментар
9	Додавање на рецепт во листа на омилени рецепти
10	Бришење на рецепт од листа на омилени рецепти
11	Листање на омилени рецепти
12	Листање на оценети рецепти
13	Апликација за вработување
14	Превземање на нарачка како доставувач
15	Листање на активни нарачки како доставувач
16	Преглед на активни апликации за вработување
17	Преглед на коментари

Регистриран корисник (User)

ИД 13 - Апликација за вработување како доставувач

За корисник да аплицира за работна позиција како доставувач, корисникот треба првично да ги пополни своите информации и да го притисне копчето "Submit Application".

ИД 13

При клик на копчето Submit Application, се испраќа POST барање до backend апликацијата во кој се сместени поднесените информации кои се побарани во апликацијата (телефонскиот број, мејл адресата, CV-фајлот како и мотивационото писмо).

Во header делот не е потребно да специфицираме дека Content-Type ќе е multipart/form-data поради тоа што самиот IDE може да препознае дека се испраќа таков тип на контент.

ИД 13

За секоја потребна информација чуваме посебен Hook, и тие се ажурираат при секоја промена од страна на корисникот.

ИД 13

Во следните неколку слики е опишана обработката на апликацијата на корисникот.

Во backend апликацијата, POST request-от е примен од страна на контролерот ApplicationController којшто содржи соодветен API endpoint. којшто ги препраќа потребните информации кон подолните слоеви (сервисниот слој).

Во контролерот ја составуваме апликацијата според пратените информации и тие информации ги препраќаме до сервисниот дел.

ИД 13

Сервисниот дел директно ги препраќа информациите до последниот слој (Data Access Object)

ИД 13

Во последниот слој користиме java database connection за да ги пратиме дадените информации како нов ред во табелата „application“.

Ние одбравме директно да ги чуваме cv-ата во база место како url поради тоа што не е очекувано да се добива многу апликации и при review на истите администраторот е задолжен да ги избрише.

Администратор (Admin)

ИД 16 - Преглед на активни апликации за вработување

Да ја поминеме процедурата за превземање на cv-ња на апликанти од страна на администраторот, постапката на изглед е едноставна. Администраторот веќе се наоѓа на страницата која ги прикажува сите апликации. Тој селектира еден апликант и има можност да го превземе cv-to, да го прифати или одбие апликантот

ИД 16

Во зависнот од Hook-от "active" се прикажуваат потребните картички, во овој случај по default е сетирана на "application" за да ни се прикажат картичките од апликациите. Другите states се однесуваат за други случаи на употреба.

ИД 16

Во истиот filе се праќа get барање во завистост од кој api endpoint се бара (во овој случај /application)

Дополнително се испраќа page и size поради тоа што апликациите како и сите други картички се враќаат во форма на pagination.

ИД 16

Во секој ApplicationCard праќаме дополнително барање до друг endpoint за прибирање на деталите за секој user.

Дополнително во header делот праќаме jwt Token за да се осигуриме дека Администраторот е тој што ги праќа барањата до backed делот.

Исто така и специфицираме дека Content-Type-от е во application/json формат.

ИД 16

Справувањето на accept копчето се активира додека администраторот сака да го прифати апликантот како доставувач.

Се праќа POST барање со посебен header кои што состои автентикација дека администраторот е тој што го прифаќа доставувачот и го сетираме Content-Type на application/json.

ИД 16

Во backend делот од апликацијата се пречекува барањето од соодветниот API endpoint, се добива идентификацискиот број на userot и се препраќа кон сервисниот слој

ИД 16

Сервисниот слој само го препраќа ид-то кон Data Access Object слојот.

ИД 16

Data Access Објеct слојот користејќи jdbc (java database connection) го менува односно update-ира улогата на корисникот во доставувач.