Changes between Version 18 and Version 19 of Имплементација
- Timestamp:
- 12/19/21 18:04:30 (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Имплементација
v18 v19 1 = **Имплементација** = 1 = Имплементација = 2 3 4 5 2 6 3 7 == Организација на контролата врз верзии на изворниот код … … 5 9 За контрола врз верзиите на изворниот код ќе се користи алатката Git. 6 10 11 12 13 14 7 15 == Изворен код 8 16 17 {{{#!box type=todo 18 Слободно наведете дека изворно работевте на Github и од таму е пренесен тука кодот за чување во проектниот простор на факултетот. 19 }}} 20 21 {{{#!box type=todo 22 Недостасува краток опис на организацијата на датотеките. 23 }}} 24 25 26 9 27 **[https://develop.finki.ukim.mk/projects/SaveSpace/browser Извор - SaveSpace]** 10 28 29 30 31 32 11 33 == Имплементациски дијаграм 12 34 35 36 37 38 13 39 === Најава и автентикација 14 40 15 Во овој дел ќе бидат прествени и објаснати одредени функционалности од системот кои се користат нај често во рамки на системот. Ќе започнам со објаснување за начинот на креирање на оддел кој што е предуслов за креирање на фолдер т.е. документ.\\ 16 Во MVC системот моделот е класа која се состои од податоци запишани во одредена табела во база. View го претставува интерфејсот преку кој корисникот комуницира со апликацијата. Кога корисникот презема акција, Controller се справува со акцијата и ги ажурира податоците во база преку моделот доколку е потребно.\\ 17 Во Laravel, моделот обично е класа со променливи што одговараат на колоните во базата на податоци т.е. променливите кои се дефинирани во Migrations во одредена табела. Контролерите се одговорни за завршување на корисничките дејства и за управување со деловната логика на апликацијата. Рутирањето на ресурсите во Laravel ги доделува „CRUD“ операциите или функциите дефинирани во контролерот со една линија код.\\ 18 19 Ќе започнам со објаснување на начинот на најва и автентикација во апликацијата. За автентикација се користи Middleware кој што обезбедува механизам за проверка и филтрирање на HTTP барањата на апликацијата. Laravel вклучува софтвер кој потврдува дека корисникот е автентициран. Ако корисникот не е автентициран, ќе го пренасочи корисникот на екранот за најава. Меѓутоа, ако корисникот е автентициран, ќе дозволи барањето да продолжи да се процесира. Освен базичните класи за автентикација кои ни ги овозможува Laravel во Middleware директориумот ги додаваме сите проверки кои му дозволуваат на корисникот да се автентицира. На пример во апликацијата предуслов за најава е да се креира лозинка за да се активира профилот на корисникот. Laravel го олеснува начинот на заштитата на апликацијата од напади за не верифицирани барања меѓу страници со помош на CSRF. Laravel автоматски генерира CSRF „токен“ за секоја активна корисничка сесија управувана од апликацијата. Овој токен се користи за да се потврди дека автентицираниот корисник е тој што всушност ги поставува барањата до апликацијата. Во секоја форма преку која праќаме HTTP барање потребно е да се додаде и CSFR токенот.\\ 41 Во овој дел ќе бидат претставени одредени функционалности од системот кои се почесто во употреба и ќе биде објаснето како се имплементирани. Ќе започнам со објаснување за начинот на креирање на оддел кој е предуслов за креирање на фолдер т.е. документ. 42 43 {{{#!rbox type=todo 44 Тука првпат спомнувате MVC, треба да објасните што е тоа во една реченица, како што правевте и поопсежно на други места, и да дадете референца. 45 }}} 46 Во MVC системот моделот е класа која се состои од податоци запишани во одредена табела во база. View го претставува интерфејсот преку кој корисникот комуницира со апликацијата. Кога корисникот презема акција, Controller се справува со акцијата и ги ажурира податоците во база преку моделот доколку е потребно. 47 48 {{{#!rbox type=todo 49 Некои реченици се нејасно напишни, да се рефразира. 50 }}} 51 Во Laravel, моделот обично е класа со променливи што одговараат на колоните во базата на податоци т.е. променливите кои се дефинирани во Migrations во одредена табела. Контролерите се одговорни за завршување на корисничките дејства и за управување со деловната логика на апликацијата. Рутирањето на ресурсите во Laravel ги доделува „CRUD“ операциите или функциите дефинирани во контролерот со една линија код. 52 53 Ќе започнам со објаснување на начинот на најава и автентикација во апликацијата. За автентикација се користи Middleware кој обезбедува механизам за проверка и филтрирање на HTTP барањата на апликацијата. Laravel вклучува софтвер кој потврдува дека корисникот е автентициран. Ако корисникот не е автентициран, ќе го пренасочи корисникот на екранот за најава. Меѓутоа, ако корисникот е автентициран, ќе дозволи барањето да продолжи да се процесира. Освен базичните класи за автентикација кои ни ги овозможува Laravel во Middleware директориумот ги додаваме сите проверки кои му дозволуваат на корисникот да се автентицира. 54 55 На пример, во апликацијата предуслов за најава е да се креира лозинка за да се активира профилот на корисникот. Laravel го олеснува начинот на заштитата на апликацијата од напади за не верифицирани барања меѓу страници со помош на CSRF. Laravel автоматски генерира CSRF „токен“ за секоја активна корисничка сесија управувана од апликацијата. Овој токен се користи за да се потврди дека автентицираниот корисник е тој што всушност ги поставува барањата до апликацијата. Во секоја форма преку која праќаме HTTP барање потребно е да се додаде и CSFR токенот. 20 56 21 57 {{{ … … 38 74 }); 39 75 }}} 40 ''Листа на рути за автентикација''\\ 41 Како што може да се види за секој повик за автентикација потребен е параметарот token кој што означува уникатен идентификатор на корисничкиот профил преку кој корисникот се автентицира и праќа барања до серверот.\\ 76 77 ''Листа на рути за автентикација'' 78 79 Како што може да се види за секој повик за автентикација потребен е параметарот token кој означува уникатен идентификатор на корисничкиот профил преку кој корисникот се автентицира и праќа барања до серверот. 42 80 43 81 {{{ … … 89 127 } 90 128 }}} 91 ''Методи од контролерот LoginController за најава во апликацијата''\\ 92 Со помош на методот showLogin() го прикажуваме интерфејсот за најава во апликацијата. Во методот login() се врши најавата. Во овој метод има два параметри од кои едниот е валидацијата на податоците преку барањето која се врши преку класата LoginRequest како и $hashid од класата HashId која ни помага при енкодирање на токенот за верификација на најавата. Во овој метод проверуваме дали корисникот постои во база, е активен т.е. дали креирал лозинка и се најавил во системот и дали има внесено точна лозинка. Потоа му се генеира безбедносен код кој што ќе му биде испратен на маил за верификација на најавата преку VerifyUser класата за праќање на нотификација како и токенот за верификација преку кој ќе се најави. По автентикација на корисникот ќе му се појави екранот за внес на кодот за верификација т.е. ќе се прати барање до контролерот VerifyLoginController.\\ 129 130 ''Методи од контролерот LoginController за најава во апликацијата'' 131 132 Со помош на методот showLogin() го прикажуваме интерфејсот за најава во апликацијата. Во методот login() се врши најавата. Во овој метод има два параметри од кои едниот е валидацијата на податоците преку барањето која се врши преку класата LoginRequest како и $hashid од класата HashId која ни помага при енкодирање на токенот за верификација на најавата. Во овој метод проверуваме дали корисникот постои во база, е активен т.е. дали креирал лозинка и се најавил во системот и дали има внесено точна лозинка. Потоа му се генеира безбедносен код кој ќе му биде испратен на е-пошта за верификација на најавата преку VerifyUser класата за праќање на нотификација како и токенот за верификација преку кој ќе се најави. По автентикација на корисникот ќе му се појави екранот за внес на кодот за верификација т.е. ќе се прати барање до контролерот VerifyLoginController. 93 133 94 134 {{{ … … 107 147 } 108 148 }}} 109 ''Метод од класата VerifyUser за праќање на верификацистиот код на маил'' 110 149 150 ''Метод од класата VerifyUser за праќање на верификацискиот код по е-пошта'' 111 151 112 152 {{{ … … 130 170 } 131 171 }}} 132 ''Методи од контролерот VerifyLoginController''\\ 133 Секогаш почнуваме со приказ на интерфејсот т.е. index методот која ни служи за приказ на целата колекција од податоци. Откако корисникот ќе се најави ќе стигне барањето до методот verify кој ќе го прими барањето, ќе направи декодирање на претходно енкодираниот $hashid и ќе му дозволи на корисникот да се најави во системот.\\ 172 173 ''Методи од контролерот VerifyLoginController'' 174 175 Секогаш почнуваме со приказ на интерфејсот т.е. index методот која ни служи за приказ на целата колекција од податоци. Откако корисникот ќе се најави ќе стигне барањето до методот verify кој ќе го прими барањето, ќе направи декодирање на претходно енкодираниот $hashid и ќе му дозволи на корисникот да се најави во системот. 176 177 178 179 134 180 135 181 === Управување со оддели 182 183 {{{#!box type=todo 184 Најдобро прво објаснение, а потоа пример, а не обратно. Свртете ги обратно и сменете го и објаснувањето во текстот да е соодветно. 185 }}} 186 136 187 137 188 {{{ … … 159 210 }}} 160 211 161 ''Department моделот''\\ 212 ''Department моделот'' 213 162 214 Во горенаведениот код се запишани променливите кои претходно биле дефнирани во табелата Departments. Исто така во овој дел се дефинираат и релации помеѓу два или повеке модели. Во конкретниот случај е дефинирана релација помеѓу Department и Folder моделот каде што се означува дека еден оддел може да има неколку фолдери. Може да се дефинираат и методи кои влечат одредени податоци од истиот модел како што методот getCreatedByName() кој го наоѓа корисничкото име од User модел-от и истиот може потоа да се прикаже во интерфејс на апликацијата преку класата Department. 163 215 … … 171 223 }}} 172 224 173 ''Метод од контролерот DepartmentsController за приказ на сите оддели запишани во база''\\ 225 ''Метод од контролерот DepartmentsController за приказ на сите оддели запишани во база'' 226 174 227 Методот index се повикува кога рутата /departments е вчитана со методот GET HTTP. Во овој метод, ние ги преземаме сите достапни податоци во табелата за оддели користејќи го моделот Department и го пренесуваме во интерфејсот како променлива. Ова значи дека во интерфејсот, променливата $departments ќе може да се користи за да се прикажат податоци од колекцијата која ги состои сите оддели. 175 228 … … 187 240 }}} 188 241 189 ''Листа на рути за оддели''\\ 242 ''Листа на рути за оддели'' 243 190 244 Секој повик во Laravel потребно е да има посебна рута. Рутата со име index ја дефинирав посебно за да се ограничи пристапот за корисници кои имаат ролја во која не е дозволено да управуваат со оддели. Рутата store служи за креирање на нов оддел. Методот во оваа рута секогаш треба да е post затоа што се запишуваат нови податоци т.е. се креира нов оддел. Методот patch се повикува кога се прави ажурирање на податоците во база за веќе креиран оддел што во овој случај е рутата со име edit. На двете рути за да прикажат и ажурираат оддел потребно им е да се додели вредност id која според id-то во база ќе го најде конкретниот оддел. 191 192 245 193 246 {{{ … … 216 269 } 217 270 }}} 218 ''Метод од контролерот DepartmentsController за креирање на нов оддел''\\ 219 Како што може да се види и во кодот методот како влезен параметар има објект од класата NewDepartmentRequest каде што се прави валидацијата на променливите од моделот Department кога тие ќе стигнат преку HTTP барањето преку формата која претходно ја пополнувал корисникот во интерфејсот на апликацијата. Почнуваме со креирање на нов објект од класата Department и сите параметри кои треба да се запишат во база за тој оддел ќе бидат еднакви на тие што доаѓаат од повикот. При креирање на одделот за истиот креираме и фолдер во сервер за зачувување на датотеките. Името на фолдер-от го одредува кодот кој го доделуваме на новиот оддел а локацијата на фолдер-от ја зачувуваме во променлива. На крај го зачувуваме одделот и прикажуваме порака на корисникот дали во таа сесија поминало барањето или не. Доколку има грешки се прикажуваат валидациски пораки. Последен чекор е да се вратиме на почетниот екран.\\ 271 272 ''Метод од контролерот DepartmentsController за креирање на нов оддел'' 273 274 Како што може да се види и во кодот методот како влезен параметар има објект од класата NewDepartmentRequest каде што се прави валидацијата на променливите од моделот Department кога тие ќе стигнат преку HTTP барањето преку формата која претходно ја пополнувал корисникот во интерфејсот на апликацијата. Почнуваме со креирање на нов објект од класата Department и сите параметри кои треба да се запишат во база за тој оддел ќе бидат еднакви на тие што доаѓаат од повикот. При креирање на одделот за истиот креираме и фолдер во сервер за зачувување на датотеките. Името на фолдер-от го одредува кодот кој го доделуваме на новиот оддел а локацијата на фолдер-от ја зачувуваме во променлива. На крај го зачувуваме одделот и прикажуваме порака на корисникот дали во таа сесија поминало барањето или не. Доколку има грешки се прикажуваат валидациски пораки. Последен чекор е да се вратиме на почетниот екран. 220 275 221 276 {{{ … … 231 286 } 232 287 }}} 233 ''Класата Alert за приказ на пораки од сесија''\\ 234 Методот во класата алерт е креиран за да му ја олесни работата на корисникот во моментот кога нема да помине барањето поради грешка при валидација на податоците или друг проблем. За приказ на пораките користев Тоаst JS [11].\\ 288 289 ''Класата Alert за приказ на пораки од сесија'' 290 291 Методот во класата алерт е креиран за да му ја олесни работата на корисникот во моментот кога нема да помине барањето поради грешка при валидација на податоците или друг проблем. За приказ на пораките користев Тоаst JS [11]. 235 292 236 293 {{{ … … 255 312 }); 256 313 257 258 314 </script> 259 315 @endif 260 316 }}} 261 ''Интерфејсот за приказ на пораките''\\ 262 Во првиот дел проверуваме дали има грешка и ја враќаме пораката од сесија и типот го поставуваме да е секогаш грешка за да биде соодветно на пораката додека во вториот дел проверувам дали во сесија има објект alert т.е. дали се враќа одговор од серверот и ја прикажуваме пораката и типот на одговорот според сесија.\\ 317 318 ''Интерфејсот за приказ на пораките'' 319 320 Во првиот дел проверуваме дали има грешка и ја враќаме пораката од сесија и типот го поставуваме да е секогаш грешка за да биде соодветно на пораката додека во вториот дел проверувам дали во сесија има објект alert т.е. дали се враќа одговор од серверот и ја прикажуваме пораката и типот на одговорот според сесија. 263 321 264 322 {{{ … … 301 359 } 302 360 }}} 303 ''Метод од контролерот DepartmentsController за уредување на оддел''\\ 304 Со помош на методот edit може да се смени името на одделот или кодот. Во случај кога ќе се прави измена во кодот потребно е името на фолдерот каде што се наоѓаат сите датотеки од тој оддел да се преименува. Со таа цел преку функцијата isDirty() со која може да се дознае дали моделот е уреден пред да се запише во база проверувам дали има промена и доколку има прво го поместуваме одделот во нов директориум а потоа во две итерации ги изминуваме сите фолдери и датотеки и нивните патеки во база ги заменуваме со новата. На крај ги зачувуваме и прикажувам соодветна порака за извршена акција како и го враќам корисникот во страницата со сите оддели.\\ 361 362 ''Метод од контролерот DepartmentsController за уредување на оддел'' 363 364 Со помош на методот edit може да се смени името на одделот или кодот. Во случај кога ќе се прави измена во кодот потребно е името на фолдерот каде што се наоѓаат сите датотеки од тој оддел да се преименува. Со таа цел преку функцијата isDirty() со која може да се дознае дали моделот е уреден пред да се запише во база проверувам дали има промена и доколку има прво го поместуваме одделот во нов директориум а потоа во две итерации ги изминуваме сите фолдери и датотеки и нивните патеки во база ги заменуваме со новата. На крај ги зачувуваме и прикажувам соодветна порака за извршена акција како и го враќам корисникот во страницата со сите оддели. 305 365 306 366 {{{ … … 323 383 } 324 384 }}} 325 ''Метод од контролерот DepartmentsController за бришење на оддел''\\ 326 Покрај уредување на оддел корисникот со привилегии администратор или референт има можност да избрише еден оддел што значи да се одстранат сите записи од база како и сите фолдери и датотеки за истиот. Корисникот има можност да го избрише одделот само ако тој оддел е празен т.е. доколку во него не постои ниту еден фолдер. Во спротивно, се фрла порака дека тој оддел има асоцирани фолдери со него и не ја дозволува акцијата да се изврши.\\ 385 386 ''Метод од контролерот DepartmentsController за бришење на оддел'' 387 388 Покрај уредување на оддел корисникот со привилегии администратор или референт има можност да избрише еден оддел што значи да се одстранат сите записи од база како и сите фолдери и датотеки за истиот. Корисникот има можност да го избрише одделот само ако тој оддел е празен т.е. доколку во него не постои ниту еден фолдер. Во спротивно, се фрла порака дека тој оддел има асоцирани фолдери со него и не ја дозволува акцијата да се изврши. 327 389 328 390 {{{ … … 367 429 } 368 430 }}} 369 ''Метод од контролерот DepartmentsController за симнување на фолдери и датотеки од оддел''\\ 370 За потребите на компанијата додаден е метод за симнување на сите фолдери со нивните датотеки од еден оддел преку кој се креира zip кој ги содржи сите фолдери од еден оддел со истата структура како што се тие запишани на сервер. На почеток проверуваме дали има празни фолдери со цел тие да ги игнорираме затоа што не содржат ниту една датотека.Класата RecursiveIteratorIterator која што е тип на итератор кој ни овозможува рекурзивно да ги поминеме сите патеки ми помогна да ги најдам потребните фолдери и датотеки. За разлика од обичен итератор кој што пребарува низ листа RecursiveIteratorIterator може да се каже дека пребарува низ дрво и ја олеснува работата кога се работи за неколку патеки во еден директориум. За секоја пронајдена датотека ја добиваме патеката од Storage и ја додаваме во zip. На крај ја симнуваме датотеката со доделено име, прикажуваме соодветна порака и се враќаме назад. Во овој дел клуч е патеката која ја запишувам при креирање на оддел. На истиот начин направив и функција за симнување на сите оддели со нивните фолдери и датотеки при што се игнорираат празните оддели и фолдери.\\ 431 432 ''Метод од контролерот DepartmentsController за симнување на фолдери и датотеки од оддел'' 433 434 За потребите на компанијата додаден е метод за симнување на сите фолдери со нивните датотеки од еден оддел преку кој се креира zip кој ги содржи сите фолдери од еден оддел со истата структура како што се тие запишани на сервер. На почеток проверуваме дали има празни фолдери со цел тие да ги игнорираме затоа што не содржат ниту една датотека.Класата RecursiveIteratorIterator која што е тип на итератор кој ни овозможува рекурзивно да ги поминеме сите патеки ми помогна да ги најдам потребните фолдери и датотеки. За разлика од обичен итератор кој пребарува низ листа RecursiveIteratorIterator може да се каже дека пребарува низ дрво и ја олеснува работата кога се работи за неколку патеки во еден директориум. За секоја пронајдена датотека ја добиваме патеката од Storage и ја додаваме во zip. На крај ја симнуваме датотеката со доделено име, прикажуваме соодветна порака и се враќаме назад. Во овој дел клуч е патеката која ја запишувам при креирање на оддел. На истиот начин направив и функција за симнување на сите оддели со нивните фолдери и датотеки при што се игнорираат празните оддели и фолдери. 435 436 371 437 372 438 … … 374 440 === Корисници и уредување на кориснички податоци 375 441 376 Секој корисник има можност да ги промени своите податоци за профилот како и администраторот има можност да ги промени податоците за секој корисник и да додаде нови. Исто така секој корисник има можност да ги менува е-адресата, корисничкото име или лозинката. Дополнително администраторот има можност да постави валидациски правила за прикачување на нови датотеки. Ќе започнам со објаснување на контролерот UsersController преку кој се креираат нови корисници или се менуваат кориснички податоци. \\442 Секој корисник има можност да ги промени своите податоци за профилот како и администраторот има можност да ги промени податоците за секој корисник и да додаде нови. Исто така секој корисник има можност да ги менува е-адресата, корисничкото име или лозинката. Дополнително администраторот има можност да постави валидациски правила за прикачување на нови датотеки. Ќе започнам со објаснување на контролерот UsersController преку кој се креираат нови корисници или се менуваат кориснички податоци. 377 443 378 444 {{{ … … 389 455 }); 390 456 }}} 391 ''Листа на рути за управување со корисници''\\ 392 Рутата за приказ на корисници е посебно дефинирана со цел да се овозможи пристап за корисници од различни ролји т.е. референтот да има можност да ја види листата со корисници но да нема можност да управува со нив.\\ 457 ''Листа на рути за управување со корисници'' 458 459 Рутата за приказ на корисници е посебно дефинирана со цел да се овозможи пристап за корисници од различни ролји т.е. референтот да има можност да ја види листата со корисници но да нема можност да управува со нив. 393 460 394 461 {{{ … … 439 506 } 440 507 }}} 508 441 509 ''Методи на контролерот UsersController за приказ и креирање на корисници'' 442 Додавање на нов корисник оди преку методот store кој како параметар го прима барањето кое ќе го валидира според правилата дефинирани во NewUserRequest класата. Некои од податоците за кои не им се доделува вредност при креирање креирав методи во User моделот за генерирање на random вредности со цел за да помине валидацијата на тие задолжителни полиња како на пример што е generateTemporaryPassword() методот. За корисникот исто така може да се додаде слика која ја зачувуваме во сервер. На крај се зачувува корисникот и се праќа нотификација од класата WelcomeUser() преку која праќаме маил до новиот корисник за креирање на нова лозинка со што корисникот ќе има активен профил и ќе може да се најави. На сличен начин работи и контролерот за уредување на кориснички податоци. За разлика од креирање во тој дел доколку се промени е-адресата на корисникот се генеира нов токен за верификација како и безбедносен код и се праќаат до корисникот со цел да го верифицира истиот и да може да се најави пак во системот.\\ 510 511 Додавање на нов корисник оди преку методот store кој како параметар го прима барањето кое ќе го валидира според правилата дефинирани во NewUserRequest класата. Некои од податоците за кои не им се доделува вредност при креирање креирав методи во User моделот за генерирање на random вредности со цел за да помине валидацијата на тие задолжителни полиња како на пример што е generateTemporaryPassword() методот. За корисникот исто така може да се додаде слика која ја зачувуваме во сервер. На крај се зачувува корисникот и се праќа нотификација од класата WelcomeUser() преку која праќаме е-пошта до новиот корисник за креирање на нова лозинка со што корисникот ќе има активен профил и ќе може да се најави. На сличен начин работи и контролерот за уредување на кориснички податоци. За разлика од креирање во тој дел доколку се промени е-адресата на корисникот се генеира нов токен за верификација како и безбедносен код и се праќаат до корисникот со цел да го верифицира истиот и да може да се најави пак во системот. 443 512 444 513 {{{ … … 450 519 } 451 520 }}} 452 ''Дел од методот за уредување на корисник (промена на е-адреса)''\\ 453 521 ''Дел од методот за уредување на корисник (промена на е-адреса)'' 454 522 455 523 {{{ … … 463 531 } 464 532 }}} 533 465 534 ''Методот за блокирање на корисник'' 466 Доколку еден корисник не работи веќе во фирмата тоа значи дека истиот не смее да се најави веќе во системот. Со таа намена методот block го менува статусот на корисникот од активен во не активен и не му дозволува да се најави во системот. На ист начин може и да се деблокира еден корисник.\\ 467 535 536 Доколку еден корисник не работи веќе во фирмата тоа значи дека истиот не смее да се најави веќе во системот. Со таа намена методот block го менува статусот на корисникот од активен во не активен и не му дозволува да се најави во системот. На ист начин може и да се деблокира еден корисник. 468 537 469 538 {{{ … … 495 564 } 496 565 }}} 566 497 567 ''Метод за промена на личните кориснички податоци'' 498 Преку методот editUserData секој најавен корисник има можност да си ги менува своите лични кориснички податоци како име, презиме, мобилен број или слика.\\ 499 500 568 569 Преку методот editUserData секој најавен корисник има можност да си ги менува своите лични кориснички податоци како име, презиме, мобилен број или слика. 501 570 502 571 {{{ … … 523 592 } 524 593 }}} 525 ''Метод за бришење на корисник''\\ 526 Администраторот на апликацијата има можност да избрише корисник со користење на методот destroy. При бришење во истиот момент је отстранува и сликата од профилот на корисникот од сервер како и сите податоци за него во база. Притоа, еден корисник може да се избрише само доколку нема асоцирани фолдери во него т.е. доколку тој корисник никогаш не додал фолдери и датотеки во одреден оддел.\\ 527 594 595 ''Метод за бришење на корисник'' 596 597 Администраторот на апликацијата има можност да избрише корисник со користење на методот destroy. При бришење во истиот момент је отстранува и сликата од профилот на корисникот од сервер како и сите податоци за него во база. Притоа, еден корисник може да се избрише само доколку нема асоцирани фолдери во него т.е. доколку тој корисник никогаш не додал фолдери и датотеки во одреден оддел. 528 598 529 599 {{{ … … 543 613 } 544 614 }}} 615 545 616 ''Метод за промена на корисничко име во SettingsController контролерот'' 546 Преку методот updateUsername корисникот има можност да го промени своето корисничко име. Методот како параметар го добива барањето кое ќе биде валидирано според правилата поставени во UsernameSettingsRequest. По завршена акција корисникот се одјавува. Доколку се промени е-адресата тој исто така добива и маил за потврда на новата со цел да може да се најави пак. На ист начин работи и методот за промена на лозинка.\\ 617 618 Преку методот updateUsername корисникот има можност да го промени своето корисничко име. Методот како параметар го добива барањето кое ќе биде валидирано според правилата поставени во UsernameSettingsRequest. По завршена акција корисникот се одјавува. Доколку се промени е-адресата тој исто така добива и порака по е-пошта за потврда на новата со цел да може да се најави пак. На ист начин работи и методот за промена на лозинка. 547 619 548 620 {{{ … … 570 642 } 571 643 }}} 572 ''Метод за промена на валидациски правила во SettingsController контролерот''\\ 573 Валидациските правила се зачувуваат во база во еден ред од посебна табела и истите потоа се превземаат при валидација за прикачување на датотеки. Администраторот има можност да ги дефинира сите дозволени типови на датотеки кои можат да се прикачат како и максималната големина по датотека.\\ 574 644 645 ''Метод за промена на валидациски правила во SettingsController контролерот'' 646 647 Валидациските правила се зачувуваат во база во еден ред од посебна табела и истите потоа се превземаат при валидација за прикачување на датотеки. Администраторот има можност да ги дефинира сите дозволени типови на датотеки кои можат да се прикачат како и максималната големина по датотека. 575 648 576 649 {{{ … … 590 663 } 591 664 }}} 665 592 666 ''Дел од кодот за валидација на датотеки'' 593 Во овој дел од FolderRequest класата за валидација на нов фолдер може да се забележи дека во mimes се запишуваат типови на датотеки кои што администраторот претходно ги дефинирал преку методот fileTypes(). Прво го наоѓаме првиот ред од база од класата FileType и неговите податоци ги поставуваме како валидациски правила. 667 668 Во овој дел од FolderRequest класата за валидација на нов фолдер може да се забележи дека во mimes се запишуваат типови на датотеки кои администраторот претходно ги дефинирал преку методот fileTypes(). Прво го наоѓаме првиот ред од база од класата FileType и неговите податоци ги поставуваме како валидациски правила. 669 670 671 672 594 673 595 674 === Управување со фолдери и датотеки 596 597 598 675 599 676 {{{ … … 611 688 }); 612 689 }}} 690 613 691 ''Рути за управување со фолдери'' 614 Рутата со име dashboard.folders.files се користи за приказ на сите датотеки за одреден фолдер според query параметарот кој што е id од избраниот фолдер. Рутите create и store се користат за креирање на нов фолдер додека рутата uploadFiles за прикачување на нови датотеки во веќе креиран фолдер. 615 692 693 Рутата со име dashboard.folders.files се користи за приказ на сите датотеки за одреден фолдер според query параметарот кој е id од избраниот фолдер. Рутите create и store се користат за креирање на нов фолдер додека рутата uploadFiles за прикачување на нови датотеки во веќе креиран фолдер. 616 694 617 695 {{{ … … 699 777 } 700 778 }}} 701 ''Метод од контролерот FoldersController за приказ на фолдери''\\ 702 За разлика од другите index методи тука дополнително правам сортирање по query параметри и ги подредувам фолдерите според селекцијата која ја прави во интерфејсот. Сите податоци се прикажуваат и полнат на истата страница и со таа цел пред да ја враќам колекцијата и да ја прикажам на фронтенд ги правам сите можни проверки за сортирање. Исто така, освен сортирање на главната страница со сите фолдери правам и сортирање на фолдери од еден оддел кога пристапува корисникот до избран оддел преку навигацискиот панел. Исто така правам калкукација на тоа колку простор е зафатен во дискот на сервер преку функцијата disk_total_space која ја враќа вкупната зафатеност на дискот или одредена партиција каде што работи апликацијата. Преку фунцијата paginate() која како параметар прима број на објекти по страница Laravel креира страници кои што исто така преку query параметри прават филтрирање и ги листаат објектите по даден број во различни страници. \\ 703 779 780 ''Метод од контролерот FoldersController за приказ на фолдери'' 781 782 За разлика од другите index методи тука дополнително правам сортирање по query параметри и ги подредувам фолдерите според селекцијата која ја прави во интерфејсот. Сите податоци се прикажуваат и полнат на истата страница и со таа цел пред да ја враќам колекцијата и да ја прикажам на фронтенд ги правам сите можни проверки за сортирање. Исто така, освен сортирање на главната страница со сите фолдери правам и сортирање на фолдери од еден оддел кога пристапува корисникот до избран оддел преку навигацискиот панел. Исто така правам калкукација на тоа колку простор е зафатен во дискот на сервер преку функцијата disk_total_space која ја враќа вкупната зафатеност на дискот или одредена партиција каде што работи апликацијата. Преку фунцијата paginate() која како параметар прима број на објекти по страница Laravel креира страници кои исто така преку query параметри прават филтрирање и ги листаат објектите по даден број во различни страници. 704 783 705 784 {{{ … … 774 853 } 775 854 }}} 855 776 856 ''Потребни методи за креирање на нов фолдер'' 777 Начинот на креирање на фолдер е идентичен со тој на оддел. За разлика од првиот тука при креирање на избор потребно е фолдерот да има асоциран оддел како и архивски број според избраниот оддел кој што автоматски ќе му биде препопулиран по избор. Исто така дополнително има можност за прикачување на датотеки кои ќе бидат асоцирани со ново креираниот фолдер. Во кодот може да се забележи дека се проверува дали постои фолдер во база со исто име или архивски број. Доколку постои само едното се враќа порака за грешка и доколку се исти двете полиња се креира нова верзија за веќе постоечкиот фолдер. За секој нов фолдер се креира папка на сервер според локацијата на одделот и во неја ги зачувувам сите додадени датотеки. Архивскиот број се состои од: "код од одделот" + "/" + "внесува корисникот". Истата логика се валидира во класата FolderRequest на следниот начин: 778 857 858 Начинот на креирање на фолдер е идентичен со тој на оддел. За разлика од првиот тука при креирање на избор потребно е фолдерот да има асоциран оддел како и архивски број според избраниот оддел кој автоматски ќе му биде препопулиран по избор. Исто така дополнително има можност за прикачување на датотеки кои ќе бидат асоцирани со ново креираниот фолдер. Во кодот може да се забележи дека се проверува дали постои фолдер во база со исто име или архивски број. Доколку постои само едното се враќа порака за грешка и доколку се исти двете полиња се креира нова верзија за веќе постоечкиот фолдер. За секој нов фолдер се креира папка на сервер според локацијата на одделот и во неја ги зачувувам сите додадени датотеки. Архивскиот број се состои од: "код од одделот" + "/" + "внесува корисникот". Истата логика се валидира во класата FolderRequest на следниот начин: 779 859 780 860 {{{ … … 832 912 } 833 913 }}} 834 ''Валидација на полињата за креирање на нов фолдер''\\ 835 Тука може да е забележи дека се прави валидација на архивскиот број со цел да се провери дали е тој правилно внесен т.е. дали се состои од кодот на одделот како и внесениот број од страна на корисникот и доколку не е се фрла исклучок. Валидација на низата од датотеки се прави според внесените валидациски правила од страна на администраторот.\\ 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 914 915 ''Валидација на полињата за креирање на нов фолдер'' 916 917 Тука може да е забележи дека се прави валидација на архивскиот број со цел да се провери дали е тој правилно внесен т.е. дали се состои од кодот на одделот како и внесениот број од страна на корисникот и доколку не е се фрла исклучок. Валидација на низата од датотеки се прави според внесените валидациски правила од страна на администраторот.
