walidacja formularzy Opcje

[rzseattle]

Jestem bardzo ciekawy czy tos wykorzysuje w swoich systemach zaawansowane systemy walidacji fomularzy. Moze by jego koncepcja cos zminila w mojej bo akurat jestem w sferze projektowania takiego modulu. Glownym jego zadaniem jest pozbyci sie z akcji wszelkiego typu if(empty($var)) itd . Akcja powinna byc elastyczna a kazda dodatkowa linijka kodu pomniejsza ta ceche. Juz pozbylem sie z akcji wywolywania szablonow (user sam decydyje uruchamiajac akcje jaki szablon zostanie uruchomiony po jej wykonaniu) teraz przyszedl czas na walidacje potrzebnych danych. Obecnie tymczasowo rozwiazalem to na zasadzie rejestracji akcji wejsciowej validacyjnej. CZyli jesli dane przesylane formularzem posiadaja dopowiednia predefiniowana zmienna to system uruchamia akcje walidacyjna ktora decyduje czy przeposcic dane do akcji logicznej czy przekierowac je na formularz z odpowiednimi komunikaami bledu. Zmina taka ma mniej wiecej taka postac

[XML] pobierz, plaintext 
<INPUT name="arrow_validate_form" type="hidden" 
value="
arrow_template_foward:iH/admin/categories/show_categories
|arrow_template_back:iH/admin/banners/add_banner
|arrow_action_redirect:categories:add_category_element
|name:text:5-20
|baner_alt:text:0-40
|baner_url:text:7-100
|email:mail" >
[XML] pobierz, plaintext 

Gdzie na pozatku mamy szablony wywolane w przypadku powodzenia i niepowodzenia walidacji i akcje ktora zostanie wykonana w przypadku raku bledu. Dalej sa juz pola i opisy danych jakie maja zawierac.
Jednak ten system nie jest idealny. Tzn dziala znakomicie jednak pisanie formularzy staje sie po pewnym czasie problemem poniewaz kazde pole wyglada mniej wiecej tak:

[XML] pobierz, plaintext 
<INPUT class="pole" style="WIDTH: 200px" type=input name="name" value="{if isset($_global_page_input.name)}{$_global_page_input.name}{/if}">
{if isset($_global_arrow_error.name)}<br /> Podaj nazwę{/if} </TD></TR>
[XML] pobierz, plaintext 

i moze przy jednym polu to sie wydawac lajtowe ale uwierzcie mi przy formach z 15 - 20 polami nie jest juz tak fajnie. Druga wada jest brak wsparcia dla js.

Wiec sobie pomyslalem ze przeciez mozna generowac formularze. I nie chodzi mi tu o biblioteki w php tzn nie o obiekty z metodami ->createInput. Raczej wykorzystal bym tutaj mozliwosci SMARTEGO i generowac formularze w oparciu o dane z szablonu. Mniej wecej cos takiego

Kod

{form tpl_foward="jakis szablon" action="jakas akcja" jsCheck=TRUE }
{input type="text" name="name" style="jakis styl np wielkosc" check=TRUE size="5-30"}
{input type="text" name="kod_pocztowy" style="jakis styl np wielkosc" check=TRUE preg="/[0-9]{2}-[0-9]{3}/"}
{input type="mail" name="email" style="jakis styl np wielkosc" check=TRUE }
{/form}

No i zostal by wygenerowany tym sposobem nie tylko szablon z odpowednimi polami i warunkami wstawiajacymi odpowiednie wartosci pola lub wywalajacymi komunikat bledu ale rowniez skrypt jsrealizujacy identyczne zadanie tylko ze clientSide.

Moze ktos juz robil podaoba rzecz? Chetnie poslucham rad

ps To jest rozwiazanie userfriendly - niestety wiem ze do BARDZO bezpiecznych nie nalezy i jesli nam zalezy na bezpieczenstwie to w akcjach trzeba walic if(isset ...

[Holyboy]

kiedys znalazlem taki plugin do smartow (ale jak sie nazywal nie pamietam) - wada force_compile=1

[rzseattle]

Ano rzeczywiście ktoś już o tym pomyślał i to nie kto inny jak jeden z twórców smarty. Jeszcze nie testowałem tego pluginu ale zapowiada sie interesująco. I nicgdzie nie znalazlem informacji ze wymagane jest force_compile . Po przetestowaniu postaram się przedsawić moje zdanie o tej wtyczce.

ps dla zainteresowanych http://www.phpinsider.com/php/code/SmartyValidate/

[seaquest]

No cóż. Rozwiązanie bardzo ciekawe, szczególnie, że zaimpletowane w szablonach (nie trzeba dopisywać zbędnych linijek). Walidiacja moim zdaniem jednak jest potrzebna tylko w formularzach rejestracyjnych, a takie stosuję jednak bardzo rzadko, dlatego nie wiem jak wyniki czasowe parsowania tego kodu przez smarty - czekam na efekty.

BTW. rzseattle: jak mozna zdobyc to twoje tlumaczenie manuala smarty?

[rzseattle]

BTW. rzseattle: jak mozna zdobyc to twoje tlumaczenie manuala smarty?

Wersja tymczasowa jest na http://rzseattle.piwko.pl . Teraz chwycilem chwile oddechu wiec moze w koncu to dokoncze i przezuce do docbooka.

[...] dlatego nie wiem jak wyniki czasowe parsowania tego kodu przez smarty

Sam sobie odpowiedzialeś na pytanie - po pierwsze zadko takie formularze wyswietlasz po drugie mozesz wylaczyc sprawdzanie serverside i nie kompilowac juz szablonow, po trzecie jak wprowadzisz blok {dynamic} {/dynamic} i wlaczysz keszowanie to roznice beda znikome.

[Holyboy]

I nicgdzie nie znalazlem informacji ze wymagane jest force_compile .

to byl inny projekt, ale faktycznie to co podales wydaje mi sie ciekawe... nawet baaardzo ciekawe

a co do tlumaczenia - jakbys potrzebowal pomocy to daj znac

Ten post edytował Holyboy 2.07.2004, 14:38:33

[Luke]

Ciekawa klasa jest OOh Forms ktora wchodzi w sklad pakietu PHPLIB. Ma zaimplementowany JavaScript oraz weryfikacje formularzy po stronie serwera. Weryfikacja danych wyslanych z formularza odbywa sie wedlug wczesniej zdefiniowanych kryteriow np. wyrazenia regularna, dopasuja przeslane wartosci do wzorcow, a JavaScript wypisze blad o braku wypelnionego pola ...

[PHP] pobierz, plaintext 
<?php
 
.
.
.
 
$forms -> add_element(array(&#092;"name\" => \"email\",
				   &#092;"type\" => \"text\",
				   &#092;"size\" => \"20\",
					&#092;"minlenght\" => \"1\",
					&#092;"lenght_e\" => \"Prosze podac adres email\",
					&#092;"valid_e\" => \"Bladedny adres email\",
					&#092;"valid_regex\" => \"tutaj wzor z ktorym porownamy wprowadzony adres\" ));
 
.
.
.
 
?>
[PHP] pobierz, plaintext 

[rzseattle]

Jednak zaden z tych skryptow mnie nie zadowala poniewaz jeden nie ma wsparcia dla js a drugi operuje przedewszystkim na poziomie php a nie smarty. Datego pisze wlasny plugin do walidacji. Postaram sie aby byl on jak najbardziej przenosny (mozliwosc ustawienia zewnetrznego uchwytu sesji i zewnetrznego parsera linkow i ... ). Jak skoncze to zaprezentuje.

[DeyV]

ja również walczyłem / walczę z tym problemem.
W efekcie powstałą seria klas służąca do walidacji formulaży w oparciu o smarty.
Co prawda narazie nie ma tu żadnego wsparcia dla JS, ale są jak najbardziej możliwości po temu by je dodać.

Zaletą jest również bardzo elastyczne dodawanie wielu różnych warunków do jednego inputa (np. cyfra, nie mniejsza niż 10 i nie większa niż 100, nie równa ... itp )

Przykład: http://www.mstudio.nq.pl/php_pl/projects/f.../forms_0.1b.zip

[JackLondon]

Ciekawy ten plugin Smarty. Szkoda, że go nie znalazłem wcześniej. Bo właśnie jestem na etapie projektowania własnego systemu obsługi formularzy. Lecz podszedłem do tego minimalistycznie. Widziałem tutaj na forum projekty które składały się z kilkunastu klas. Ja wybrałem wariant minimalistyczny:). Chodziło o czas zdecydowałem się na dwie klasy jedna jest odpowiedzialna za walidacje a druga za formularze. Formularze wyświetalm w Smarty ale pobierznie przeglądając plugin chyba porzucę swój dopiero co zaczęty "projekt"

[Wujashek]

Co sądzicie o bibliotece QuickForm ?
Używam od dłuższego czasu i jestem zadowolony. Dużo trzeba pisać, ale przynajmniej kodowanie jest przejrzyste i jest mała szansa na popełnienie błędów.

[Ociu]

IMHO Formularze w agavi są po prostu świetne. Mało pisania, walidacja jest najlepsza jaką znalazłem. Ogólnie jest super.

[splatch]

Może słowo o tym jak to wygląda w Agavi.

Otóż walidacja nie jest powiązana z żadnym polem bezpośrednio. To znaczy, że nie definiujemy konfiguracji walidacji w widoku. Myślę, że praktyka dobra, ponieważ w połączeniu z możliwością rozbijania i wczytywania konfiguracji przez XInclude w zależności od potrzeby daje to po prostu elastyczność.

Zatem, w pliku validate/<nazwaakcji>.xml mamy definicję walidacji zgodną ze schematem XML:

[XML] pobierz, plaintext 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations xmlns:xi="http://www.w3.org/2001/XInclude">
      <configuration>
            <validators>
 
                  <validator class="string" name="parameter_name">
                        <arguments>
                              <argument>parameter_name</argument>
                        </arguments>
                        <errors>
                              <error for="min">Podana nazwa jest za krótka.</error>
                              <error for="max">Podana nazwa jest za długa.</error>
                        </errors>
                        <parameters>
                              <parameter name="min">5</parameter>
                              <parameter name="max">30</parameter>
                        </parameters>
                  </validator>
 
            </validators>
      </configuration>
</configurations>
[XML] pobierz, plaintext 

Może o składni dokumentu:

Część atrybutów znacznika validator
1. class (string) - klasa sprawdzająca poprawność danych, rozszerzająca klasę AgaviValidator.
2. name (string) - identyfikator walidatora
3. method (set)- metoda, w której walidacja jest wybierana domyślnie, dopuszczalne wartości to write/read. Domyślnie write.
4. depends (string) - nazwa walidatora, który musi zwrócić true, by walidacja mogła przebiegać dalej
5. severity (set) - waga błędu walidacji - dopuszczalne wartości to:
   1. success - zawsze zwraca true
      
   2. none - nie ma wpływu na proces walidacji
      
   3. notice - błąd zgłoszony przez walidator nie przerywa procesu i nie ma wpływu na dane
      
   4. error - błąd, nie przerywa procesu walidacji
      
   5. critical - natychmiastowe przerwanie walidacji i zgłoszenie błędu
6. required (bool) - czy uruchomienie tego walidatora jest zawsze obowiązkowe. W chwili gdy argumentem walidatora

Tagi
1. arguments (array) - nazwy zmiennych, które będą podlegały sprawdzeniu przez określony walidator.
2. errors (array) - komunikaty błędów, które zobaczy użytkownik. Walidatory używają atrybutu for do
3. identyfikacji błędów. Np. Klasa AgaviNumberValidator korzysta z błędów o atrybutach min, max, type. W Agavi 1.0 będzie możliwość internacjonalizacji komunikatów.
4. parameters (array) - parametry przekazane do walidatora. Atrybut name identyfikuje parametr.
5. validators (validator[]) - kolekcja walidatorów, które są zgrupowane. Pozwala to tworzyć warunki logiczne w walidacji bez konieczności implementacji odpowiednich mechanizmów (if...) w akcji.

To by było tyle odnośnie konfiguracji. Teraz jak to wygląda w akcji:
.

Wierzcie mi, że uzyskanie tego efektu nie wymagało żadnego warunku w widoku czy też szablonie, ponieważ Agavi dostarcza filtr, który na podstawie zgłoszonych w czasie walidacji błędów odpowiedni "dekoruje" output. Mowa tu o Form Population Filter. Co więcej filtr ten oprócz zaznaczania błędów dodaje wiadomości błędów a także uzupełnia wartości.

Więcej na temat w Agavi będziecie mogli się dowiedzieć już w najbliższej przyszłości na zmodernizowanym code-house.net.