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:
<?php
$form = array ('example1' => 'domyślna', 'example2' => 'domyślna', 'example3' => 'domyślna'); $form['example1'] = validation( $_POST['example1'] );
$form['example2'] = validation( $_POST['example2'] );
$form['example3'] = validation( $_POST['example3'] );
//a tutaj zrobisz sobie co tam jeszcze chcesz z tymi danymi
}
?>
<form action="" method="post" name="simple_form">
<?php show_error( $error['example1'] ) ?>
<input type="text" name="example1" value="
<?php echo $form['example1']; ?>" />
<?php show_error( $error['example2'] ) ?>
<input type="text" name="example2" value="
<?php echo $form['example2']; ?>" />
<?php show_error( $error['example3'] ) ?>
<input type="text" name="example3" value="
<?php echo $form['example3']; ?>" />
<input type="submit" name="send" value="Wyślij" />
</form>
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
Z kodu jaki podałeś wynika, że:
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.