Niedawno znalezione: wygodna biblioteka ułatwiająca sprawdzanie poprawności danych wpisanych w formularzu, jeszcze przed wysłaniem ich do serwera. Samo sprawdzanie to nic nowego, ale tę bibliotekę spośród innych rozwiązań wyróżnia sposób, w jaki określa się poprawną zawartość: poprzez atrybut class pól formularzy i odpowiednio zdefiniowane, ogólne funkcje testujące.

Łatwiej to zademonstrować niż opowiedzieć:

Ten fragment tworzy formularz z trzema polami: miejscem na email, hasło oraz listę używanych programów. Każde z nich ma przypisaną klasę, która określa jaką zawartość należy wymuszać:

1. email: chciałbym, żeby można było wpisać adres email w najczęściej używanej, prostej postaci – użytkownik@domena.gdzieśtam (klasa simple_email),
2. hasło: powinno to być sensowne hasło (klasa sane_password),
3. używane shelle: należy wybrać przynajmniej jeden (klasa mandatory).

Jak widać, formularz pomimo dodania tej informacji nadal jest prosty i czytelny. Pozostaje jeszcze zdefiniować funkcje sprawdzające poprawność pól:

Klasa mandatory już jest zdefiniowana w bibliotece, więc nie trzeba jej dodawać. Funkcje te mogą być wspólne dla wielu formularzy, więc najlepiej umieścić je w osobnym pliku .js, wspólnym dla całego serwisu. Zostało już tylko włączenie sprawdzania formularzy poprzez wykonanie po załadowaniu strony:

Form.Validator.installForAllForms({'validators':Validators});

I już, efekt można obejrzeć tutaj. Jakie dokładnie są zalety takiego podejścia? Po kolei:

1. formularze zawierają informacje o danych w postaci zwięzłej i czytelnej i dla maszyny, i dla człowieka,
2. definicje funkcji testowych są zebrane w jednym, wspólnym dla całego serwisu miejscu, co oznacza że ewentualna zmiana sane_password dla wszystkich formularzy na coś bardziej skomplikowanego będzie szybka i wygodna,
3. to, co trzeba napisać samemu, zostało ograniczone do naprawdę niezbędnego minimum: biblioteka faktycznie zawiera całą wspólną część kodu.

Uwaga, na wszelki wypadek: całe to sprawdzanie po stronie klienta oczywiście nie oznacza, że można zrezygnować z kontroli danych na serwerze. Nie należy mieć zaufania do przeglądarki. I nie o to tu chodzi, żeby całkowicie przenieść testy na klienta, tylko o szybsze poinformowanie użytkownika że coś wpisał źle.

Rozwiązanie ma jedną wadę: poprawność trzeba sprawdzać w dwóch miejscach, najprawdopodobniej w dwóch różnych językach programowania (ktoś tu pisze kod po stronie serwera w JS?), co oznacza powtarzanie informacji. Trzeba będzie się przyjrzeć, czy w takim Django dałoby się wyznaczać tablicę Validators na podstawie definicji modelu

Aktualizacja 2007/10/16: Miron zwrócił uwagę, że nie działał odsyłacz do strony testowej. Poprawiłem, dzięki.

Przy okazji wprowadziłem jedną zmianę, drobną ale ważną: od teraz pola z niepoprawną zawartością są wskazywane kolorem tła. Form.Validator ustawia takim elementom klasę "invalid", więc wymagało to tylko dopisania jednej linii CSS.

RTRails: ten zestaw najprawdopodobniej już wkrótce będzie reklamowany jako kolejna demonstracja siły Rails. Całkiem możliwe, że z komentarzem "jeszcze bardziej dynamiczne strony www." To chyba pierwsze zastosowanie modelu push pod hasłem Web 2.0. Demo dostępne tutaj.

Wszystkie aplikacje wykorzystujące XMLHttpRequest, jakie widziałem do tej pory, wykorzystywały do komunikacji z serwerem model zapytanie-odpowiedź. Jeśli oczekiwały na wystąpienie jakiegoś zdarzenia po stronie serwera, na przykład pojawienie się nowego tekstu lub pliku, to musiały co jakiś czas wysyłać do serwera zapytanie żeby sprawdzić, czy coś się dzieje.

W modelu push serwer może przesłać do przeglądarki nowe informacje nie czekając, aż strona o nie spyta. Oznacza to, że strona jest aktualizowana znacznie szybciej, co jest szczególnie ważne w przypadku takich aplikacji jak komunikatory i chaty.

Demo RTRails zawiera aplikację Chat i odtwarzacz mp3. Wygląda interesująco z technicznego punktu widzenia – takie podejście pozwala na tworzenie aplikacji www, które szybko reagują nie tylko na kliknięcia i wpisanie tekstu lokalnie, ale też na zdarzenia które nastąpiły w innej części sieci. Jednocześnie demo ma też podstawową wadę większości aplikacji AJAX – znaczny przerost formy nad treścią, wykorzystujący chyba wszystkie biblioteki do efektów graficznych powstałe na fali AJAX i prototype.

Przy okazji trafiłem na AFLAX, bibliotekę pozwalającą na tworzenie obiektów Flash, także całkiem dynamicznych, przy pomocy JavaScript.  Dociąża trochę procesor, ale możliwości daje spore.

Właśnie skończyłem moją wersję dokumentacji prototype-1.4.0, w tej chwili tekst jest w zasadzie zgodny oryginalną wersją z 25 stycznia 2006. Różnice – głównie fragmenty, które według mnie zawierają drobne błędy – powinny zostać wyjaśnione i wyrównane niedługo.

W sumie fajna sprawa, takie tłumaczenie. Można poznać bibliotekę lepiej niż samym tylko używaniem, można znaleźć błędy w tekście oryginalnym, można wreszcie znaleźć błędy w bibliotece Oczywiście, można też przy okazji samemu narobić błędow, więc w razie zauważenia takich w moim tekście bardzo prosiłbym o poinformowanie mnie o nich.

Uaktualniam sobie moje tłumaczenie dokumentacji biblioteki prototype do wersji 1.4.0 i rzuciło mi się w oczy: pośród nowego kodu w tej wesji pojawiła się, w implementacji funkcji sortBy obiektu Enumerable, transformata Schwartza.

Polubiłem Javascript, podoba mi się prototype, ale tu mi trochę mina zrzedła.  Nawet wersja Schwartza była czytelniejsza, pomimo tego że napisana w Perlu i to prawie na golfowo – tak zwięźle, jak tylko się dało.  Jakoś nie chce mi się wierzyć, żeby w JS nie dało się tego zapisać ładniej.

Oh well, fajnie że jest, razem z masą pozostałych funkcji w 1.4.0.  Polska wersja opisu już wkrótce.