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

---

Преглед на Model класите

---

Регуларен корисник

Ги прелистува секциите за дискусија

Текот на податоци откако корисникот ќе внесе 4 знаци во полето за пребарување на професори и предмети.

---

Истиот тек го следат повеќето делови од апликацијата. На пример, приказот на сите теми за даден предмет откако корисникот ќе се најде на страницата /subject/[subjectId], го спроведува компонентата Topic.js на сличен начин како погоре.

Корисничка регистрација

Главниот дел од логиката за корисничка регистрација се содржи во register методата од RegistrationService која се одзива на повик од RegistrationController и која прима податоци за новата корисничка сметка што треба да ја креира.
Истата зависи од неколку сервис класи кои содржат методи за валидација на примените податоци, како и од repository слојот. Вторава зависност е да се провери дали во базата постои корисник со ист e-mail (уникатна колона во случајов) и ако постои, дали сметката му е активирана. Во случајот да постои и да е активирана, се враќа исклучок со порака што се пропагира до UI слојот. Во спротивно, се инстанцира и перзистира во база објект од класата ConfirmationToken, со чиешто уникатно поле се гради линк за активација на сметката. Со помош на трета зависност - EmailSender класата (која повикува методи од JavaMail API) се испраќа мејл со линкот за активација, кој води до GET повик на кој се одзива confirm методот од RegistrationController, чијашто задача е да провери дали во базата постои токенот кој го добива како параметар. Доколку постои и е важечки (генериран пред доволно краток временски период), методот ја овозможува сметката и тоа го соопштува на UI слојот со враќање на стрингот „Confirmed“.

Корисничка најава

Најавата се врши преку кориснички интерфејс, со POST повик до сервисот за најава. Апликацијата користи автентикација со помош на колачиња. Доколку корисничкото име и лозинката се валидни, сервисот за најава му враќа на клиентот променлива (JSESSIONID), која вториот ја зачувува како колаче во прелистувачот и ја користи за сите понатамошни повици до други сервиси, сè додека корисникот не се одјави и колачето не се избрише. Колачето не се користи само за backend сервиси кои бараат автентикација, туку и за контрола на погледот во самиот клиент. Имено, многу UI компоненти се ограничени (се целосно скриени или видоизменети) зависно од глобална променлива „auth“ која се поставува на true доколку колачето е вчитано.

Додава мислење во секција за дискусија

Коментира туѓо мислење

Оценува туѓо мислење

Пријавува туѓо мислење

Го уредува својот кориснички профил

Случајот на употреба нема да се имплементира.

Го верификува својот кориснички профил

Случајот на употреба нема да се имплементира.

Модератор

Прегледува пријави за содржината

fetchPostReports() е метод кој се повикува при секое освежување на UserDashboard компонентата, но само доколку најавениот корисник ја има улогата 'MODERATOR'. За ова да се провери (поедноставено):

1. апликацијата на клиентска страна комуницира со прелистувачот и гледа дали во GET повикот кон /user_dashboard има заглавје - колаче со име JSESSIONID
2. доколку има, ја поставува глобалната променлива auth=true, што тригерира блокирачки повик кон fetchUser()
3. fetchUser() комуницира со апликацијата на серверска страна, предавајќи ја сесиската променлива во повикот
4. серверската апликација комуницира со базата која проверува дали во соодветната табела има запис со пречеканата променлива
5. доколку има, ги враќа сите податоци за корисникот (вклучувајќи ја и улогата)
6. fetchUser() го препушта извршувањето на fetchPostReports()

Изменува или брише напишана содржина

Како пример е даден само случајот за уредување мислења за предмети (Thread)
За бришење мислења во сервисниот слој се повикува PostRepository.deleteById(...), при што заедно со мислењето од базата се бришат сите негови „потомци-мислења“, а се зачувуваат пријавите за мислењето: