Dawno dawno temu w czasach mrocznych i złych gdy większość użytkowników internetu używała IE5 pewna firma na M wymyśliła pewną sztuczkę…

Sztuczka była prosta i opierała się o ciekawy pomysł. Zaimplementujmy jako obiekt JS główną funkcjonalność przeglądarki, czyli komunikację z serwerem. Początkowo obiekt ten był kontrolką ActiveX i nie mógł za wiele jednak z czasem zmieniono technologię a Netscape stworzył własny odpowiednik.

Oczywiście mówię tu o obiekcie XMLHttpRequest i czymś szerzej znanym jako AJAX (wym. adżaks – dż to fajna głoska). Gdy konsorcjum w3c rozpoczęło poważną kampanię na rzecz powszechnej implementacji DOM w przeglądarkach narodził się AJAX w dzisiejszej postaci.

Wraz z rozwojem technologii skupionych pod tym hasłem narodziły się i kłopoty typowe dla sieci. Pierwszy z nich to kompatybilność pomiędzy rozwiązaniami. Firma na M choć była pierwszą, która zaimplementowała odpowiednie interfejsy to nadal ma ona w dupie standardy. Inne firmy tworzące przeglądarki porozumiały się w spawie nazewnictwa i wszystkie mają tak samo nazywający się obiekt. Drugim poważniejszym problemem okazała się inna polityka firmy na M i twórców przeglądarek w sprawie interfejsu DOM. Firma na M ma własny inne firmy trzymają się standardu. Na całe szczęście w pewnym minimalnym zakresie wszyscy dostawcy przeglądarek mają wspólny interfejs dla najważniejszych części DOM.

Ale o co chodzi?

Po krótkim i nieskładnym wstępnie wyjaśniam o co chodzi. AJAX stał się „sławny” dzięki zastosowaniu go w aplikacjach googla (googlemaps, gmail, itd). Jednak popularność została okupiona krwią programistów. Wprowadzenie nowej technologii która dodatkowo jest niekompatybilna sama z sobą pociągnęło wzrost kosztów i zwiększenie ilości błędów. Chcąc nie chcąc programiści Java musieli uczyć się JS. Pomimo dużych podobieństw pomiędzy oboma językami był, i jest nadal, proces bardzo trudny i czasochłonny.

Rozwiązaniem dla programistów Java okazał się znowuż Google ze swoim narzędziem Google Web Toolkit (GWT).

Co to jest?

Wyobraźmy sobie, że piszemy interfejs użytkownika (UI) „klasycznie” z użyciem biblioteki swing. Następnie odpalamy, zapominamy i działa. Na stronie można takie rozwiązanie zastosować pisząc aplet, który będzie osadzony na stronie. Wyobraźmy sobie jednak, że nasz napisany w swingu interfejs możemy „przerobić” na bardziej naturalny dla sieci html. Niemożliwe? Możliwe 🙂 Sercem GWT jest kompilator Java – JavaScript, który pozwala na budowanie interfejsu tak jak w swingu i tłumaczy go na kod html + JS. To nie wszystko. W Javie mamy do dyspozycji mechanizm RMI. GWT dostarcza odpowiedni mechanizm wywołań zdalnych pod nazwą RPC.

W tych dwóch „zabawkach” jest moim zdaniem cały „miodzio” GWT. Pierwsza z nich uwalnia nas programistów Java od użerania się z brakiem kompatybilności pomiędzy przeglądarkami w zakresie DOM i dynamicznej budowy UI. Druga zapewnia możliwość bezproblemowego korzystania z AJAXa. Może przesadziłem z tą bezproblemowością jednak liczba wrzodów spowodowanych przez problemy ze zgodnością na pewno spadnie.

Dlatego też drodzy moi do boju 🙂