Długi czas wzbraniałem się z wykorzystaniem AJAXA na stronach WWW. W końcu i na mnie przyszła kryska...

Po kilku tygodniach mniej lub bardziej intensywnego studiowania tematu wczoraj opublikowałem moją pierwszą miniaplikację w AJAXIE.

Aplikacja to bardzo prosty formularz rejestracyjny do fotogalerii.

Czemu AJAX?
W zasadzie - z ciekawości.
Chciałem zapoznać się z technologią, ale mam wrodzoną awersję do pracy z GUI. Nie cierpię listenerów, layoutow, paneli i kontenerów. Dotychczasowe zabawy z tym tematem kończyły się na kilku prostych buttonach, których rozłożenie wiązało się z zagmatwanym kodem wygenerowanym przez buildery. Dodatkowo dwie podstawowe biblioteki Javy odpowiedzialne za GUI (AWT, Swing) używane są najczęściej z zaawansowanymi aspektami Javy (kto z java developerów nie kocha anonymous classes, inner classes itp?).

Za dużo już jednak dookoła AJAXA, dynamicznych aplikacji WWW i nie mogłem pozostać obojętny. Teraz jak patrzę na kilka ostatnich tygodni to duża część tej tematyki była rozpoznana w godzinach pracy. ;-)  Hi hi, praca w AOL rozwija...

Ostatecznym impulsem aby zająć się zabawą z AJAXem było demo MyGWT, które pokazuje co można wycisnąć z DHTMLa!

Wracając do mojego formularza.

Obserwacje logów fotogalerii pokazały, że jest zamieszanie z rejestracją nowego konta.
Kłopoty były spowodowane tym, że zasady rejestracji były dość restrykcyjne:
nick użytkownika nie mógł zawierać polskich znaków, musiał być unikalny, podobnie z loginem, wymagane było zatwierdzenie kilku checkboxów z warunkami umowy itp..

Oczywiście duża część walidacji danych odbywa się wstępnie jeszcze na stronie WWW (client side validation), ale bez połączenia z serwerem i zajrzenia do bazy zarejestrowanych użytkowników nie da się sprawdzić unikalności loginu, emaila itp...

Co dzieje się w tym formularzu rejestracyjnym?
Wprowadzone dane sa sprawdzane są między innym pod kątem:

• Czy login i hasło nie jest za krótkie.
• Czy login nie zawiera polskich znaków, przecinków, myślników, spacji itp...
• Czy hasło i potwierdzenie hasła jest identyczne.
• Czy email wygląda na poprawny. Celowo piszę tutaj "wygląda" ponieważ dane kontrolowane są tylko pod względem składniowym: czy jest jedna małpa, czy za małpą jest przynajmniej jedna kropka, brak spacji itp... Nie ma natomiast rzeczywistego sprawdzenia czy podany user, domena są rzeczywistymi istniejącymi w internecie. Na wstępną kontrolę jednak taki poziom dokładności jest w zupełności wystarczający. Weryfikacja czy email jest prawdziwy, czy trafia na prawdziwą skrzynkę odbywa się dalej - tradycyjnym emailem aktywacyjnym wysyłanym na podany adres.
• Czy wprowadzany login nie jest już obecny w bazie zarejestrowanych użytkowników - to sprawdzenie odbywa się całkowicie w tle(!) i jest wywoływane zdarzeniem onFocusLost. Dzięki temu nie ma denerwującego momentu "wprowadziłem, wysłałem i czekam co strona odpowie". Ponieważ zwykle login wprowadzany jest jako pierwszy i potem wypełniane są kolejne pola to zakładam, że łączenie z serwerem i weryfikacja unikalności nicka odbywa się zupełnie w tle.
  
