Changes between Version 8 and Version 9 of UseCaseRealizations


Ignore:
Timestamp:
02/09/21 22:50:14 (4 years ago)
Author:
143096
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UseCaseRealizations

    v8 v9  
    1212
    1313|| **ID** || **Use Case Realization** ||
    14 || 1 ||**Пребарува пракса/работа/проект според клучен збор** По успешна најава User тип на корисник има опција во навигацискиот бар да пребарува работа/пракса/проект според клучен збор. Ова се одвива на тој начин што  корисникот внесува некој клучен збор на фронтенд и избира каков тип на работа бара. Ова се одвива преку форма, која постира на бекендот на патека /api/search и соодветно /job, /internship или /project. Ова се одвива преку SearchControllerot кој комуницира со WorkService преку функцијата за full-text search која е различна за сите типови на работа, соодветно во функцијата се креираат филтрирани листи преку итерации на сите работи кој содржат вештина или дескрипција/име ист на текстот кој е внесен како параметар во пребарувањето. По итерациите се враќа листа на одредени работи кој одговараат на критериумот, при што истите се испраќаат на фронтенд каде соодветно се додаваат во состојбата на реакт компонентата која врши real-time refresh на клиентот и ги листа резултатите од пребарувањето. ||
    15 || 2-3 ||**Ажурира лични податоци / Ажурира вештини кој ги поседува или сака да ги стекне** По најавата, корисникот може да одбере да ги смени својте лични податоци. По кликање на копчето Edit на фронтендот корисникот е редиректиран во рамките на фронтендот, на посебна форма во која може да ги внесе промените кој сака да ги направи на својот профил. По внесување на соодветните промени и кликање на копчето Confirm се праќа Post request на бекендот кој го прима патеката /api/edit/account и /user/{userid}/{userEmail}, ова се разликува за различните типови на корисници. По пристап на оваа патека, бекендот ги зема податоците за корисникот како и неговиот id и email потоа враќа optional доколку тој email постои, креира две листи од вештини кој се земаат од база врз основа на нивните id-a кој се праќаат од корисникот како List<Long> потоа се повикува AccountService функцијата editUser која ги прима сите нови вредности како параметри. Оваа функција проверува дали постои тој email, доколку постои се фрла exception кој е хендлан така што на фронтендот му праќа објект со ерор и е презентиран во формата за едит на податоци. Доколку новиот e-mail помине се гради UserResponseDTO Кој ги праќа новите податоци до фронтендот и корисникот се редиректира назад на профилот на фронтендот. ||
     14|| **1** ||**Пребарува пракса/работа/проект според клучен збор** \\ **1.** По успешна најава User тип на корисник има опција во навигацискиот бар да пребарува работа/пракса/проект според клучен збор. \\ **2.** Kорисникот внесува некој клучен збор на фронтенд и избира каков тип на работа бара. Ова се одвива преку форма, која постира на бекендот на патека /api/search и соодветно /job, /internship или /project. Ова се одвива преку Search контролерот кој комуницира со Work сервисот преку функцијата за full-text search која е различна за сите типови на работа. \\ **3.** соодветно во функцијата се креираат филтрирани листи преку итерации на сите работи кој содржат вештина или дескрипција/име ист онаков како текстот кој е внесен како параметар во пребарувањето. \\ **4.** По итерациите се враќа листа на одредени работи кој одговараат на критериумот, при што истите се испраќаат на фронтенд каде соодветно се додаваат во состојбата на реакт компонентата која врши real-time refresh на клиентот и ги листа резултатите од пребарувањето. ||
     15|| **2** и **3** ||**Ажурира лични податоци / Ажурира вештини кој ги поседува или сака да ги стекне** \\ **1.** По најавата, корисникот може да одбере да ги смени својте лични податоци. По кликање на копчето Edit на фронтендот корисникот е редиректиран во рамките на фронтендот, на посебна форма во која може да ги внесе промените кој сака да ги направи на својот профил. \\ **2.** По кликање на Edit копчето, корисникот е редиректиран до рутата за Edit при што вредностите на полињата во формата се популираат од самата реакт состојба за моментално најавениот корисник. \\ **3.** По внесување на соодветните промени и кликање на копчето Confirm се праќа Post request на бекендот кој го прима патеката /api/edit/account и /user/{userid}/{userEmail}. \\ **4.** Ова се разликува за различните типови на корисници. По пристап на оваа патека, бекендот ги зема податоците за корисникот како и неговиот id и email кој се променливи во патеката. \\ **5.** Потоа враќа Optional која е резултат на повик до функцијата од Account сервисот - findByIdAndEmail која прима 3 аргументи, id, email и тип на корисник. \\ **6.** Ова за возврат прави повик до соодветните репозиториуми според тоа каков тип на акаунт бара едит. \\ **7.** Доколку тој email и тоа id постојат, односно Optional објектот не е празен, се креираат две листи од вештини кој се земаат од база врз основа на нивните id-a кој се праќаат од корисникот како List<Long> (Исто како за регистрација.) \\ **8.** Потоа се повикува Account сервис функцијата editUser која ги прима сите нови вредности како параметри. \\ **9.** Оваа функција функционира на ист начин како кај регистрацијата, само разликата е што во овој случај се прави overwrite на постоечки корисник со одредено ID. дали постои тој email, доколку постои се фрла exception кој е хендлан така што на фронтендот му праќа објект со error и е презентиран во формата за едит на податоци. Доколку новиот e-mail помине се зачувува нови гради UserResponseDTO Кој ги праќа новите податоци до фронтендот и корисникот се редиректира назад на профилот на фронтендот. ||
    1616
    1717