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