• W razie niepoprawności danych wyświetlany jest odpowiedni alert - dialogi w stylu Windows (drag'n drop, przezroczystość itp...).
• Pola z błędnie wprowadzonymi danymi (albo wcale nie wypełnione) są odpowiednio "alarmowo" oznaczane.

Dla ciekawskich - proszę przetestować założenie konta dla istniejącego użytkownika 'olektrolek'.

GWT
No i dochodzimy do Google Web Toolkit, bez którego nie da tworzyć się bardziej zaawansowanych dynamicznych stron WWW.
W wielkim skrócie GWT, to komplet narzędzi i bibliotek pozwalający  programować aplikacje WWW client-side  z wykorzystaniem języka Java. Następnie tak przygotowana aplikacja jest automatycznie konwertowana do JavaScript, który to dopiero jest w stanie być przetrawiony przez przeglądarkę WWW.

Uwaga: mówimy tutaj o aplikacjach w całości operujących na raz załadowanej stronie HTML. Nie ma tradycyjnej interakcji klik-zapytanie do serwera-odpowiedź-przeładowanie strony-klik. Nie działają funkcje wstecz/poprzednia strona a reload strony wiąże się z ponownym odpaleniem całej aplikacji!
Strona ładuje się więc raz i ewentualna wymiana informacji odbywa się właśnie za pomocą AJAXA, bez wyraźnego SUBMITu do serwera.

Ponieważ programujemy w Javie to wykorzystujemy prawie wszystkie funkcje oferowane rpzez ten język: enkapsulację, obiekty, dziedziczenie, itp.

Ponieważ finalny kod to skrypt (Java Script) to wiąże się to z ograniczeniami, o jakich należy pamiętać piszac pod GWT:

• zabroniony jest dostęp do plików na lokalnym FS,
  
• brak wielowątkowości,
• brak obsługi wielu funkcji z grupy Thread nawet, jeśli nie zamierzamy tworzyć wielu wątków.

Tutaj z początku miałem sporą zagwozdkę ponieważ użycie Thread.sleep(...) powodowało błąd uruchomienia a nie kompilacji - w dodatku z dość dziwnym komunikatem (nieznana metoda...)

• jest wskazanie aby nie uzywac zbyt ogolnych typow danych. Na przykald zamiast Map okreslac precyzyjniej ze obiekt bedzie typu HashMap. Wynika to z tego, ze im bardziej ogolny typ danych tym obszerniejszy bedzie kod wynikowy, ktory zapewni tak 'szerokie' obsluzenie tak 'ogolnego' elementu. To troche kloci sie z polimorfizmem.

I to chyba koniec ograniczeń.

GWT oferuje platformę developerską, która pozwala logować zdarzenia, zaglądać do Java stacktrace itp... Oczywiście kod piszemy w swoim ulubionym IDE, który nie ma zielonego pojęcia że "jego" Java zostanie przekształcona na ubogiego krewnego Javy - skrypty Java Script.

Aplikacja tworzona w GWT potrafi wyświetlać rozmaite kontrolki, dialogi, generować drzewka, panele z zakładkami (tzw. taby) itp... Generalnie - w tworzeniu i działaniu bardzo przypomina typowe aplikacje "okienkowe". A przecież w całości zamyka się w www, ściąga z serwera i do pracy wymaga zwykłej tylko przeglądarki www!

Rozszerzenia GWT
Znalazłem przynajmniej dwa wspaniałe rozszerzenia bazujące na GWT.

• GWT-Ext, to tak naprawdę owinięta w Jave biblioteka Ext. Czyli?

Zanim pojawiło się GWT-EXt można było porywać się na tworzenie aplikacji "okienkowej" wykorzystując do tego "czysty" Java Script.
Istnieje do tego całe API które jest ciągle rozwijane, ma mnóstwo kontrybutorów i to właśnie jest Ext (obecnie wersja 2.0).
Jak dla mnie tworzenie w js kojarzy sie z masochizmem (nędzne mechanizmy debugowania, brak porządnego IDE itp...). Dlatego GWT-EXt finalnie bazuje na tych bibliotekach, ale w procesie tworzenia operujemy na czystej Javie a odpowiednią transformacją do JS zajmuje się już samo GWT-EXT. To już dużo wygodniejsze.

Wada? Ponieważ jest dodatkowy element pośredniczący w procesie uruchomienia to program wynikowy jest ciężki bo musi załadować spory komplet bibliotek wspomagających. Dla przykładu powyższy formularz w pierwszym rzucie ważył 700kb! Jak na stronę www to znacznie za dużo.

• MyGWT - Ta biblioteka nie bazuje na rozwiązaniach oferowanych przez EXT. Z tego powodu oferuje dużo uboższe elementy graficzne (nie ma zaawansowanych drzewek, gridow itp.) Jednak aktualnie jest w okresie burzliwego rozwoju i kwestia czasu będzie jej wzbogacenie. Przyznaje, ze mam problemy z operowaniem na niej. Nie do końca chwytam idee kontenerów, rozmieszczania elementów itp. Chyba nie tylko ja mam takie problemy - w ostatnim czasie na blogu autora pojawiło sie kilka tutoriali właśnie na temat layoutu. Wielkim plusem jest natomiast waga wynikowego skryptu - kod jest stosunkowo 'lekki'.
  

GWT - gwóźdź do trumny Java Applet?
Jestem w stanie zgodzić się z tą teorią. O to w czym GWT bije Java Applet:

• GWT pracuje na lekkim języku skryptowym, który jest czymś od dawna wbudowanym w każdej okienkowej przeglądarce internetowej. Java Applet do uruchomienia wymaga Javy, która musi być dodatkowo doinstalowana. Co prawda Sun oferuje bardzo prosty sposób instalacji ale zawsze to jeden krok więcej - i naprawdę przeciętny użytkownik gubi się jak ma zainstalować obsługę Javy.
• Applety Javy startują z hukiem! Nawet najprostszy aplet powoduje kilku sekundowe szaleństwo twardego dysku - zanim to zacznie działać ja już widzę po zachowaniu komputera, że będzie to applet Java.
• Applety są zawodne. Już nie raz miałem problemy z odpaleniem apletu, najczęstsze przyczyny niepowodzenia to Security Exception. Java Script na którym bazuje GWT nie jest tak mocno obwarowane zabezpieczeniami jak pełna Java. To mniej komplikuje a chyba nie jest poważną luką zabezpieczeń.

Jestem nowym użytkownikiem GWT dlatego moja opinia jest pewnie nieco hurraoptymistyczna, ale na teraz nie widzę większych wad w tej technologii.

Kłopoty z wagą
Kiedy przygotowałem pierwszy działający prototyp powyższego formularza okazało się, ze do uruchomienia inkluduje on:

• dwa style CSS w sumie ok 70kB,
• trzy pliki .js wśród których królował ext.js ważący ok 600kB.

Przy obecnej jakości łącza wychodzącego, jakim dysponują fotogalerie ładowanie formularza zajmowało ponad dwie minuty.
Jak skwitował to znajomy - dziesięć rejestracji dziennie i 8 MB transferu poszło sie j.... ;-)
Jak sobie z tym radzimy?

