![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 42 Pomógł: 0 Dołączył: 23.10.2009 Ostrzeżenie: (0%) ![]() ![]() |
Witam
Dopiero co raczkuje w PHP, na początek chciałem stworzyć skrypt walidujący prosty formularz. Dane przekazywane są z formularza w postaci dwóch tablic: required i optional. Mój problem polega na tym że po zatwierdzeniu formularza, wypełnione pola stają się na nowo puste, a staram się wymusić żeby tak nie było. Wszystko znajduje się w jednym pliku: skrypt:
formularz html:
Proszę o porady. |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 372 Pomógł: 2 Dołączył: 10.05.2009 Ostrzeżenie: (0%) ![]() ![]() |
szczerze nie wczytuje się w te funkcje, ale jeśli chcesz by po wypełnieniu formularza pola nie były puste musisz dodać w polach formularza np. tu:
Kod <td><input type="password" name="required[pass2]" id="pass2" maxlength="50"/></td> opcję value, w ten sposób: oczywiśćie przykład z hasłem nie najlepszy, ale to tylko przykład:) Ten post edytował lamcpp 29.10.2009, 00:29:51 |
|
|
![]()
Post
#3
|
|
![]() Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
Wszystko zależy od Twojego podejścia do formularza. Brak pliku w action sugeruje, że całość walidacji i przetwarzania jest wykonywana w tym samym pliku. Jeśli tak to znaczy, że po otworzeniu strony po raz pierwszy nie masz nic, ale jeśli dałeś Submit i jest to przeładowanie, to masz dostęp do zmiennej $_POST lub jej odpowiednika jeśli używasz programowania obiektowego i masz to w jakiś sposób w nim zaszyte. Jeśli jest to proste to rozwiązaniem jest pomysł kolegi, czyli wpisujesz do value zmienne POST. Jeśli robisz to obiektowo, to przekazujesz do formularza obiekt z wartościami domyślnymi value tych pól. Tyle, że po wciśnięciu Submit w owym obiekcie wartości domyślne zostają zastąpione wartościami z POST, przy czym w takiej sytuacji mogą one już być w postaci poprawionej przez system walidacji. Przykładowo:
Dałem Ci taki zarys jak by to mniej więcej mogło być proceduralnie rozwiązane. Zauważ, że przygotowuje sobie już tam grunt pod komunikaty błędów itp. A w zależności od tego czy ktoś posłał formularz, zmieniają się wartości pól. Oczywiście to tylko zgrubne, byś widział JAK by to mogło wyglądać, bo osobiście nieco bym tam pozmieniał pod kątem innego rozwiązania walidacji, systemu komunikatów błędów i kilku rzeczy ale poza tym sam szkielet jest już prawidłowy i róznica będzie tylko drobna w implementacji ![]() @down: Owszem... To tylko przykład. To jak postąpisz z polami w walidacji zależy od piszącego. Ja rozbiłem na osobne by zilustrować, że należy to zrobić i w mniej więcej jakim miejscu skryptu niż to, że w ten sposób. Wspominając o tym, że inaczej bym rozwiązał walidację miałem na myśli właśnie przekazanie albo całości, albo pozostawienie na poziomie rozbitym, ale potratowanie od razu pól uniwersalną funkcją (zamiast robić to dopiero na poziomie głównej funkcji walidującej), która je zwaliduje mając określone parametry zmieniające jej zachowanie w stylu $pole = validate( $pole, 'valid_email'), $pole = validate($pole, 'valid_text', 150) czy $pole = validate( $pole, 'required') by uzyskać łatwo rozszerzalny formularz. Dlatego też pisałem że szkielet powinien być mniej więcej podobny, choć mogą zaistnieć różne implementacje Przykładowo wyświetlanie błędów. Wielu robi je zbiorczo na górze formularza. Według mnie to mylące bo trzeba potem szukać gdzie dano pole jest. Lepiej oznaczyć pola z błędem w jakiś sposób. Czy to kolorem, czy komunikatem, ale nie u góry całości, ale bezpośrednio nad/pod tymże polem.Widze, że też podobnie podchodzisz do sprawy. Co do walidacji znów, to sprawdzanie pól obowiązkowych już na starcie strony może Ci błędy powodować. O ile nie sprawdzasz czy zmienna POST istnieje, a z kodu php przytoczonego nie można tego wywnioskować(choć już sprawdzanie pól jest, ale w metodzie wyświetlającej). To samo tyczy się value. W całym kodzie html nie masz w części kodu nadawania im jakichś wartości, więc lamcpp nie powinien być za to przez Ciebie rugany. Nie masz tego w kodzie = nie stosujesz tego = można Ci to podsunąć jako rozwiązanie. Proste ![]() 1) konwertujesz do tablicy formularz (wspominasz, że takie 2 będą - required i optional) i walidujesz 2) masz kilka funkcji w tym jedną wyświetlającą i nawet stosujesz ją w kilku przypadkach, tyle że potrzebuje ona jakichś danych, których zwyczajnie nie masz przez część życia formularza i dodatkowo tylko w części z nich stosujesz wyświetlanie. To zrozumiałe, że olewasz value dla password, ale email już może ją mieć. 3) zauważ, że nie masz nigdzie czegoś takiego jak dane domyślne. Jeśli jest to rozwiązane tak, że sprawdzanie jest na początku to próbujesz metody wyświetlające wywołać dla tablicy $required, której struktury na moment wejścia na stronę formularz i skrypt nawet nie znają. Dlatego ja mam na samym starcie ją utworzoną i zainicjowaną jako $form i dopiero po walidacji i przetwarzaniu przypisuje do niej przetworzone $_POST. To czy przypiszę każde pole z osobna czy może po prostu $form = $_POST zależy od tego co zrobiłem podczas walidacji z nimi. 4) widzę, że masz isset dla wyświetlania więc teoretycznie punkt 3 można by nawet sobie odpuścić. To bardziej moje podejście do problemu, by unikać ciągłego sprawdzania zawartości. Chciałem jednak rozdzielić tablicę post i wartości formularza wyświetlane, te bowiem nie zawsze są takie same. 5) myślę, że pewnym ułatwieniem byłoby dla Ciebie takie zmienienie funkcji walidującej by to ona decydowała co jest, a co nie jest opcjonalne. W ten sposób upraszczasz sobie zapis bo wyskakujesz z tablic required i optional. Ten post edytował thek 29.10.2009, 09:35:25 -------------------- Najpierw był manual... Jeśli tam nie zawarto słów mądrości to zapytaj wszechwiedzącego Google zadając mu własciwe pytania. A jeśli i on milczy to Twój problem nie istnieje :D
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 10.05.2025 - 07:49 |