Version 15 (modified by 2 years ago) ( diff ) | ,
---|
Имплементација на случаите на употреба
Регуларен корисник
Ги прелистува секциите за дискусија
Текот на податоци откако корисникот ќе внесе 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 доколку колачето е вчитано.
Додава мислење во секција за дискусија
Коментира туѓо мислење
Оценува туѓо мислење
Пријавува туѓо мислење
Го уредува својот кориснички профил
Случајот на употреба нема да се имплементира.
Го верификува својот кориснички профил
Случајот на употреба нема да се имплементира.
Модератор
Прегледува пријави за содржината
Изменува или брише напишана содржина
Attachments (12)
- Screenshot_20230122_072453.png (137.9 KB ) - added by 2 years ago.
- prelistuva1.png (99.4 KB ) - added by 2 years ago.
- prelistuva2.png (8.9 KB ) - added by 2 years ago.
- registracija1.png (148.9 KB ) - added by 2 years ago.
- najava.png (15.8 KB ) - added by 2 years ago.
- replicira1.jpg (227.9 KB ) - added by 2 years ago.
- ocenuva1.png (82.1 KB ) - added by 2 years ago.
- prijavuva1.png (77.5 KB ) - added by 2 years ago.
-
dodava1.jpg
(226.2 KB
) - added by 2 years ago.
new
- pregleduva1.png (105.3 KB ) - added by 23 months ago.
- izmenuva1.png (164.1 KB ) - added by 23 months ago.
- Screenshot_20230202_014352.png (35.0 KB ) - added by 23 months ago.
Download all attachments as: .zip