Odchudzamy...
W pierwszej kolejności można skorzystać z narzedzia, które pozwala wygenerować ext.js zawierający tylko niezbędne nam elementy.
Przykładowo do obsługi formularza potrzebujemy tylko procedury z grupy Form oraz z grupy Core. Niestety jedynym znanym mi sposobem było przygotowanie kodu metodą prób i błędów: typowałem jakie elementy prawdopodobnie będą niezbędne, pobierałem wygenerowany plik ext.js, podmieniałem go w projekcie, rekompilowalem i klikałem po aplikacji czy czegoś jej nie brakuje. Jeśli coś okazywało sie nie tak, to wracałem na stronę i generowałem nowy ext.js zawierający więcej elementów.
Zabawa bardzo żmudna i przy bardziej rozbudowanej aplikacji nie widzę szansy na takie stosowanie bez jakiegoś "pomocnika", który by analizował kod i sugerował jakie procedury należy zawrzeć w ext.js.
Po kilkunastu próbach wycyrklowalem plik wynikowy do rozmiaru ok 250kB.

Odchodziłem również pliki CSS, które są wykorzystywane przez formularz. Style tam umieszczone są na szczęście nazywane intuicyjnie, i bez pudła w moim wypadku można było  wykasować cały zestaw klas gdzie nazwa zaczynała sie na .tree..

Ostatnim najbardziej efektywnym krokiem było uruchomienie na serwerze www kompresji GZIP na wysyłany strumień danych. Prosty wpis w servlet.xml - pliku konfiguracyjnym  Apache Tomcat powoduje, że serwer automatycznie kompresuje "w locie" zawartość plików JavaScript i automatycznie generuje odpowiednie nagłówki w odpowiedzi HTTP. Dzięki temu przeglądarka wie jak "przetrawić" przychodzący strumień danych.
Przykład konfiguracji kompresji http:

<Connector ...compressableMimeType="text/javascript,text/css" compression="10000" />

Ten wpis mówi, że mają być kompresowane wszystkie pliki java script i css, których rozmiar przekracza 10kB.
Istnieje niebezpieczeństwo, że co bardziej egzotyczne przeglądarki nie będą potrafiły zdekompresować otrzymanych danych. Ryzyko niewielkie, i warto je ponieś bowiem po tej operacji ilość danych do przesłania spadła z 250kB do ok 80kB.

Tak więc ostateczny efekt przy wadze 80Kb jest już do zaakceptowania i kilka dni po uruchomieniu sprawdza się bez zastrzeżeń...