Changes between Version 20 and Version 21 of Имплементација
- Timestamp:
- 12/20/21 19:30:17 (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Имплементација
v20 v21 21 21 Корегирано 22 22 }}} 23 Иницијалното репо за апликацијата го креирав на Github [https://docs.github.com/en/get-started/quickstart/hello-world] платформата за хостирање или зачувување на код. Преку интерфејсот на Github ја добиваме истата структура на апликацијата која ја развиваме. На многу едноставен начин може да се зачуваат измени од кодот преку Git алатката и да се управува со верзии на кодот. Секое репо може да има неколку гранки во кои на една од нив се развива целата апликација и во иднина може да се креираат дополнителни гранки за нови фукнционалности. Тоа ни олеснува да пристапиме до некоја постара верзија на апликациајта каде што нема дополнителни функционалности кои не се потребни. Во процесот на развој ја користев гранката develop и потоа кодот ја пресликав на главната гранка master. Кога завршив со развојот направив пресликување на целото репо во проектиот простор на факултет каде може да го добиете изворот од кодот и логови за направени измени. Дополнително апликацијата ја хостирав на сервер за тестирање кој што ќе биде опишан во делот "Презентација". 23 Иницијалното репо за апликацијата го креирав на Github [https://docs.github.com/en/get-started/quickstart/hello-world] платформата за хостирање или зачувување на код. Преку интерфејсот на Github ја добиваме истата структура на апликацијата која ја развиваме. На многу едноставен начин може да се зачуваат измени од кодот преку Git алатката и да се управува со верзии на кодот. Секое репо може да има неколку гранки во кои на една од нив се развива целата апликација и во иднина може да се креираат дополнителни гранки за нови фукнционалности. Тоа ни олеснува да пристапиме до некоја постара верзија на апликациајта каде што нема дополнителни функционалности кои не се потребни. Во процесот на развој ја користев гранката develop и потоа кодот ја пресликав на главната гранка master. Кога завршив со развојот направив пресликување на целото репо во проектиот простор на факултет каде може да го добиете изворот од кодот и логови за направени измени. Дополнително апликацијата ја хостирав на сервер за тестирање кој што ќе биде опишан во делот "Презентација".\\ 24 24 Линк до изворниот код: **[https://develop.finki.ukim.mk/projects/SaveSpace/browser Извор - SaveSpace]** 25 25 … … 32 32 Структурата на датотеките во Laravel е по избор корисникот но за да е во тек со други апликации и разбирлива за другите добро е да се воздржиме на класичната MVC структура. Model-View-Controller (MVC) [https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduction.htm] е модел кој ја дели апликацијата на три главни логички компоненти: модел, приказ и контролер. Секоја од овие компоненти е изградена за да се справи со специфични развојни аспекти на апликацијата. MVC е една од најчесто користените индустриски стандардни рамки за развој на веб за креирање скалабилни и проширливи проекти. 33 33 34 Модел 34 Модел\\ 35 35 Компонентата Модел одговара на целата логика поврзана со податоци со која работи корисникот. Ова може да ги претставува или податоците што се пренесуваат помеѓу компонентите Приказ и контролер или кои било други податоци поврзани со деловната логика. На пример, објектот Customer ќе ги преземе информациите за клиентот од базата на податоци, ќе манипулира со нив и ќе ги ажурира податоците назад во базата на податоци или ќе ги користи за прикажување податоци. 36 36 37 Приказ 37 Приказ\\ 38 38 Компонентата View се користи за целата логика на UI на апликацијата. На пример, приказот на клиентите ќе ги вклучи сите компоненти на корисничкиот интерфејс, како што се текстуални полиња, паѓачки склопки, итн. со кои ќе комуницира конечниот корисник. 39 39 40 Контролер 40 Контролер\\ 41 41 Контролерите дејствуваат како интерфејс помеѓу компонентите на Model и View за да ја обработат целата деловна логика и дојдовните барања, да манипулираат со податоците користејќи ја компонентата Model и да комуницираат со Views за да го прикажат конечниот излез. На пример, контролорот на клиентите ќе се справи со сите интеракции и влезови од Приказот на клиентите и ќе ја ажурира базата на податоци користејќи го моделот на клиентите. Истиот контролер ќе се користи за прегледување на податоците на клиентот. 42 42 … … 45 45 .php е местото каде што можете да ги регистрирате сите канали за емитување настани што ги поддржува вашата апликација. Storage директориумот за складирање ги содржи сите компајлирани шаблони како и конфигурацијата за зачувување на датотеки. Директориумот на апликации може да се користи за складирање на сите датотеки генерирани од вашата апликација. Рамковниот директориум се користи за складирање на датотеки и кешови генерирани од рамка. Конечно, директориумот за дневници ги содржи датотеките за дневници на вашата апликација.Vendor директориумот ги содржи сите зависности од Composer [https://getcomposer.org/] кој што претставува управуавач на зависносни пакети во PHP. Поголемиот дел од вашата апликација е сместена во директориумот App кој содржи дополнителни директориуми како што се Console, Http и Providers. Во директориумот Console додадов clearAll класа која што како една команда ми заменува четири команди во исто време за чистење на кеш и конфигурација на апликацијата. Директориумот Http ги содржи контролерите, конфигурацијата за автентикација и валидациските класи за моделите. Речиси целата логика за справување со барањата кои влегуваат во апликацијата се запишани во овој директориум. Директориумот Models ги содржи сите класи на Eloquent модели. Eloquent ORM [https://laravel.com/docs/8.x/eloquent] вклучен во Laravel обезбедува едноставна имплементација за работа со базата на податоци. Секоја табела со база на податоци има соодветен „модел“ кој се користи за интеракција со таа табела. Директориумот Notifications иницијално не постои, но се креира автоматски ако ја извршите командата Artisan make:notification. Истиот ги содржи сите известувања што ги испраќа апликацијата, како што се едноставни известувања за настани што се случуваат во апликацијата. Во конкретниот пример праќам нотификација за промена или заборавена лозинка, верификација на кориснички профил, промена на е-адреса како и OTP код за верификација на најавата преку маил. 46 46 47 [[Image(app_structure.png)]] 47 48 48 49 … … 50 51 51 52 == Имплементациски дијаграм 52 53 53 54 54 … … 62 62 Тука првпат спомнувате MVC, треба да објасните што е тоа во една реченица, како што правевте и поопсежно на други места, и да дадете референца. 63 63 }}} 64 {{{#!rbox type=comment 65 Додадов објаснување за MVC погоре 66 }}} 67 64 68 Во MVC системот моделот е класа која се состои од податоци запишани во одредена табела во база. View го претставува интерфејсот преку кој корисникот комуницира со апликацијата. Кога корисникот презема акција, Controller се справува со акцијата и ги ажурира податоците во база преку моделот доколку е потребно. 65 69 … … 67 71 Некои реченици се нејасно напишни, да се рефразира. 68 72 }}} 69 Во Laravel, моделот обично е класа со променливи што одговараат на колоните во базата на податоци т.е. променливите кои се дефинирани во Migrations во одредена табела. Контролерите се одговорни за завршување на корисничките дејства и за управување со деловната логика на апликацијата. Рутирањето на ресурсите во Laravel ги доделува „CRUD“ операциите или функциите дефинирани во контролерот со една линија код. 70 71 Ќе започнам со објаснување на начинот на најава и автентикација во апликацијата. За автентикација се користи Middleware кој обезбедува механизам за проверка и филтрирање на HTTP барањата на апликацијата. Laravel вклучува софтвер кој потврдува дека корисникот е автентициран. Ако корисникот не е автентициран, ќе го пренасочи корисникот на екранот за најава. Меѓутоа, ако корисникот е автентициран, ќе дозволи барањето да продолжи да се процесира. Освен базичните класи за автентикација кои ни ги овозможува Laravel во Middleware директориумот ги додаваме сите проверки кои му дозволуваат на корисникот да се автентицира. 73 {{{#!rbox type=comment 74 Тргнат е параграфот, додадов објаснување погоре 75 }}} 76 77 Ќе започнам со објаснување на начинот на најава и автентикација во апликацијата. За автентикација се користи Middleware [https://laravel.com/docs/8.x/lifecycle] кој претставува механизам за проверка и филтрирање на HTTP барањата на апликацијата. Laravel вклучува софтвер кој потврдува дека корисникот е автентициран. Ако корисникот не е автентициран, ќе го пренасочи корисникот на екранот за најава. Меѓутоа, ако корисникот е автентициран, ќе дозволи барањето да продолжи да се процесира. Освен базичните класи за автентикација кои ни ги овозможува Laravel во Middleware директориумот ги додаваме сите проверки кои му дозволуваат на корисникот да се автентицира. 72 78 73 79 На пример, во апликацијата предуслов за најава е да се креира лозинка за да се активира профилот на корисникот. Laravel го олеснува начинот на заштитата на апликацијата од напади за не верифицирани барања меѓу страници со помош на CSRF. Laravel автоматски генерира CSRF „токен“ за секоја активна корисничка сесија управувана од апликацијата. Овој токен се користи за да се потврди дека автентицираниот корисник е тој што всушност ги поставува барањата до апликацијата. Во секоја форма преку која праќаме HTTP барање потребно е да се додаде и CSFR токенот. 80 81 За секој повик за автентикација потребен е параметарот token кој означува уникатен идентификатор на корисничкиот профил преку кој корисникот се автентицира и праќа барања до серверот. 74 82 75 83 {{{ … … 94 102 95 103 ''Листа на рути за автентикација'' 96 97 Како што може да се види за секој повик за автентикација потребен е параметарот token кој означува уникатен идентификатор на корисничкиот профил преку кој корисникот се автентицира и праќа барања до серверот.98 104 99 105 {{{ … … 195 201 196 202 197 198 199 203 === Управување со оддели 200 204 … … 202 206 Најдобро прво објаснение, а потоа пример, а не обратно. Свртете ги обратно и сменете го и објаснувањето во текстот да е соодветно. 203 207 }}} 204 208 {{{#!box type=comment 209 Корегирано 210 }}} 211 212 Класата Department во која се дефинирани сите променливи кои претходно ги запишав во датотеката за миграција на табелата 213 "departments". Во класата се дефинираат и релации помеѓу два или повеке модели. Во кодот е дефинирана релација помеѓу Department и Folder моделот каде што се означува дека еден оддел може да има неколку фолдери. Може да се дефинираат и методи кои влечат одредени податоци од истиот модел како што е методот getCreatedByName() кој го наоѓа корисничкото име од User моделот и истиот може потоа да се прикаже во интерфејс на апликацијата преку класата Department.\\ 205 214 206 215 {{{ … … 230 239 ''Department моделот'' 231 240 232 Во горенаведениот код се запишани променливите кои претходно биле дефнирани во табелата Departments. Исто така во овој дел се дефинираат и релации помеѓу два или повеке модели. Во конкретниот случај е дефинирана релација помеѓу Department и Folder моделот каде што се означува дека еден оддел може да има неколку фолдери. Може да се дефинираат и методи кои влечат одредени податоци од истиот модел како што методот getCreatedByName() кој го наоѓа корисничкото име од User модел-от и истиот може потоа да се прикаже во интерфејс на апликацијата преку класата Department.241 Основниот метод index од контролерот DepartmentsController се повикува кога рутата /departments е вчитана со методот GET HTTP. Во овој метод, ние ги преземаме сите достапни податоци во табелата за оддели користејќи го моделот Department и го пренесуваме во интерфејсот како променлива. Ова значи дека во интерфејсот, променливата $departments ќе може да се користи за да се прикажат податоци од колекцијата која ги состои сите оддели. 233 242 234 243 {{{ … … 243 252 ''Метод од контролерот DepartmentsController за приказ на сите оддели запишани во база'' 244 253 245 Методот index се повикува кога рутата /departments е вчитана со методот GET HTTP. Во овој метод, ние ги преземаме сите достапни податоци во табелата за оддели користејќи го моделот Department и го пренесуваме во интерфејсот како променлива. Ова значи дека во интерфејсот, променливата $departments ќе може да се користи за да се прикажат податоци од колекцијата која ги состои сите оддели.254 Секој повик во Laravel потребно е да има посебна рута. Рутата со име index ја дефинирав посебно за да се ограничи пристапот за корисници кои имаат ролја во која не е дозволено да управуваат со оддели. Рутата store служи за креирање на нов оддел. Методот во оваа рута секогаш треба да е post затоа што се запишуваат нови податоци т.е. се креира нов оддел. Методот patch се повикува кога се прави ажурирање на податоците во база за веќе креиран оддел што во овој случај е рутата со име edit. На двете рути за да прикажат и ажурираат оддел потребно им е да се додели вредност id која според id-то во база ќе го најде конкретниот оддел. 246 255 247 256 {{{ … … 260 269 ''Листа на рути за оддели'' 261 270 262 Секој повик во Laravel потребно е да има посебна рута. Рутата со име index ја дефинирав посебно за да се ограничи пристапот за корисници кои имаат ролја во која не е дозволено да управуваат со оддели. Рутата store служи за креирање на нов оддел. Методот во оваа рута секогаш треба да е post затоа што се запишуваат нови податоци т.е. се креира нов оддел. Методот patch се повикува кога се прави ажурирање на податоците во база за веќе креиран оддел што во овој случај е рутата со име edit. На двете рути за да прикажат и ажурираат оддел потребно им е да се додели вредност id која според id-то во база ќе го најде конкретниот оддел.271 Методот store како влезен параметар има објект од класата NewDepartmentRequest каде што се прави валидацијата на променливите од моделот Department кога тие ќе стигнат преку HTTP барањето преку формата која претходно ја пополнувал корисникот во интерфејсот на апликацијата. Почнуваме со креирање на нов објект од класата Department и сите параметри кои треба да се запишат во база за тој оддел ќе бидат еднакви на тие што доаѓаат од повикот. При креирање на одделот за истиот креираме и фолдер во сервер за зачувување на датотеките. Името на фолдер-от го одредува кодот кој го доделуваме на новиот оддел а локацијата на фолдер-от ја зачувуваме во променлива. На крај го зачувуваме одделот и прикажуваме порака на корисникот дали во таа сесија поминало барањето или не. Доколку има грешки се прикажуваат валидациски пораки. Последен чекор е да се вратиме на почетниот екран. 263 272 264 273 {{{ … … 290 299 ''Метод од контролерот DepartmentsController за креирање на нов оддел'' 291 300 292 Како што може да се види и во кодот методот како влезен параметар има објект од класата NewDepartmentRequest каде што се прави валидацијата на променливите од моделот Department кога тие ќе стигнат преку HTTP барањето преку формата која претходно ја пополнувал корисникот во интерфејсот на апликацијата. Почнуваме со креирање на нов објект од класата Department и сите параметри кои треба да се запишат во база за тој оддел ќе бидат еднакви на тие што доаѓаат од повикот. При креирање на одделот за истиот креираме и фолдер во сервер за зачувување на датотеките. Името на фолдер-от го одредува кодот кој го доделуваме на новиот оддел а локацијата на фолдер-от ја зачувуваме во променлива. На крај го зачувуваме одделот и прикажуваме порака на корисникот дали во таа сесија поминало барањето или не. Доколку има грешки се прикажуваат валидациски пораки. Последен чекор е да се вратиме на почетниот екран.301 Методот во класата Alert е креиран за да му прикаже соодветна порака според одговорот од серверот кога не поминува валидацијата која ќе му ја олесни работата на корисникот во моментот кога нема да помине барањето поради грешка при валидација на податоците или друг проблем. За приказ на пораките користев Тоаst JS [11]. 293 302 294 303 {{{ … … 307 316 ''Класата Alert за приказ на пораки од сесија'' 308 317 309 Методот во класата алерт е креиран за да му ја олесни работата на корисникот во моментот кога нема да помине барањето поради грешка при валидација на податоците или друг проблем. За приказ на пораките користев Тоаst JS [11].318 Во првиот дел проверувам дали има грешка и ја враќаме пораката од сесија и типот го поставуваме да е секогаш грешка за да биде соодветно на пораката додека во вториот дел проверувам дали во сесија има објект alert т.е. дали се враќа одговор од серверот и ја прикажувам пораката и типот на одговорот според сесија. 310 319 311 320 {{{ … … 336 345 ''Интерфејсот за приказ на пораките'' 337 346 338 Во првиот дел проверуваме дали има грешка и ја враќаме пораката од сесија и типот го поставуваме да е секогаш грешка за да биде соодветно на пораката додека во вториот дел проверувам дали во сесија има објект alert т.е. дали се враќа одговор од серверот и ја прикажуваме пораката и типот на одговорот според сесија.347 Со помош на методот edit може да се смени името на одделот или кодот. Во случај кога ќе се прави измена во кодот потребно е името на фолдерот каде што се наоѓаат сите датотеки од тој оддел да се преименува. Со таа цел преку функцијата isDirty() со која може да се дознае дали моделот е уреден пред да се запише во база проверувам дали има промена и доколку има прво го поместуваме одделот во нов директориум а потоа во две итерации ги изминуваме сите фолдери и датотеки и нивните патеки во база ги заменуваме со новата. На крај ги зачувуваме и прикажувам соодветна порака за извршена акција како и го враќам корисникот во страницата со сите оддели. 339 348 340 349 {{{ … … 380 389 ''Метод од контролерот DepartmentsController за уредување на оддел'' 381 390 382 Со помош на методот edit може да се смени името на одделот или кодот. Во случај кога ќе се прави измена во кодот потребно е името на фолдерот каде што се наоѓаат сите датотеки од тој оддел да се преименува. Со таа цел преку функцијата isDirty() со која може да се дознае дали моделот е уреден пред да се запише во база проверувам дали има промена и доколку има прво го поместуваме одделот во нов директориум а потоа во две итерации ги изминуваме сите фолдери и датотеки и нивните патеки во база ги заменуваме со новата. На крај ги зачувуваме и прикажувам соодветна порака за извршена акција како и го враќам корисникот во страницата со сите оддели.391 Покрај уредување на оддел корисникот со привилегии администратор или референт има можност да избрише еден оддел што значи да се одстранат сите записи од база како и сите фолдери и датотеки за истиот. Корисникот има можност да го избрише одделот само ако тој оддел е празен т.е. доколку во него не постои ниту еден фолдер. Во спротивно, се фрла порака дека тој оддел има асоцирани фолдери со него и не ја дозволува акцијата да се изврши. 383 392 384 393 {{{ … … 404 413 ''Метод од контролерот DepartmentsController за бришење на оддел'' 405 414 406 Покрај уредување на оддел корисникот со привилегии администратор или референт има можност да избрише еден оддел што значи да се одстранат сите записи од база како и сите фолдери и датотеки за истиот. Корисникот има можност да го избрише одделот само ако тој оддел е празен т.е. доколку во него не постои ниту еден фолдер. Во спротивно, се фрла порака дека тој оддел има асоцирани фолдери со него и не ја дозволува акцијата да се изврши.415 За потребите на компанијата додаден е метод за симнување на сите фолдери со нивните датотеки од еден оддел преку кој се креира zip кој ги содржи сите фолдери од еден оддел со истата структура како што се тие запишани на сервер. На почеток проверуваме дали има празни фолдери со цел тие да ги игнорираме затоа што не содржат ниту една датотека.Класата RecursiveIteratorIterator која што е тип на итератор кој ни овозможува рекурзивно да ги поминеме сите патеки ми помогна да ги најдам потребните фолдери и датотеки. За разлика од обичен итератор кој пребарува низ листа RecursiveIteratorIterator може да се каже дека пребарува низ дрво и ја олеснува работата кога се работи за неколку патеки во еден директориум. За секоја пронајдена датотека ја добиваме патеката од Storage и ја додаваме во zip. На крај ја симнуваме датотеката со доделено име, прикажуваме соодветна порака и се враќаме назад. Во овој дел клуч е патеката која ја запишувам при креирање на оддел. На истиот начин направив и функција за симнување на сите оддели со нивните фолдери и датотеки при што се игнорираат празните оддели и фолдери. 407 416 408 417 {{{ … … 450 459 ''Метод од контролерот DepartmentsController за симнување на фолдери и датотеки од оддел'' 451 460 452 За потребите на компанијата додаден е метод за симнување на сите фолдери со нивните датотеки од еден оддел преку кој се креира zip кој ги содржи сите фолдери од еден оддел со истата структура како што се тие запишани на сервер. На почеток проверуваме дали има празни фолдери со цел тие да ги игнорираме затоа што не содржат ниту една датотека.Класата RecursiveIteratorIterator која што е тип на итератор кој ни овозможува рекурзивно да ги поминеме сите патеки ми помогна да ги најдам потребните фолдери и датотеки. За разлика од обичен итератор кој пребарува низ листа RecursiveIteratorIterator може да се каже дека пребарува низ дрво и ја олеснува работата кога се работи за неколку патеки во еден директориум. За секоја пронајдена датотека ја добиваме патеката од Storage и ја додаваме во zip. На крај ја симнуваме датотеката со доделено име, прикажуваме соодветна порака и се враќаме назад. Во овој дел клуч е патеката која ја запишувам при креирање на оддел. На истиот начин направив и функција за симнување на сите оддели со нивните фолдери и датотеки при што се игнорираат празните оддели и фолдери.453 454 455 456 457 461 458 462 === Корисници и уредување на кориснички податоци 459 463 460 464 Секој корисник има можност да ги промени своите податоци за профилот како и администраторот има можност да ги промени податоците за секој корисник и да додаде нови. Исто така секој корисник има можност да ги менува е-адресата, корисничкото име или лозинката. Дополнително администраторот има можност да постави валидациски правила за прикачување на нови датотеки. Ќе започнам со објаснување на контролерот UsersController преку кој се креираат нови корисници или се менуваат кориснички податоци. 465 466 Рутата за приказ на корисници е посебно дефинирана со цел да се овозможи пристап за корисници од различни ролји т.е. референтот да има можност да ја види листата со корисници но да нема можност да управува со нив. 461 467 462 468 {{{ … … 475 481 ''Листа на рути за управување со корисници'' 476 482 477 Рутата за приказ на корисници е посебно дефинирана со цел да се овозможи пристап за корисници од различни ролји т.е. референтот да има можност да ја види листата со корисници но да нема можност да управува со нив.483 Додавање на нов корисник оди преку методот store кој како параметар го прима барањето кое ќе го валидира според правилата дефинирани во NewUserRequest класата. Некои од податоците за кои не им се доделува вредност при креирање креирав методи во User моделот за генерирање на random вредности со цел за да помине валидацијата на тие задолжителни полиња како на пример што е generateTemporaryPassword() методот. За корисникот исто така може да се додаде слика која ја зачувуваме во сервер. На крај се зачувува корисникот и се праќа нотификација од класата WelcomeUser() преку која праќаме е-пошта до новиот корисник за креирање на нова лозинка со што корисникот ќе има активен профил и ќе може да се најави. На сличен начин работи и контролерот за уредување на кориснички податоци. За разлика од креирање во тој дел доколку се промени е-адресата на корисникот се генеира нов токен за верификација како и безбедносен код и се праќаат до корисникот со цел да го верифицира истиот и да може да се најави пак во системот. 478 484 479 485 {{{ … … 527 533 ''Методи на контролерот UsersController за приказ и креирање на корисници'' 528 534 529 До давање на нов корисник оди преку методот store кој како параметар го прима барањето кое ќе го валидира според правилата дефинирани во NewUserRequest класата. Некои од податоците за кои не им се доделува вредност при креирање креирав методи во User моделот за генерирање на random вредности со цел за да помине валидацијата на тие задолжителни полиња како на пример што е generateTemporaryPassword() методот. За корисникот исто така може да се додаде слика која ја зачувуваме во сервер. На крај се зачувува корисникот и се праќа нотификација од класата WelcomeUser() преку која праќаме е-пошта до новиот корисник за креирање на нова лозинка со што корисникот ќе има активен профил и ќе може да се најави. На сличен начин работи и контролерот за уредување на кориснички податоци. За разлика од креирање во тој дел доколку се промени е-адресата на корисникот се генеира нов токен за верификација како и безбедносен код и се праќаат до корисникот со цел да го верифицира истиот и да може да се најави пак во системот.535 Доколку еден корисник не работи веќе во фирмата тоа значи дека истиот не смее да се најави веќе во системот. Со таа намена методот block го менува статусот на корисникот од активен во не активен и не му дозволува да се најави во системот. На ист начин може и да се деблокира еден корисник. 530 536 531 537 {{{ … … 552 558 ''Методот за блокирање на корисник'' 553 559 554 Доколку еден корисник не работи веќе во фирмата тоа значи дека истиот не смее да се најави веќе во системот. Со таа намена методот block го менува статусот на корисникот од активен во не активен и не му дозволува да се најави во системот. На ист начин може и да се деблокира еден корисник.560 Со помош на методот editUserData секој најавен корисник има можност да си ги менува своите лични кориснички податоци како име, презиме, мобилен број или слика. 555 561 556 562 {{{ … … 585 591 ''Метод за промена на личните кориснички податоци'' 586 592 587 Преку методот editUserData секој најавен корисник има можност да си ги менува своите лични кориснички податоци како име, презиме, мобилен број или слика.593 Администраторот на апликацијата има можност да избрише корисник со користење на методот destroy. При бришење во истиот момент је отстранува и сликата од профилот на корисникот од сервер како и сите податоци за него во база. Притоа, еден корисник може да се избрише само доколку нема асоцирани фолдери во него т.е. доколку тој корисник никогаш не додал фолдери и датотеки во одреден оддел. 588 594 589 595 {{{ … … 613 619 ''Метод за бришење на корисник'' 614 620 615 Администраторот на апликацијата има можност да избрише корисник со користење на методот destroy. При бришење во истиот момент је отстранува и сликата од профилот на корисникот од сервер како и сите податоци за него во база. Притоа, еден корисник може да се избрише само доколку нема асоцирани фолдери во него т.е. доколку тој корисник никогаш не додал фолдери и датотеки во одреден оддел.621 Преку методот updateUsername корисникот има можност да го промени своето корисничко име. Методот како параметар го добива барањето кое ќе биде валидирано според правилата поставени во UsernameSettingsRequest. По завршена акција корисникот се одјавува. Доколку се промени е-адресата тој исто така добива и порака по е-пошта за потврда на новата со цел да може да се најави пак. На ист начин работи и методот за промена на лозинка. 616 622 617 623 {{{ … … 634 640 ''Метод за промена на корисничко име во SettingsController контролерот'' 635 641 636 Преку методот updateUsername корисникот има можност да го промени своето корисничко име. Методот како параметар го добива барањето кое ќе биде валидирано според правилата поставени во UsernameSettingsRequest. По завршена акција корисникот се одјавува. Доколку се промени е-адресата тој исто така добива и порака по е-пошта за потврда на новата со цел да може да се најави пак. На ист начин работи и методот за промена на лозинка.642 Валидациските правила се зачувуваат во база во еден ред од посебна табела и истите потоа се превземаат при валидација за прикачување на датотеки. Администраторот има можност да ги дефинира сите дозволени типови на датотеки кои можат да се прикачат како и максималната големина по датотека. 637 643 638 644 {{{ … … 663 669 ''Метод за промена на валидациски правила во SettingsController контролерот'' 664 670 665 В алидациските правила се зачувуваат во база во еден ред од посебна табела и истите потоа се превземаат при валидација за прикачување на датотеки. Администраторот има можност да ги дефинира сите дозволени типови на датотеки кои можат да се прикачат како и максималната големина по датотека.671 Во долниот дел од кодот од FolderRequest класата за валидација на нов фолдер може да се забележи дека во mimes се запишуваат типови на датотеки кои администраторот претходно ги дефинирал преку методот fileTypes(). Прво го наоѓаме првиот ред од база од класата FileType и неговите податоци ги поставуваме како валидациски правила. 666 672 667 673 {{{ … … 684 690 ''Дел од кодот за валидација на датотеки'' 685 691 686 Во овој дел од FolderRequest класата за валидација на нов фолдер може да се забележи дека во mimes се запишуваат типови на датотеки кои администраторот претходно ги дефинирал преку методот fileTypes(). Прво го наоѓаме првиот ред од база од класата FileType и неговите податоци ги поставуваме како валидациски правила.687 688 689 690 691 692 692 693 === Управување со фолдери и датотеки 694 695 Рутата со име dashboard.folders.files се користи за приказ на сите датотеки за одреден фолдер според query параметарот кој е id од избраниот фолдер. Рутите create и store се користат за креирање на нов фолдер додека рутата uploadFiles за прикачување на нови датотеки во веќе креиран фолдер. 693 696 694 697 {{{ … … 709 712 ''Рути за управување со фолдери'' 710 713 711 Рутата со име dashboard.folders.files се користи за приказ на сите датотеки за одреден фолдер според query параметарот кој е id од избраниот фолдер. Рутите create и store се користат за креирање на нов фолдер додека рутата uploadFiles за прикачување на нови датотеки во веќе креиран фолдер. 714 За разлика од другите index методи тука дополнително правам сортирање по query параметри и ги подредувам фолдерите според селекцијата која ја прави во интерфејсот. Сите податоци се прикажуваат и полнат на истата страница и со таа цел пред да ја враќам колекцијата и да ја прикажам на фронтенд ги правам сите можни проверки за сортирање. Исто така, освен сортирање на главната страница со сите фолдери правам и сортирање на фолдери од еден оддел кога пристапува корисникот до избран оддел преку навигацискиот панел. Исто така правам калкукација на тоа колку простор е зафатен во дискот на сервер преку функцијата disk_total_space која ја враќа вкупната зафатеност на дискот или одредена партиција каде што работи апликацијата. Преку фунцијата paginate() која како параметар прима број на објекти по страница Laravel креира страници кои исто така преку query параметри прават филтрирање и ги листаат објектите по даден број во различни страници. 712 715 713 716 {{{ … … 798 801 ''Метод од контролерот FoldersController за приказ на фолдери'' 799 802 800 За разлика од другите index методи тука дополнително правам сортирање по query параметри и ги подредувам фолдерите според селекцијата која ја прави во интерфејсот. Сите податоци се прикажуваат и полнат на истата страница и со таа цел пред да ја враќам колекцијата и да ја прикажам на фронтенд ги правам сите можни проверки за сортирање. Исто така, освен сортирање на главната страница со сите фолдери правам и сортирање на фолдери од еден оддел кога пристапува корисникот до избран оддел преку навигацискиот панел. Исто така правам калкукација на тоа колку простор е зафатен во дискот на сервер преку функцијата disk_total_space која ја враќа вкупната зафатеност на дискот или одредена партиција каде што работи апликацијата. Преку фунцијата paginate() која како параметар прима број на објекти по страница Laravel креира страници кои исто така преку query параметри прават филтрирање и ги листаат објектите по даден број во различни страници. 803 Начинот на креирање на фолдер е идентичен со тој на оддел. За разлика од првиот тука при креирање на избор потребно е фолдерот да има асоциран оддел како и архивски број според избраниот оддел кој автоматски ќе му биде препопулиран по избор. Исто така дополнително има можност за прикачување на датотеки кои ќе бидат асоцирани со ново креираниот фолдер. Во кодот може да се забележи дека се проверува дали постои фолдер во база со исто име или архивски број. Доколку постои само едното се враќа порака за грешка и доколку се исти двете полиња се креира нова верзија за веќе постоечкиот фолдер. За секој нов фолдер се креира папка на сервер според локацијата на одделот и во неја ги зачувувам сите додадени датотеки. Архивскиот број се состои од: "код од одделот" + "/" + "внесува корисникот". Истата логика се валидира во класата FolderRequest на следниот начин: 801 804 802 805 {{{ … … 872 875 }}} 873 876 874 '' Потребни методиза креирање на нов фолдер''875 876 Начинот на креирање на фолдер е идентичен со тој на оддел. За разлика од првиот тука при креирање на избор потребно е фолдерот да има асоциран оддел како и архивски број според избраниот оддел кој автоматски ќе му биде препопулиран по избор. Исто така дополнително има можност за прикачување на датотеки кои ќе бидат асоцирани со ново креираниот фолдер. Во кодот може да се забележи дека се проверува дали постои фолдер во база со исто име или архивски број. Доколку постои само едното се враќа порака за грешка и доколку се исти двете полиња се креира нова верзија за веќе постоечкиот фолдер. За секој нов фолдер се креира папка на сервер според локацијата на одделот и во неја ги зачувувам сите додадени датотеки. Архивскиот број се состои од: "код од одделот" + "/" + "внесува корисникот". Истата логика се валидира во класата FolderRequest на следниот начин: 877 ''Метод за креирање на нов фолдер'' 878 879 Во методот rules() може да се забележи дека се прави валидација на архивскиот број со цел да се провери дали е тој правилно внесен т.е. дали се состои од кодот на одделот како и внесениот број од страна на корисникот и доколку не е се фрла исклучок. Валидација на низата од датотеки се прави според внесените валидациски правила од страна на администраторот. 877 880 878 881 {{{ … … 932 935 933 936 ''Валидација на полињата за креирање на нов фолдер'' 934 935 Тука може да е забележи дека се прави валидација на архивскиот број со цел да се провери дали е тој правилно внесен т.е. дали се состои од кодот на одделот како и внесениот број од страна на корисникот и доколку не е се фрла исклучок. Валидација на низата од датотеки се прави според внесените валидациски правила од страна на администраторот.
