Laravel: Walidacja danych

5.8.x

0:00Zajmijmy się teraz wyświetlaniem błędów. Powiem

0:04ci od razu jak to wygląda. Czyli my tutaj mamy formularz który po wysłaniu przesyła

0:08się do tego kontrolera. On się przesyła konkretnie do metody register

0:12którą można podejrzeć, na tym RegisteredUsers, niemniej skupimy się na tym co

0:16jest tutaj. Jak możesz się domyślić tylko patrząc na ten kod, nawet jeszcze nie

0:20rozumiejąc czym jest walidator, można się domyślić że tutaj są walidowane

0:25dane, które są wejściowe. Teraz mamy name, email i password.

0:29Skąd to bierze? Zauważ, że ja już wcześniej w formularzu ustawiłem odpowiednie atrybuty

0:34name i one są Tutaj absolutnie kluczowe, czyli jeżeli tutaj mamy email, name

0:38i password to się musi zgrywać z tym co jest tutaj i z tym co jest

0:42później tutaj, czyli innymi słowy jeszcze tak szybko, tutaj jest pewna metoda walidator,

0:46która jeżeli przejdzie odpowiednio wszystkie walidacje.

0:50Jeżeli dane będą poprawne to pozwoli na przyjście do metody create, która tworzy

0:54nowego użytkownika, bo tym polega rejestracja i zauważ, że tutaj nie ma nic skomplikowanego. Mamy

0:59po prostu odwołanie do modelu, czyli do eloquent model i wykonujemy

1:04na nim metody create, która pozwoli nam utworzyć właśnie nowego użytkownika. W

1:08podobny sposób będziemy później tworzyć na przykład posty, czyli tutaj nie ma specjalnie

1:12skomplikowanego jeżeli chodzi o samą rejestracje, po prostu tworzymy użytkownika

1:16i podajemy mu już zwalidowane dane. Jeżeli chodzi o Hash::make, to

1:21to z kolei pozwoli utworzyć hasło zapisane w Bcrypt, czyli

1:25będzie on po prostu zahaszowany w odpowiedni sposób i zapisany bazie danych i za każdym razem

1:29kiedy się logujemy będzie ono porównywane również za pomocą takiej

1:33funkcji Bcrypt, czyli tutaj teraz możesz zobaczyć, że mamy

1:37walidator, ale on oczekuje właśnie że będzie tam name, email czy password i to

1:41się musi zgrywać z tym podaliśmy tutaj, więc jeżeli teraz wysyłamy ten formularz

1:45to wszelkie pola które tutaj są z takimi nazwami przesyłają się

1:49tutaj i zauważ, że name jest walidowane w następujący sposób, required to

1:54jest pierwsza reguła walidacji. Czyli musi być coś podane. Jeśli coś jest

1:58podane to przechodzimy na drugiej reguły, to musi być string i maksymalnie

2:02255 znaków, dlatego że również ogranicza nas do 255 znaków

2:06kolumna w bazie danych. Następnie email jest wymagany,

2:11musi to być string, musi to być również email, więc laravel ma wbudowaną walidację

2:15poprawności email'a. Max 255 i co ciekawe unique:users. To

2:20jest tutaj ciekawa reguła walidacji. Ona oznacza, że email musi

2:24być unikalny, w tabeli users. Teraz tabela już zaraz będzie determinowana

2:29przez to co mamy tutaj w migracjach czyli database migrations i mamy create_users_table. To

2:35już dla nas było wcześniej, czyli będzie tam w tej tabeli kolumna email. Tabela

2:39nazywa się users, więc reguła walidacji mówi po prostu, że w tabeli users

2:44kolumna email ma być unikalna, czyli jeżeli

2:48będziemy drugi raz jej dodać takiego samego użytkownika to tutaj ta walidacja nie

2:52przejdzie. No i hasło jest wymagane, musi to być string minimum 8 znaków i potwierdzony. Jest

2:57więcej takich reguł walidacji, my się tym jeszcze później będziemy zajmować, więc pokażę ci je dokumentacji

3:02laravela wówczas. Okej, natomiast co teraz

3:06dzieje się, jeżeli ta walidacja nie przejdzie, bo na naszej stronie wydaje się że nic

3:10takiego się nie wydarzyło. Natomiast to wydarza się bo okazuje się że jest do widoku

3:14zwracany dla nas automatycznie obiekt error, errors i

3:18w zasadzie jest to taka zmienna i ta zmienna jest pewnego obiektem,

3:23który ma kilka metod i możemy z niego wyłuskać błędy. Gdybyśmy

3:27sobie tutaj na przykład spróbowali zrobić coś takiego, php, to jest nowy

3:32dla ciebie pewnie zapis &php, w ten sposób możemy widokach

3:36blade wpisać sobie jakiś dowolny kod PHP. Mamy w laraverze

3:40taką globalną funkcję jak die dump. Jeżeli teraz wpiszemy errors,

3:44czyli ta zmienna o której mówiłem że powinna być dostępna, to te błędy nam się powinny w

3:48taki fajny sposób wyświetlić i okazuje się, że rzeczywiście jest to jakaś klasa. Te błędy tutaj

3:53się znalazły i możemy zobaczyć, że mamy na przykład name

3:57i mamy wiadomość, mamy email, mamy password. Natomiast

4:01ja ci pokażę od razu w jaki sposób można skorzystać z tego obiektu. Będziemy

4:06chcieli w tym miejscu dodawać klasę is-invalid i jeżeli wystąpią

4:10jakieś błędy. I teraz możemy to zrobić następujący sposób. Od

4:14razu sobie tutaj otworzę znacznik blade i będę chciał zrobić sprawdzenie, jeżeli

4:19errors, tutaj na tym obiekcie jest taka metoda jak has, email, czyli

4:25dokładnie to koresponduję z tą nazwą która jest tutaj. No i oczywiście z tym co mieliśmy w tym

4:29miejscu, czyli jeżeli błędy jakby zawierają w sobie email to wtedy chciałbym

4:33tutaj wyświetlić spację bo muszimy tutaj spację dopisać is-invalid. W

4:39przeciwnym wypadku chcę tutaj dać pusty string, czyli w nic. Teraz, jeżeli

4:44sobie to skopiujemy i wstawimy również w pozostałe miejsca, tylko tutaj podmieni na name,

4:48a w tym miejscu podmienimy na password to

4:54powinno to już zacząć fajnie wyglądać. Zobaczmy, przyjdziemy

4:59tutaj tak, wszyscy mamy i okazuje się, że pola podświetlane. Jeżeli

5:03tutaj cokolwiek wpisze to to pole będzie już wtedy poprawne. Natomiast jeszcze

5:07jedna rzecz o której zapomniałem powiedzieć. Mamy fajną regułę walidacji przy password. Jest

5:12to confirm i confirm to oznacza, że jeżeli mamy pole nazwie password,

5:16to oczekujemy, że jest jeszcze dodatkowe pole, które nazywa password podkreślnik

5:20confirmation i one muszą się ze sobą zgadzać, więc dlatego to pole

5:24ma dokładnie taką nazwę, password_confirmation. Jeżeli tutaj byś zmienił na

5:29coś innego, tutaj również musisz ten człon dostosować i wtedy po

5:33dostosowaniu tego tutaj confirmed będzie wiedziało w jaki sposób ma tych

5:37danych poszukiwać w jaki sposób je porównywać. Okej, czyli te błędy już

5:41wyświetlają, na koniec jeszcze ci pokażę jedną rzecz. Mamy tutaj zdefiniowane coś takiego

5:45jak redirectT o home. To oznacza, że jeżeli uda się zarejestrować

5:49użytkownika, to przekieruje nas do ścieżki home. Dlatego też laravel w lekcji poprzedniej

5:53dodał nam HomeController. U nas takiej ścieżki nie mam, dlatego będę chciał zamienić

5:58ją na prostu slash czyli naszą stronę główną i teraz spróbujemy sobie zarejestrować

6:02użytkownika, więc tutaj odświeżam. Wpiszemy sobie jakieś fejkowy

6:06email. Ja mam tutaj taki generator z użyciem alfreda. Dlatego,

6:11że ten mail nie musi być poprawny, tak naprawdę nie będziemy na razie tam nic wysyłać. Tutaj

6:16sobie wpiszę fake name, okej i

6:20hasło musi mieć minimum 8 znaków, więc sobie wpiszemy na przykład testowe hasło,

6:24wyślij i okazało

6:28się że udało się utworzyć takiego użytkownika i co ciekawe od razu jesteśmy

6:32również zalogowani. To jest bardzo istotne. Jeżeli byśmy

6:36sobie podejrzeli tutaj źródło naszej strony, przeszli do Application

6:40i następnie do Cookies to laravel_session oznacza

6:44że jesteśmy zalogowani. Tutaj jest zaszyfrowana sesja i za każdym razem teraz

6:49to ciasteczko jest przesyłane do serwera kiedy będziemy się łączyć z

6:53naszą stroną i po stronie serwera laravel może je sobie odszyfrować

6:57i może sprawdzić kto jest zalogowany czy jest zalogowany i

7:01tak dalej. Na tej podstawie będziemy mogli instancję użytkownika później uzyskiwać, ale

7:05o tym będzie później. Dodatkowo jeżeli podejrzymy sobie bazę danych i

7:09przejdziemy tutaj do users to możesz zauważyć że nowy użytkownik został

7:13utworzony i to stało dokładnie poprzez użycie User::create,

7:18kiedy udało się przejść przez wszystkie reguły walidacji.