Piotr Gogacz WYKORZYSTANIE GOOGLE WEB TOOLKIT DO BUDOWY SYSTEMU DOKUMENTACJI FOTOGRAFICZNEJ DLA POTRZEB INŻYNIERII WODNEJ

INSTYTUT INśYNIERII I GOSPODARKI WODNEJ POLITECHNIKA KRAKOWSKA im. TADEUSZA KOŚCIUSZKI Piotr Gogacz WYKORZYSTANIE GOOGLE WEB TOOLKIT DO BUDOWY SYSTEMU DOKUMENTACJI FOTOGRAFICZNEJ DLA POTRZEB INŻYNIERII WODNEJ studia dzienne kierunek studiów: informatyka specjalność: informatyka stosowana w inŝynierii środowiska promotor: dr inŝ. Robert Szczepanek nr pracy: 2184 KRAKÓW 2009 ul. Warszawska 24, 31-155 Kraków tel/fax (+48 12) 628 20 41 e-mail: sekretariat@iigw.pl internet: www.iigw.pl

Podziękowania Mamie za, dopingowanie oraz motywowanie do pisania.

Spis Treści: ROZDZIAŁ 1: WPROWADZENIE... 1 1.1 CEL... 2 1.2 PLAN PRACY... 3 ROZDZIAŁ 2: WEBGIS... 4 2.1 DEFINICJA... 5 ARCHITEKTURA WEBGIS-U... 6 2.2 INTEROPERACYJNOŚĆ I OPEN GEOSPATIAL CONSORTIUM... 7 ROZDZIAŁ 3: AJAX... 10 3.1 CZYM JEST AJAX?... 11 3.2 OBIEKT XMLHTTPREQUEST... 14 3.3 AJAX-OWE FRAMEWORKI... 19 ROZDZIAŁ 4: GOOGLE WEB TOOLKIT... 20 4.1 WPROWADZENIE W ŚWIAT GWT... 21 4.2 PODSTAWY GWT... 25 Interfejs użytkownika User Interface (UI)... 28 Image Bundle... 30 Zdalne Wywoływanie Procedur... 31 JavaScript Native Interface... 32 Internacjonalizacja - Internationalization (I18n)... 35 Dostęp do elementów Document Object Model... 36 Deferred Binding... 38 ROZDZIAŁ 5: IMPLEMENTACJA APLIKACJI... 41 5.1 ZAŁOŻENIA... 42 5.2 IMPLEMENTACJA... 43 Tworzenie Interfejs Użytkownika... 43 Wykorzystanie Image Bundle... 46 Użycie kaskadowych arkuszy stylów... 48 Wykorzystanie Internacjonalizacja... 49 Wykorzystanie JavaScript Native Interface... 51 GWT RPC... 53 5.3 PREZENTACJA DZIAŁANIA APLIKACJI... 55 ROZDZIAŁ 6: PODSUMOWANIE... 60 BIBLIOGRAFIA... 61 SPIS RYSUNKÓW... 62 SPIS TABEL... 63

Rozdział 1: WPROWADZENIE 1

1.1 CEL Niniejsza poświęcona jest aplikacji internetowej wykorzystującej mapy Google a do zaprezentowania zbiorów fotograficznych Regionalnego Zarządu Gospodarki Wodnej w Krakowie (RZGW). Zbiór ten (rys. 1) dokumentuje zjawiska przyrodnicze powstające na rzekach i zbiornikach wodnych. Wiele z fotografii pokazuje skutki powodzi, jak również prace budowlane związane z przedsięwzięciami hydrotechnicznymi. Zbiór gromadzono przez lata, niektóre fotografie są ponadstuletnie, ma on więc wartość historyczną. Jednakże Regionalny Zarząd Gospodarki Wodnej w Krakowie nie udostępnia go społeczeństwu. Celem tej pracy jest zatem stworzenie aplikacji internetowej, która zaprezentuje ten unikatowy zbiór fotografii. Dzięki wykorzystaniu jako podkładu map Google a użytkownik uzyska dostęp do informacji o lokalizacji danego obiektu. Razem z informacją o położeniu odbiorca dostanie również informację o czasie, w jakim dane zjawisko miało miejsce. Do każdego z prezentowanych zdjęć dołączony jest odpowiedni opis. Dzięki gromadzeniu tych danych użytkownik będzie mieć możliwość wyszukania interesujących go obiektów. Prezentowana aplikacja ma bez wątpienia wartości edukacyjne. Celem pracy jest również prezentacja bieżących technologii informatycznych służących do budowy aplikacji internetowych wykorzystujących serwis mapowy. Technologie te zostaną przedstawione w aspekcie ich wykorzystania już w konkretnej aplikacji. Aplikacja internetowa jak już wspomniano jako podkład w prezentacji zbioru fotograficznego wykorzystuje serwis mapowy Google a. Jest to obecnie najpopularniejszy serwis mapowy w Internecie. Różnica pomiędzy tą aplikacją a setkami bądź tysiącami innych serwisów polega na doborze wykorzystywanych technologii. Przedstawione są wady i zalety poszczególnych podejść do tworzenia systemu mogącego prezentować zbiór. Autor koncentruje się na wyjaśnieniu dlaczego do budowy aplikacji mapowej wybrano framework Google Web Toolkit. Framework ten stanowi równocześnie generalną różnicę pomiędzy opisywanym serwisem, a serwisami oferującymi podobną funkcjonalność. 2

1.2 PLAN PRACY Prezentowaną pracę można podzielić na cztery główne części. Rozdział drugi, WebGIS, definiuje pojęcie WebGIS-ów. Ukazuje jak duże znaczenia mają mapy internetowe. Nakreśla także typową architekturę serwisów mapowych najczęściej spotykaną w tego typu rozwiązaniach. Omawia kwestię interoperacyjności oraz opisuje fenomen Google Maps. Rozdział trzeci przedstawia technikę Ajax, która pozwala na tworzenie interaktywnych aplikacji. Techniki wykorzystywane przez AJAX są również wykorzystywane przez framework Google Web Toolkit (GWT). Dzięki omówieniu techniki AJAX możliwe będzie zrozumienie tego, co nowego do budowy aplikacji internetowych wnosi framework GWT. Kolejny rozdział opisuje framework Google Web Toolkit. GWT stanowi nowe podejście w wykorzystaniu techniki AJAX. Do budowy aplikacji internetowej wykorzystano właśnie ten framework. Rozdział opisuje poszczególne elementy składające się na tę technikę tworzenia aplikacji webowych. Rozdział piąty przedstawia założenia stawiane przed aplikacją, zapoznaje z jej implementacją oraz prezentuje jej działanie. Rozdział szósty stanowi podsumowanie. Rysunek 1Kolekcja zdjęć Regionalnego Zarządu Gospodarki Wodnej w Krakowie 3

Rozdział 2: WEBGIS 4

2.1 DEFINICJA GIS czyli Systemy Informacji Geograficznej (ang. Geographic Information Systems) to specjalistyczne systemy służące gromadzeniu, przetwarzaniu oraz prezentacji danych geograficznych. Rozwój systemów GIS w ostatnich latach cechuje się bardzo dużą dynamiką, jeszcze szybszy rozwój ma miejsce w przypadku internetowych GIS WebGIS. Postęp Internetu sprawił, że zwykli jego użytkownicy mają dostęp do serwisów oferujących mapy. Czyli WEB-GIS to taki GIS który można obsługiwać za pomocą przeglądarki internetowej [www.geostrada.com]. POTENCJAŁ WEBGIS GIS swój początek miały w latach 60. ubiegłego stulecia. Pojawiły się w kręgach akademickich kilku amerykańskich uniwersytetów oraz pozostawały (co wydaje się dość oczywiste) w strefie zainteresowań wielu armii, w pełni świadomych potencjału drzemiącego w tej technologii. GIS są więc, biorąc pod uwagę szybkość zmian w informatyce dziedziną dość starą. Internet, który w ciągu niemal dwóch dekad całkowicie zmienił funkcjonowanie gospodarki i wywarł ogromny wpływ na życie wielu ludzi, nie mógł nie czerpać z potencjału GIS. Można oczywiście spierać się, czy to Internet wykorzystuje systemy informacji geograficznej, czy GIS wykorzystuje siłę Internetu. To zapewne zależy od konkretnego przypadku. Niepodważalnym natomiast pozostaje fakt, że internetowe mapy w dalszym ciągu mają przed sobą przyszłość. Kropka nad i w tej kwestii nie została jeszcze postawiona. Motorem postępu są, jak w każdej dziedzinie, pieniądze i to nie są bynajmniej niewielkie sumy. Pieniądze te mobilizują zarówno duże korporacje do tworzenia ogólnodostępnych serwisów mapowych, czego przykładami są takie produkty jak: Google Maps, Yahoo Maps czy Microsoft Live Search Maps, jak również pojedynczych web developerów, którzy wykorzystują na swoich stronach owe serwisy mapowe. Samych stron posługujących się tymi serwisami są tysiące. Tak więc mamy tu do czynienia z fenomenem. 5

ARCHITEKTURA WEBGIS-U Tę architekturę można podzielić na trzy główne składniki: pierwszą warstwą jest użytkownik, a konkretniej przeglądarka internetowa, poprzez którą użytkownik wysyła zapytania oraz odbiera interesujące go dane. Drugim składnikiem jest serwer WWW, który odbiera zapytania przesłane przez użytkownika oraz generuje na ich podstawie odpowiedź. Trzecim składnikiem architektury typowego serwisu WebGIS jest baza danych służąca przechowywaniu informacji. Informacje te mają często bardzo różny charakter, mogą mieć one postać zwykłych danych, map postaci wektorowej, bądź w postaci rastrowej. Poniżej przedstawiono typową architekturę web serwisu. Rysunek 2: Architektura web serwisu W modelu tym można podzielić klientów na cienkich oraz grubych. Niektórzy dzielą również klientów web serwisów na jeszcze jedną grupę: średnich. I tak klient cienki zazwyczaj odbiera tylko wszelkie dane, potrzebne obliczenia przeprowadzane na serwerze. Dzięki temu użytkownik nie musi być zaawansowany i w pełni świadomy, co znacznie poszerza potencjalne grono odbiorców. Również brak potrzeby instalacji jakiegokolwiek oprogramowania na komputerze sprawia, że użytkownicy nie są zniechęceni instalacją plugin-ów. Natomiast gruby klient jest przeciwieństwem klienta cienkiego, jest bardziej świadomy. Do swojej pracy bardzo często potrzebuje dodatkowego oprogramowania, jak choćby ArcExplorer, czy Google Earth. Jednak założeniem rozwijanej aplikacji jest dotarcie do możliwie najszerszego kręgu odbiorców, więc w aplikacji za potencjalnego klienta został przyjęty klient cienki. 6

2.2 INTEROPERACYJNOŚĆ I OPEN GEOSPATIAL CONSORTIUM Open Geospatial Consortium, Inc (OGC) to międzynarodowe konsorcjum składające się z ponad 300 firm, instytucji rządowych oraz uniwersytetów skupionych na rozwoju publicznie dostępnych specyfikacji interfejsów. Konsens w rozwoju standardów jest niezmiernie ważny ze względu na dalszy rozwój Systemów Informacji Geograficznej. Wiele firm czy agencji rządowych posiada oprogramowanie od kilku dostawców. Oprogramowania te często nie może ze sobą współpracować formaty danych są różne, co znacząco zwiększa koszty użytkowania. Dostawcy oprogramowania muszą więc razem współdziałać, a najlepszym miejscem do osiągnięcia trwałego konsensu jest właśnie OGC. Rozwój aplikacji powinien o ile to możliwe uwzględniać wytyczne OGC. Interoperacyjność to zdolność do wzajemnego współdziałania różnych systemów informatycznych[www.idg.pl]. W praktyce oznacza to możliwość wymiany danych. Dane te muszą mieć w związku z tym określoną strukturę tak aby systemy o zupełnie innej architekturze również potrafiły ją zrozumieć. Jest to jeden z podstawowych aspektów, nad którymi trwają prace w OGC. Ukazałem już cele pracy OGC, oraz omówiłem współczesne problemy użytkowania oprogramowania GIS. Czytelnik być może zastanawia się, co ma wspólnego web aplikacja z bardzo zaawansowanym oprogramowaniem. Pamiętajmy, że jednym z założeń stawianych przed aplikacją jest zdolność do rozwoju. Rozwój serwisu jest tylko jedną z ewentualnych możliwości wykorzystania informacji wprowadzonych do bazy. Właśnie w tym tkwi siła informatyki, to jest przecież ciągłe użytkowanie tych samych informacji przez różnorodne systemy. 7

Można zapytać jak pogodzić tę naczelną zasadę informatyki interoperacyjność z jednym z założeń stawianych przed aplikacją, tj. szerokim dostępem. W tym miejscu przychodzi z pomocą właśnie OGC. Na dzień dzisiejszy w OGC trwają prace nad specyfikacją gramatyki XML-a do zakodowania i transportu danych geograficznych dla prezentowania ich w bardziej zaawansowanych przeglądarkach Ziemi niż sam Google Map. Do tej grupy przeglądarek należą takie produkty jak: Google Earth, ArcExplorer firmy ESRI, czy też NASA World Wind. Za gramatykę odpowiedzialny jest format KML. Opowiada on za to, co jest wyświetlane oraz precyzuje sposób prezentacji. Przewiduje się, że w przyszłości w tym formacie użytkownik otrzymywać będzie dane. Dzięki temu będzie miał możliwość zapisania bieżących informacji i w razie potrzeby kontynuowania pracy w jednej z przeglądarek Ziemi. Proces ten sprawi, że doświadczeni użytkownicy będą mogli pracować na oprogramowaniu bardziej zaawansowanym. Również odbiorcy mniej wprawieni, jeśli tylko będą chcieli, uzyskają możliwość przeglądania zbioru RZGW w trójwymiarowym środowisku, co niewątpliwie może przyczynić się do wzrostu liczby użytkowników serwisu. Wybór formatu dekodowania i transportu danych ma więc kolosalne znaczenie, jeśli założymy rozwój i pracę w różnorodnym środowisku. GOOGLE MAPS I ZBIÓR FOTOGRAFII RZGW Serwis Google Maps jest obecnie najbardziej rozpowszechnionym serwisem mapowym w Internecie. Nie jest to bynajmniej przypadek. Fenomen popularności Google Maps bierze się z polityki firmy Google, która zmusiła konkurentów do wdrożenia w swoich serwisach podobnych rozwiązań. Najważniejszą cechą serwisu jest to, że mapę Google może dodać każdy do swojej strony internetowej i to zazwyczaj całkowicie za darmo. Mapa ta obejmuje zasięgiem całą Ziemię, zaś w przypadku wielu zachodnich miast dzisiejsza dokładność planów była jeszcze kilkanaście lat temu praktycznie nie do wyobrażenia. 8

Co więcej produkt, który oferuje Google jest cały czas rozwijany nie tak dawno pojawiła się możliwość wykorzystania również technologii Flash w celu prezentacji danych. Jakość zdjęć jest z roku na rok coraz lepsza. Wystarczy kilka linijek kodu HTML i mapa jest już wstawiona w stronę. Wszystkie te zalety spowodowały, że jako podkład w prezentacji zbioru RZGW wykorzystano serwis Google Maps. W chwili obecnej samo wstawienie w stronę mapy nie zagwarantuje serwisowi popularności. Aby zapewnić potencjalne grono użytkowników należy zadbać o prezentowane dane. W tym momencie z pomocną dłonią przychodzi zbiór fotografii RZGW. Zbiór, który jak powiedziano na wstępie jest unikatowy. Użytkownik otrzyma narzędzie umożliwiające precyzyjną lokalizację prezentowanych zdjęć, wraz z opisem i określeniem daty wykonania danej fotografii. 9

Rozdział 3: AJAX 10

3.1 CZYM JEST AJAX? Początki sieci World Wide Web sięgają roku 1990, kiedy to Tim Berners-Lee stworzył pierwszą przeglądarkę internetową Mozaic, pierwszy Web serwer oraz pierwszą stronę internetową. Wszystko to zostało utworzone w jednym celu aby można było dzielić się dokumentami HTML. Pierwotnie dokumenty HTML miały postać statyczną, zaś sieć Web działała na zasadzie: kliknij, czekaj i odśwież. Przeglądarka najpierw wysyłała zapytanie HTTP, serwer generował odpowiedź statyczny plik HTML, aż w końcu przeglądarka odświeżała i wyświetlała nową stronę. Działanie powyższego schematu oraz powolność internetowych łączy sprawiły, że niektórzy użytkownicy Internetu używali innego określenia na sieć World Wide Wait. Filozofia działania techniki AJAX opiera się na zupełnie innym podejściu. Zapytania kierowane są asynchronicznie użytkownik często nie zdaje sobie sprawy, że w tle generowane są zapytania i odbierane są odpowiedzi. Można by zapytać, dlaczego się tak dzieje? Odpowiedź jest bardzo prosta, użytkownik nie traci nawet na chwilę wpływu na działanie strony. Odnosi on wrażenie, jakby pracował na lokalnej aplikacji, co zwiększa produktywność. W czasie, gdy generowana jest odpowiedź, użytkownik może zająć się innym działaniem. Odświeżana jest tylko ta część strony, która uległa zmianie, nie ma potrzeby odświeżania za każdym razem całej strony jak w przypadku statycznych stron HTML. Wiemy już, co jest fundamentem działania AJAX-a asynchroniczna komunikacja. W dalszym ciągu nie wiemy, czym jest sam AJAX. Otóż jest to nowy sposób wykorzystania starych dobrych i sprawdzonych standardów: JavaScript XML (X)HTML CSS Wszystkie te standardy są dobrze znane programistom, a co ważniejsze wspierane są przez wszystkie główne przeglądarki. Można więc śmiało powiedzieć, że AJAX jest niezależny od konkretnej wersji przeglądarki. 11

Należy również wspomnieć o pewnym elemencie AJAX-a służącym do wysyłania asynchronicznych zapytań XMLHttpRequest (XHR). Odpowiada on za wymianę informacji z serwerem. Obiekt ten odpowiedzialny jest za aktualizację strony bez jej odświeżania. XHR to serce AJAX-a. W różnych przeglądarkach w odmienny sposób tworzony jest obiekt XMLHttpRequest, ale zasada jego działania pozostaje ta sama. Przyjrzyjmy się teraz kolejnym składnikom czyniącym AJAX tak potężnym. JAVASCRIPT JavaScript to obiektowy skryptowy język programowania, stworzony pierwotnie przez firmę Netscape. Język ten wykorzystywany jest przede wszystkim w przeglądarkach internetowych. Służy on do interakcji z użytkownikiem, sprawdzania danych wprowadzonych do formularzy, czy też do tworzenia zaawansowanych układów nawigacyjnych. Obsługiwany jest przez wszystkie współczesne przeglądarki internetowe. Język ten obecnie rozwijany jest przez organizacje: Ecma International (ang. European Association for Standardizing Information and Communication Systems) Europejskie Stowarzyszenie na rzecz Standaryzacji Systemów Informacyjnych i Komunikacyjnych. Zadaniem tej organizacji jest standaryzacja oraz rozwój języka. JavaScript jest również znany pod nazwą EcmaScript, jednak nazwa nie jest ona tak popularna, więc w publikacji używana będzie nazwa JavaScript. Oficjalnym standardem JavaScriptu jest ECMA-262. Bardzo często JavaScript bywa mylony z Javą, jednak nie ma on z nią żadnego związku. JavaScript jest językiem interpretowanym przez przeglądarki, nie jest on kompilowany przed użyciem. XML XML to rozszerzalny język znaczników (ang. Extensible Markup Language). XML jest metajęzykiem służącym do definiowania innych języków. Nie sprecyzowano w nim języka znaczników, jak również gramatyki. I to właśnie jest siłą XML-a. Rozmaite technologie bazujące na XML-u dają programistom nieprawdopodobne możliwości jeśli chodzi o wymianę informacji. Jedną z najważniejszych cech XML-a jest to, że separuje dane od sposobu ich prezentacji. 12

Dane w XML-u przechowywane są w pliku tekstowym, dzięki czemu są one również zrozumiałe dla człowieka. Co więcej, można go również tworzyć oraz modyfikować w zwykłym edytorze tekstowym. W rozproszonym i zróżnicowanym środowisku, jakim niewątpliwie jest Internet, XML nadaje się wyśmienicie do wymiany informacji. Ponadto XML posłużył już do stworzenia takich języków znaczników jak: XHTML, WAP, RSS, MathML, GML oraz wielu innych. (X)HTML HTML, czyli hipertekstowy język znaczników (ang. HyperText Markup Language) to język służący do definiowania dokumentów, które mogą być wyświetlane przez przeglądarki. Opisuje on strukturę informacji zawartej w dokumencie, stworzony został na podstawie SGML (ang. Standard Generalized Markup Language). Rozszerzeniem HTML-a jest XHTML rozszerzalny hipertekstowy język znaczników, będący następcą HTML-a. Każdy dokument XHMTL-a jest także dokumentem XML. Dlatego jest on również bardziej restrykcyjnie traktowany przez przeglądarki internetowe, które wyświetlają dokument XHTLM jedynie wtedy, gdy jest on poprawnie zbudowany. CSS CSS czyli kaskadowe arkusze stylów (ang. Cascading Style Sheets) to z kolei język służący do prezentacji danych. Jest on zbiorem reguł (dyrektyw) na podstawie których przeglądarka internetowa wie w jaki sposób prezentować dane. Język ten służy do odseparowania treści od prezentacji, dzięki czemu te same dane mogą być zaprezentowane w różny sposób, w zależności od urządzenia, które je wyświetla. Separacja w znaczący sposób ułatwia tworzenie, a później modyfikacje aplikacji, ponieważ modyfikacja odbywa się w jednym miejscu, a nie w różnych częściach witryny. Pokrótce opisałem składniki AJAX-a, jednakże dogłębne omówienie wszystkich tych technologii wykracza poza tematykę mojej publikacji. Następnym punktem będzie objaśnienie obiektu XMLHttpRequest. 13

3.2 OBIEKT XMLHTTPREQUEST Obiekt XMLHttpRequest (XHR) implementuje interfejs pozwalający skryptom działającym po stronie klienta na ładowanie danych z serwera asynchronicznie. Brzmi to zawile, ale działanie obiektu XHR pozwala na pobieranie danych z serwera już po załadowaniu strony. Po pobraniu danych obiekt ten wywołuje funkcję odpowiedzialną za modyfikowanie bieżącej strony. Metody oraz właściwości obiektu mają kluczowe znaczenie w wykorzystywaniu aplikacji opartych na technice AJAX. Dane przesyłane z serwera mają najczęściej postać XML-a, JSON-a, mogą być również przesyłane w postaci czystego tekstu. Najbardziej znanymi aplikacjami opierającymi swoje działanie o AJAX-a są w tej chwili: Google Gmail, Google Maps oraz Windows Live Local. Nie pozostaje mi nic innego, jak omówienie poszczególnych składników XMLHttpRequest. Obiekt XHR obsługuje dwa modele żądań GET oraz POST. Dzięki obsłudze metody POST istnieje możliwość wysłania i odbioru większej ilości danych niż 512 bajtów, a jest to maksymalna ilość, jaką jest w stanie obsłużyć metoda GET. Najczęściej metodę GET wykorzystuje się do odpytywania serwera, natomiast metodę POST do odbioru danych z serwera. Obiekt XHR wykorzystywany w tandemie z bazą danych daje ogromne możliwości tworzenia interaktywnej aplikacji. Bardzo często można spotkać się z wykorzystaniem obiektu XHR w formularzach logujących użytkownika do serwisów internetowych. W momencie, gdy użytkownik skończy wprowadzać swój login do formularza, obiekt XHR wysyła zapytanie do serwera Czy użytkownik o podanym loginie istnieje?. Jeżeli odpowiedź jest negatywna, twórca serwisu ma możliwość poinformowania użytkownika o błędzie. Ponieważ, odpowiedź jest bardzo szybka, użytkownik zanim jeszcze dokończy wpisywać hasło ma szansę poprawienia błędu. Zwiększa się tym samym użyteczność serwisu. Jest to jeden z najczęstszych sposobów wykorzystania obiektu XHR różnego rodzaju formularze wstawiane są w większość serwisów internetowych. Poniżej przedstawiono schemat funkcjonowania obiektu XHR obsługującego bazę danych. 14

Rysunek 3: Obiekt XHR wykonujący zapytanie do bazy danych [opracowanie własne] Pora zapoznać się ze sposobem tworzenia obiektu XHR. Z powodu różnic w implementacji obiektu XHR w różnych przeglądarkach tworzenie jego jest w niektórych z nich inne. W przeglądarkach z rodziny Internet Explorer wykorzystujemy obiekt ActiveX. Natomiast pozostałe przeglądarki udostępniają metodę XMLHttpRequest, która zwraca obiekt XHR. Poniżej przedstawiono tworzenie obiektu XHR. Listing: Tworzenie obiektu XHR var xhr = false; if(window.xmlhttprequest) / przeglądarki spoza rodziny IE { xhr = new XMLHttpRequest();} else if(window.activexobject)/ IE { xhr = new ActiveXObject( Microsoft.XMLHTTP );} 15

Obiekt XHR posiada szereg właściwości oraz metod. Poniżej tabelarycznie przedstawiono właściwości i metody obiektu XHR. Tabela 1. Właściwości obiektu XHR Właściwość readystate onreadystatechange status statustext responsexml ResponseText Opis Zwraca wartość liczbową wskazującą bieżący stan obiektu. Funkcja obsługi zdarzenia wywoływana, gdy zmieni się stan obiektu żadania. Kod odpowiedzi serwera (np. 404 dla "Not Found" lub 200 dla "OK"). Kod odpowiedzi serwera w postaci tekstowej (np. "Not Found" lub "OK"). Odpowiedź serwera w postaci XML Odpowiedź serwera w postaci łancucha tekstowego Tabela 2. Metody obiektu XHR Właściwość Opis Abort() Anuluje bieżące żądanie HTTP. getallresponseheaders() Pobiera wartości wszystkich nagłówków HTTP. GetResponseHeader (etykieta) open(medota_transmisji,url asynch, użytkownik, hasło) send(zawartość) setrequestheader( nazwanagłówka, zawartośćnagłówka ) Zwraca wartość nagłówka o podanej etykiecie Inicjalizuje żądanie. Wskazuje metodę, URL, oraz dane uwierzytelniające. Wysyła żądanie. Dodaje parę nagłówek/zawartość do żądania HTTP. 16

Powyższa lista właściwości i metod wykorzystywana przez obiekt XHR pozwala tworzyć interaktywne aplikacje internetowe. Innymi słowy, wykorzystując tę nie wielką liczbę właściwości oraz metod obiektu XHR jesteśmy w stanie tworzyć bogate internetowe aplikacje. Poniżej przedstawiono przykładową implementację żądania przy pomocy obiektu XHR. Listing: Tworzenie żądania. xhr.open("get", "index.html",true); xhr.onreadystatechange=function() { if (xhr.readystate==4) { if(xhr.status==200){ alert(xhr.responsetext); } } xhr.send(null); Poniższa tabelka zawiera listę wartości właściwości readystate, właściwość ta jest wykorzystywana przy budowaniu żądania Tabela 3. Lista wartości właściwości readystate Właściwość readystate Nazwa Opis 0 Niezainicjowany Obiekt nie został zainicjowany. 1 Wczytany Obiekt ładuje swoje dane. 2 Załadowany 3 Interaktywny Obiekt ukończył ładowanie danych. Możliwa jest interakcja użytkownika z obiektem. Nawet jeśli obiekt nie został w pełni załadowany. 4 Gotowy Obiekt całkowicie załadowany. 17

Poniżej przedstawiono przykład wykorzystania AJAX-a do sprawdzenia poprawności danych wprowadzonych przez użytkownika. Kroki prezentowane na poniższym rysunku: 1. Klient wywołuje zdarzenie 2. Obiekt XHR jest tworzony i konfigurowany 3. Obiekt XHR wywołuje zapytanie 4. Zapytanie obsługiwane jest przez serwer WWW 5. Serwer WWW zwraca odpowiedź do obiektu XHR 6. Obiekt XHR wywołuje funkcję zwrotną 7. Dokument HTML jest modyfikowany Rysunek 4: Wykorzystanie AJAX-a do sprawdzenie poprawności danych [Sun Microsystems] 18

3.3 AJAX-OWE FRAMEWORKI Framework (rama projektowa, szkielet) to w programowaniu struktura wspomagająca tworzenie, rozwój i testowanie powstającej aplikacji. Z reguły na framework składają się programy wspomagające, biblioteki kodu źródłowego i inne podobne narzędzia. [Źródło Wikiepdia]. Celem powstawania kolejnych frameworków jest wspomaganie budowy aplikacji. W przypadku AJAX-a, istnieje wiele różnorodnych szkieletów mających ułatwić nam budowę aplikacji. Przystępując do tworzenia nowej aplikacji należy zastanowić się nad wyborem najodpowiedniejszego z gotowych już szkieletów programistycznych. Do najbardziej popularnych obecnie framworków należą: Dojo Toolkit, Ext, GWT, JQuery, jmaki, Prototype, Yahoo! UI Library. Różnią się one licencjami, wielkością, jaką zajmują, komponentami interfejsu użytkownika, jakie oferują, jak również wersjami przeglądarek, które dany framework potrafi poprawnie obsłużyć. Wybierając konkretny framework, możemy w pewnych aspektach naszej aplikacji ułatwić sobie rozwiązanie problemów, zaś w innych utrudnić. To wszystko musi zostać przeanalizowane zanim zabierzemy się za kodowanie. Kolejny rozdział przedstawia framework Google Web Toolkit. Rozdział ten stanowić będzie próbę omówienia zasadniczych wad i zalet wyboru właśnie tego szkieletu aplikacji. 19

Rozdział 4: GOOGLE WEB TOOLKIT 20

4.1 WPROWADZENIE W ŚWIAT GWT Google Web Toolkit (GWT) to nowe podejście do tworzenia AJAX-owych aplikacji. GWT zostało przedstawione w maju 2006 roku, jest to więc nowa technologia. Technologia, która umożliwia tworzenie AJAX-owych aplikacji w Javie. Wykorzystuje więc moc i mnogość narzędzi tego bardzo popularnego języka. Sercem GWT jest kompilator, który kompiluje kod Javy do postaci JavaScriptu oraz HTML-a. Dla programistów pracujących głównie w Javie jest to niewątpliwie duże ułatwienie możliwość pisania w ulubionym języku przy pomocy tych samych narzędzi, z którymi na co dzień pracują programując w Javie. Jednak nie jest to jedyna innowacyjność. Jest ich o wiele więcej. A wszystkie one całkowicie zmieniają podejście do tworzenia web aplikacji. Google tworząc framework GWT postawiło mocny akcent na użytkownika to on jest najważniejszy. A najistotniejszym usprawnieniem dla końcowego użytkownika jest szybkość działania aplikacji. Dlatego w Google wykluło się powiedzenie Fast is better than slow. Na szybkość działania aplikacji składa się wiele różnorodnych technik, które zostały wprowadzone na potrzeby tego podejścia do tworzenia aplikacji. Na powstanie GWT, złożyło się wiele problemów w zarządzaniu typową AJAXową aplikacją. Problemów, które do tej pory nie zostały rozwiązane przez żaden z AJAX-owych frameworków, poza jak można się łatwo domyślić GWT. Do tych problemów należy przede wszystkim debugowanie aplikacji. Debugowanie w typowej AJAX-owej aplikacji występuje w czasie wykonywania programu. Każdy programista wie jak trudne do wykrycia i naprawienia są tego rodzaju błędy. W przypadku tworzenia dużej aplikacji może to stanowić olbrzymi problem dla zespołu i niekiedy doprowadzić nawet do niepowodzenia przy realizacji projektu. Proces debugowania w większym projekcie w tej sytuacji jest żmudny oraz długi, co automatycznie przekłada się na wzrost kosztów wdrożenia aplikacji. Podczas prac nad aplikacją AJAX-ową zespół programistów musi uporać się z problemem jak efektywnie zarządzać kodem. Istnieje również duże ryzyko utworzenia kodu spaghetti. Trudność sprawia nawet dokumentowanie aplikacji. 21

Jak widać tworzenie AJAX-owej aplikacji jest prawdziwym wyzwaniem nawet dla zgranego zespołu. Wspomnieć należy również o najgorszej sytuacji, w której znajdują się Web developerzy, a są nią same technologie, które wchodzą w skład AJAXa. Ponieważ AJAX składa się z szeregu różnych technologii, występujących w różnych wersjach, które jakby tego było mało, są inaczej interpretowane przez poszczególne przeglądarki, a te w dodatku mogą być w odmiennych wersjach web developer musi być prawdziwym ekspertem w tej dziedzinie. W typowym projekcie, często zdarza się, że developer większość czasu poświęca wyłapywaniu i naprawie błędów, zamiast wykorzystać go na rozwijanie projektu. Zjawisko to można nazwać wręcz plagą, która web developerów wręcz przyprawia o kołatanie serca. W końcowym rozrachunku problemy te dotykają również użytkowników, którzy albo otrzymują produkt nie zawsze poprawnie działający w ich ulubionej przeglądarce lub, jeśli wymagany jest bardzo stabilny produkt, jak dla przykładu aplikacje bankowe, użytkownicy dopłacą z własnej kieszeni za rozwiązanie tego rodzaju problemów. Tutaj z pomocą przychodzi GWT, które stara się większość takich problemów rozwikłać, jak również nie tworzyć nowych. Google Web Toolkit jednakże ma pewnie ograniczenie; otóż mechanizm, który służy do indeksowania stron internetowych w przypadku aplikacji opartych o GWT zawodzi. Zawodzi on także, w odniesieniu do typowych aplikacji AJAX-owych. Dzieje się tak ponieważ aplikacja oparta o GWT nie składa się, jak w wypadku typowych portali, z szeregu stron, oraz linków do nich prowadzących. Może się przez to zdarzyć, że taka aplikacja nie znajdzie się na samym szczycie w rankingu wyszukiwarek. Można próbować zaradzić temu poprzez stworzenie alternatywnego serwisu udostępniającego pewną minimalną funkcjonalność dla użytkowników z wyłączoną obsługą JavaScriptu. Serwis ten byłby jednocześnie indeksowany i zapewniłby możliwość wykrycia zawartości web aplikacji przez internetowe wyszukiwarki. Google Web Toolkit oparty jest na licencji Apache 2.0. Jest więc w pełni darmowy, co więcej, stale rosnąca społeczność użytkowników sprawia, że GWT wydaje się przyszłościowym frameworkiem do tworzenia web aplikacji. Pora więc na garść suchych faktów, które pozwolą łatwiej poznać GWT. 22

Poniżej przedstawione są korzyści, które czerpie użytkownik z wykorzystania GWT: szybka odpowiedź na akcję użytkownika Fast is better than slow od użytkownika nie jest wymagane instalowanie żadnego plugin-u, czy wirtualnej maszyny Javy (JVM) zarządzanie historią Natomiast korzyści, które czerpie developer z użycia GWT są następujące: jeden język programowania do zarządzania wszystkim! błędy komplikacji, zamiast błędów czasu wykonania testowanie JUnit wykorzystanie obiektowych właściwości języka Java łatwość zarządzania dokumentacją javadoc Po za tym web developer już nie musi być ekspertem w zarządzaniu niekompatybilnością i błędami, ponieważ to zadaniem GWT jest rozwiązywanie tego rodzaju problemów. W przypadku małych projektów developer może nawet nie wykorzystywać JavaScript. Nie ma więc potrzeby nauki kolejnego języka programowania. Developer skupiony jest na pisaniu w jednym języku (Java) tym, w którym jest ekspertem. Pisze w nim po stronie serwera jak było do tej pory, jak również po stronie klienta, z wykorzystaniem tych samych narzędzi, do których jest przyzwyczajony. To nie jest powolna ewolucja, z jaką mieliśmy do czynienia do tej pory, lecz z całą pewnością rewolucja, która może zmienić porządek rzeczy w Internecie. Do głównych komponentów wchodzących w skład GWT należą: Kompilator Java-JavaScript tłumaczenie kodu Javy na postać kodu JavaScript Biblioteki emulujące środowisko unieruchomienia Javy (JRE) implementacja w postaci JavaScriptu najczęściej używanych bibliotek Javy (większość klas wchodzących w skład pakietu java.lang oraz część klas wchodzących w skład pakietu java.util) Biblioteki klas interfejsu użytkownika User Interfaces (UI) zbiór interfesów i klas służących budowaniu interfejsu użytkownika Tryb urochomienia hosted mode umożliwia uruchomienie aplikacji na maszynie wirtualnej Javy nie ma konieczności kompilowania do postaci JavaScriptu i HTML-a, co ułatwia proces debugowania 23

Samo uruchomienie aplikacji GWT może odbyć się w jednym z dwóch trybów: Hosted mode aplikacja uruchamia się jako bytecode Javy na maszynie wirtualnej Javy (JVM) Web mode aplikacja uruchamia się jako JavaScript i HTML. Tryb ten z reguły jest używany do wdrażania aplikacji. Poniżej pokazano aplikację uruchomioną w trybie hosted mode. Rysunek 5: Aplikacja działąjca w trybie hosted mode 24

4.2 PODSTAWY GWT Przyszła już pora na omówienie serca Google Web Toolkit, sercem tym jest kompilator Java-JavaScript. Kompilator w bieżącej wersji GWT 1.5 potrafi kompilować kod Javy, jeśli kod źródłowy wykorzystuje konwencje znane z Javy 5.0. Mowa jest w tym momencie o kodzie wykorzystywanym po stronie klienckiej. Natomiast kod pisany po stronie serwera może wykorzystywać konwencje zawarte w Javie 5.0 jak i nowszych wersjach. Kompilator GWT wspiera kilka typów wynikowej postaci JavaScriptu, do tych typów zaliczamy tryb obfuscate (zaciemniony). Tryb zaciemniony sprawia, że wynikowy kod JavaScriptu przypomina zupę lub zbiór liter alfabetu, co czyni ten kod dla człowieka całkowicie nieczytelnym. W praktyce używany jest on do ukrywania implementacji. Istotną korzyścią wynikającą z jego stosowania jest również niewielki plik wynikowy powstały wskutek kompilacji, co ma wpływ na szybkość działania aplikacji. Im mniejszy plik, tym szybciej można go przesłać przez sieć. Pracownicy Google a uważają, że wielkość pliku ma wpływ na szybkość interpretowania go przez przeglądarki. Jest to więc przykład wykorzystania paradygmatu Fast is better than slow. Kolejnym trybem jest tryb pretty (ładny), który tworzy kod możliwym do odczytania przez człowieka. Natomiast tryb detailed (wyszczególnienie), przypomina tryb ładny, ale zawiera pełne nazwy klas oraz metod, co ułatwia śledzenie kodu JavaScript. Kompilator GWT: wspiera przechwytywanie wyjątków Javy bloki takie jak: try, catch oraz finalny są całkowicie akceptowalne nie wspiera mechanizmu refleksji oraz dynamicznego ładowania klas nie wspiera mechanizmu serializacji Javy, zamiast niego stosuje własne rozwiązania wspiera następujące typy: byte, char, short, int, long,float, double, Object, String, jak również tablice tych typów 25

GWT dostarcza emulację wykonania bibliotek JRE. Jednakże GWT emuluje tylko pewien zasób klas wchodzących w skład J2SE oraz J2EE. Dlaczego jedynie niewielki zasób klas jest emulowany? Z bardzo prostego powodu, ponieważ JavaScript, który jest językiem dość prostym, nie jest w stanie wykorzystać wszystkich dobrodziejstw wynikających z użycia nawet podstawowego zestawu klas Javy SE. Nie zapominajmy o tym, że środowiskiem uruchomieniowym JavaScriptu jest przeglądarka internetowa. Poniżej przedstawiono zbiór klas należących do pakietów java.lang, java.io, java.sql oraz java.util, które dostępne są dla kompilatora GWT. Tabela 4. Klasy z pakietu java.util dostępne w GWT Klasy AbstractCollection AbstractList AbstractMap AbstractQueue AbstractSequentialList Arrays ArrayList AbstractSet Collections Date EnumMap EnumSet HashMap HashSet IdentityHashMap LinkedHashMap LinkedHashSet LinkedList PriorityQueue Stack TreeMap TreeSet Vector Wyjatki/Błędy EmptyStackException NoSuchElementException TooManyListenersExcepion MissingResourceExcep tion Interfejsy Collection Comparator EventListener Enumeration List ListItereator Iterator Map.Entry Map RandomAccess Set Queue SortedMap SortedSet 26

Tabela 5: Klasy z pakietu java.sql dostępne w GWT Klasy Date Time TimeStamp Tabela 6: Klasy z pakietu java.io dostępne w GWT Klasy FilterOutputStream OutputStream PrintStream Interfejsy Serializable Tabela 7. Klasy z pakietu java.lang dostepne w GWT Klasy Boolean Byte Character Class Double Enum Float Integer Long Math Number Object Short StackTraceElement String StringBuffer StringBuilder System Throwable Wyjątki/Błędy ArithmeticException ArrayStoreException AsserationError ArrayStoreException ClassCastException Exception Error IllegalArgumentException IllegalStateExcetion IndexOutOfBoundsException ArrayIndexOutOfBoundsException NegativeArraySizeException NullPointerException NumberFormatException RuntimeException StringIndexOutOfBound- Exception UnsupportableOperation- Exception Interfejsy CharSequence Clonable Comparable Iterable 27

INTERFEJS UŻYTKOWNIKA USER INTERFACE (UI) Biblioteki wchodzące w skład interfejsu użytkownika są bardzo podobne do klas składających się na bibliotekę graficzną tworzącą Swing. Podobieństwo to jest celowe, a każdy programista, który kiedykolwiek używał Swinga programując w Javie bez problemu odnajdzie się w tym interfejsie. Biblioteki interfejsu użytkownika zawierają wstępnie zdefiniowane komponenty, które podczas kompilacji tłumaczone są na ich odpowiedniki w postaci JavaScriptu i HTML dla konkretnej już przeglądarki. Cały ciężar kompatybilności interfejsu użytkownika spada na GWT. Każdy, kto choć raz starał się stworzyć spójny, jak również działający interfejs użytkownika dla różnych przeglądarek wie, jak trudne jest to zadanie. Poniżej przedstawiony jest przykładowy komponent klasy Button interfejsu użytkownika GWT. Rysunek 6: Button przykład interfejsu użytkownika Interfejs użytkownika to nie tylko komponenty, ale również panele je przechowujące i jednocześnie stanowiące o układzie komponentów. Panel na szczycie hierarchii, od którego zaczyna się budowa układu graficznego to RootPanel. Domyślnie RootPanel dołączony jest do znacznika <body> w HTML-u, jednakże może zostać powiązany z innym elementem. Z założenia uzyskiwany jest on przy pomocy metody RootPanel.get(). Natomiast aby dołączyć go do innego elementu należy wywołać metodę RootPanel.get(String element). Wielkość każdego komponentu możemy kontrolować przy pomocy wywołań metod takich jak: setsize(), setwidth(), setheight(). Argumenty w wywołaniach tych metod są typu String, ponieważ typ ten jest akceptowalny przez kaskadowe arkusze stylów. 28

RootPanel może zawierać inne panele, które lepiej organizują układ graficzny. Poniżej przedstawiony został przykładowy panel DockPanel. Potrafi on organizować lokalizację komponentów w oparciu o położenie w stosunku do krawędzi. Rysunek 7: DockPanel przykład interfejsu użytkownika Wygląd każdego komponentu został wyszczególniony w kaskadowych arkuszach stylów (ang. CSS). Dzięki temu odseparujemy treść (w naszym przypadku są to komponenty) od prezentacji. Dzięki temu, że prezentacja znajduje się w oddzielnym pliku nie mieszamy treści i prezentacji, co pozwala lepiej zarządzać naszym kodem. Przykładowo, gdybyśmy chcieli powiększyć rozmiar tekstu wyświetlonego na przycisku w arkuszu stylów napisalibyśmy następującą regułę:.gwt-button { font-size: 150%; } Oczywiście możemy tworzyć na własne potrzeby nowe komponenty, jeśli te standardowe nie sprostają naszym oczekiwaniom. Dostępne są również niestandardowe komponenty tworzone zarówno przez społeczność użytkowników GWT, jak również przez firmy komercyjne. 29

IMAGE BUNDLE Jedną z nowości, którą wprowadziła w GWT firma Google jest Image Bundle, na potrzeby pracy pokuszę się o własne tłumaczenie tego określenia jako zbiór obrazków. Ale zanim przestawię zbiór obrazków opowiem, dlaczego firma Google wprowadziła to rozwiązanie w GWT. Jak wspomniałem, postawą wszystkich nowinek wprowadzonych w GWT jest paradygmat Fast is better than slow. Otóż pracownicy firmy Google zaproponowali rozwiązanie problemu, który w wielu aplikacjach czy stronach internetowych jest dość częsty. Przeglądarka internetowa pobiera z osobna każdy obrazek czy ikonę. Pamiętajmy, że protokół HTTP 1.1 ogranicza ilość zapytań dla danej domeny/portu do dwóch. W przypadku, gdy do pobrania jest spora ilość plików skutecznie zapychane jest łącze internetowe. Tym samym następuje spowolnienie działania aplikacji. Przeglądarka ma w założeniach wykorzystywać połączenie tylko dla naprawdę istotnej pracy. W pomyśle Google przeglądarka już nie pobiera kolejnych obrazków za każdym razem, gdy są potrzebne. Można było oczywiście próbować ich cache owania, ale pamiętajmy, że również dla obrazków, które znajdują się w pamięci przeglądarki, wysyłane są zapytania, czy dany obrazek nie uległ zmianie. Rozwiązanie Google sprawia, że przeglądarka wysyła tylko jedno zapytanie do serwera, otrzymując tylko jeden obrazek. Obraz ten składa się z tych wszystkich obrazków, dla których normalnie przeglądarka wysyłałaby zapytania. I to właśnie jest zbiór obrazków. Zbiór obrazków można utworzyć tylko z plików mających następujące typy: png, gif, jpg. Są to zarazem najczęstsze typy plików graficznych, jakie wysyłane są do przeglądarek.. Poniżej pokazany jest przykładowy zbiór obrazków, który powstał ze złożenia trzech plików graficznych. Rysunek 8: Przykład "Image bundle" 30

ZDALNE WYWOŁYWANIE PROCEDUR Zdalne wywoływanie procedur (ang. Remote Procedure Call RPC) to technologa, której początki sięgają połowy lat 70., dość popularna w 90., a która za sprawą GWT zyskała drugą młodość. W skrócie można powiedzieć, że GWT RPC to metoda polegająca na wywołaniu przez klienta kodu Javy znajdującego się na serwerze. Pozwala ona na przekazanie obiektów do/z serwera poprzez protokół HTTP. Każdy obiekt przekazywany przy pomocy GWT musi być serializowany. Poprawne użycie GWT RPC daje nam możliwość przeniesienia całej logiki interfejsu użytkownika na stronę klienta. Odciąża to znacząco stronę serwera, minimalizując ilość przesyłanych danych. Prawidłowa implementacja GWT RPC sprawia, że protokołem HTTP przesyłane są wyłącznie dane. Typy Javy, które są serializowane: Prymitywne: char, byte, short, int, long, boolean, float, double. String, Date oraz klasy opakowujące typy proste: Character, Byte, Short, Integer, Boolean, Float, Double Tablice serializowanych typów (włączając w to inne serializowane tablice) Klasy zdefiniowane przez użytkownika implementujące interfejs Serializable Kroki, które należy wykonać, aby zaimplementować GWT RPC: 1. Napisać dwa interfejsy serwisu: Synchroniczny interfejs Asynchroniczny interfejs 2. Zaimplementować serwis po stronie serwera 3. Konfiguracja serwisu w plikach: deskryptora web.xml w pliku definiującym moduł dostępu (rozszerzenie gwt.xml) 31

JAVASCRIPT NATIVE INTERFACE JavaScript Native Interface (JSNI) to jeden z ważniejszych elementów wchodzących w skład GWT. JSNI pozwala na wykonanie kodu JavaScript z poziomu języka Java. W tym miejscu należy przypomnieć, że wynikiem kompilacji w przypadku GWT jest zawsze JavaScript. Jest to więc bardzo potężne narzędzie, a przy tym pozwala ono na wywołanie metod Javy z poziomu kodu JavaScript. Mamy również możliwość wykorzystania obiektów Javy przez metody JavaScriptu. Zastosowanie JSNI daje nam ogromne perspektywy, ale musimy pamiętać o kilku problemach z tym związanych. Ponieważ kod, którym posługujemy się przy pisaniu jest niskopoziomowy, mogą pojawić się problemy dotyczące niekompatybilności przeglądarek. Również kod wykorzystywany przez JSNI jest trudnej optymalizowany przez kompilator GWT. Zastosowanie JSNI można porównać do wykorzystywania kodu assemblera w zwykłym programie. JSNI można użyć do: Implementacji metod Javy w JavaScripcie Wywołanie kodu Javy z poziomu JavaScriptu i odwrotnie Odczytywanie i zapisywanie pól Javy przy pomocy JavaScript Metody JSNI deklarowane są jako native, deklaracja ta informuje kompilator, że ma do czynienia z metodą macierzystą. Oprócz deklaracji metody jako native wymagany jest specjalny blok komentarza obejmujący cały kod napisany w JavaScripcie. Zaczyna się on od /*-{, natomiast kończy się na }-*/. Poniżej przedstawione jest przykładowe użycie metody JSNI do wywołania metody JavaScript alert z poziomu języka Java. Musimy zapamiętać, że kiedy w metodzie JSNI żądamy dostępu do obiektu okna lub obiektu dokumentu, dostęp ten musimy poprzedzić odpowiednio $wnd i $doc. public static native void alert(string msg) /*-{ }-*/; $wnd.alert(msg); 32

Jak już wspomniano, dzięki JSNI można również wywoływać kod Javy przy pomocy JavaScriptu. Aby to zrobić należy użyć specjalnej składni. [instance-expr.]@nazwa-klasy::nazwa-metody(parametry-sygnatury)(argumenty) Gdzie: instance-exp: kwalifikator egzemplarza klasy nazwa-klasy: to pełna nazwa klasy wraz z ścieżką dostępu do niej nazwa-metody: normalna nazwa parametry-sygnatury: parametry sygnatury Java Native Interface argumenty: aktualna lista parametrów przekazywana do metody Dostęp do pól Javy przy pomocy JavaScriptu realizowany jest przy pomocy następującej składni: [instance-expr.]@nazwa-klasy::nazwa-pola Poniższa tabela zawiera sygnatury metod używanych przez Java Native Interface (JNI) Tabela 8. Sygnatury metod Java Native Interface Typ sygnatury Typ Javy Z boolean B byte C char m short I int J long F float D double Ljava/lang/String String Lpełna_nazwa_klasy pełna_nazwa_klasy [ typ typ[] 33

A oto praktyczny przykład użycia JSNI: Package gogo; public class PrzykladJSNI { String mojepole; static int mojestatycznepole; void Foo(String s) { } // uŝycie s static void statycznyfoo(string s) { } // uŝycie s public native void bar(przykładjsni x, String s) /*-{ // Wywołanie metody Foo() na bieŝącej instancji klasy //PrzykladJSNI - dlatego uŝywamy słowa this this.@gogo.przykladjsni::foo(ljava/lang/string;)(s); // Wywołanie metody Foo() na egzemplarzu x klasy PrzykladJSNI x.@gogo.przykladjsni::foo(ljava/lang/string;)(s); // Wywolanie statycznej metody statycznyfoo @gogo.jsniexample::staticfoo(ljava/lang/string;)(s); // Czytanie pola z bieŝącej instancji klasy PrzykladJSNI var val = this.@gogo.przykladjsni::mojestatycznepole; // Zapis pola mojepole naleŝącego do klasy JSNI egzemplarza x x.@gogo.przykladjsni::mojepole = Val; // Odczyt statycznego pola - (kwalifikator egzemplarza nie //jest wymagany) @gogo.przykladjsni::mojestatycznepole = val; }-*/; 34

INTERNACJONALIZACJA - INTERNATIONALIZATION (I18N) Internacjonalizacja (I18n) w GWT może zostać przeprowadzona na klika sposobów, dzięki czemu programista ma możliwość wybrania właściwej w danym projekcie procedury. Jedno z rozwiązań I18n wykorzystanie statycznych znaków opiera się na plikach właściwości. Aby jednak jakakolwiek metoda internacjonalizacji mogła działać musimy dodać do pliku definiującego moduł GWT następującą sekcje: Listing: Plik konfiguracyjny (gogo.rzgw.main.gwt.xml) <module> <inherits name="com.google.gwt.i18n.i18n"/> </module> Po zdefiniowaniu sekcji konieczne jest utworzenie własnego interfejsu rozszerzającego klasę Constants. Aby, dla przykładu zlokalizować statyczny ciąg znaków discover, oraz objects tworzymy następujący interfejs: Listing: Interfejs MojeStale - (gogo.rzgw.mojestale.java) public interface MojeStale extends Constants { String discover(); String objects(); } Teraz należy skojarzyć powyższy interfejs z nowo utworzonym w tym celu plikiem właściwości MojeStale.properties: Listing: Plik właściwości (gogo.rzgw.mojestale.properties) discovery = discovery objects = objects 35

Dodawnie lokalizacji sprowadza się do tworzenia dla każdej z nich nowego pliku właściwości. Dodanie polskiej lokalizacji będzie wyglądało następująco: Listing: Plik właściwości (gogo.rzgw.mojestale_pl.properties) discovery = wyszukaj objects = obiekty Aby użyć zlokalizowanych stałych trzeba jeszcze utworzyć implementację interfejsu wykorzystując metodę GWT GWT.create(class): public void uzyjmojestale() { } MojeStale mojestale = (MojeStale) GWT.create(MojeStale.class); Window.alert(mojeStale.discover()); DOSTĘP DO ELEMENTÓW DOCUMENT OBJECT MODEL Document Object Model (DOM), czyli obiektowy model dokumentu to interfejs programistyczny, który pozwala programom i skryptom na dynamiczny dostęp, modyfikację struktury, zawartości i stylu dokumentu.[w3c]. Jak wiadomo, manipulowanie zawartością DOM HTML jest sercem aplikacji DHMTL i AJAX. W większości języków i środowisk programistycznych, manipulowanie DOM naśladuje konwencję ustanowioną przez World Wide Web Consortium (W3C). W poprzedniej wersji GWT 1.4, istniało pewne odstępstwo od tej konwencji. W tej właśnie wersji używana była klasa DOM, należąca do pakietu com.google.gwt.user.client. Klasa ta zawierała zbiór statycznych metod służących manipulowaniu obiektowym modelem dokumentu. Wersja bieżąca GWT 1.5, wprowadza pewną ilość nowych klas DOM umieszczonych w pakiecie com.google.gwt.dom.client. Te klasy wspierają konwencje nazewnictwa interfejsów HTML DOM dla Javy, pozwalają też na pisanie bardziej zwięzłego kodu, który równocześnie umożliwia większą kontrolę typów. 36

Poniżej przedstawiono przykładową funkcję, która tworzy nową tabelkę, a w jej komórkę wstawia tekst. Kod przedstawiono w starej oraz w bieżącej wersji GWT. Listing: Stara wersja GWT (1.4) public void tableexample() { Element table = DOM.createTable(); Element tr = DOM.createTR(); DOM.appendChild(table, tr); Element td = DOM.createTD(); DOM.appendChild(tr, td); DOM.setInnerText(td, "Stare podejście"); DOM.appendChild(getBodyElement(), table); } public static native Element getbodyelement() /*-{ return $doc.body;} -*/; Listing: Bieżąca wersja GWT (1.5) public void tableexample() { TableElement table = doc.createtableelement(); TableRowElement tr = table.insertrow(0); TableCellElement td = tr.insertcell(0); td.setinnertext("nowe podejście"); doc.getbody().appendchild(table); } Zmiany, które zaszły w bieżącej wersji GWT, spowodowały jednakże pewne zamieszanie dotyczące nazewnictwa. Istnieją dwie klasy Element, jedna z nich to pozostałość po wersji 1.4 GWT. Klasa ta znajduje się w pakiecie com.google.gwt.user.client, rozszerza ona klasę dodaną w wersji 1.5 GWT, a znajdującą się w pakiecie com.google.gwt.dom.client. Dzięki temu rozwiązaniu kod utworzony we wcześniejszych wersjach GWT może być również skompilowany w bieżącej wersji GWT. 37

DEFERRED BINDING Deferred Binding odroczone wykonanie, jest techniką używaną przez kompilator GWT do utworzenia i wybrania specyficznej implementacji klasy na postawie zbioru parametrów. [Google doc]. Można założyć, że technika ta stanowi odpowiedniki mechanizmu refleksji w Javie. Umożliwa ona stworzenie kilku wersji aplikacji w zależności od środowiska przeglądarki. Dzięki temu przeglądarka pobiera jedynie wersję dla niej utworzoną. Główną korzyścią tej metody jest redukcja wynikowego kodu JavaScript, który przeglądarka pobiera. Jest to osiągane poprzez redukcję kodu tylko do tego który jest niezbędny do uruchomienia w danej wersji przeglądarki oraz lokalizacji. Dlaczego użytkownik Firefoxa miałby pobierać kod specyficzny dla Safari, skoro nigdy tego kodu nie użyje?[google]. Przykładem zastosowania odroczonego wykonania jest internacjonalizacja. Kompilator GWT tworzy oddzielne wersje aplikacji dla każdego języka. Również klasy wykorzystywane w implementacji obiektowego modelu dokumentu posiłkują się tą techniką. Deferred binding jest jednym z kluczowych mechanizmów pozwalających tworzyć wysoce zoptymalizowany kod JavaScript. Mechanizm ten jest całkowicie konfigurowalny i nie wymaga edycji skompilowanego kodu GWT. Odroczone wykonanie jest konfigurowane przez edycje pliku modułu XML. Istnieją dwie metody implementacji odroczonego wykonania: Zastępstwo jedna klasa jest zastępowana inna w zależności od warunku Generator zbiór klas pochodnych jest automatycznie tworzony, a następnie zastępowany w zależności od warunku Zastępstwo (ang. Replacement) oznacza redefiniowanie jednej klasy inną w momencie kompilacji. Poniższy rysunek przedstawia hierarchię dziedziczenia dla klasy DOM. Analiza rysunku oraz fragmentu zawartości modułu DOM.gwt.xml pozwoli zrozumieć mechanizm zastępstwa. 38

Rysunek 9: Hierarchia dziedziczenia dla klasy DOM [opracowanie własne] Poniżej pokazano przykład zastępstwa dla klasy DOM. Listing: Fragment zawartości modułu DOM.gwt.xml (com.google.gwt.dom.client) <module> <inherits name="com.google.gwt.core.core"/> <inherits name="com.google.gwt.user.useragent"/> <replace-with class="com.google.gwt.dom.client.domimplopera"> <when-type-is class="com.google.gwt.dom.client.domimpl"/> <when-property-is name="user.agent" value="opera"/> </replace-with> <replace-with class="com.google.gwt.dom.client.domimplsafari"> <when-type-is class="com.google.gwt.dom.client.domimpl"/> <when-property-is name="user.agent" value="safari"/> </replace-with> </module> 39

Powyższy kod podpowiada kompilatorowi GWT, że powinien zamienić klasę DOMImpl klasą DOMImplOpera, jeżeli wartość właściwość user.agent jest równa opera. Aby utworzyć przykładowo egzemplarz klasy DOMImpl, należy wywołać statyczną metodę create() należącą do klasy GWT. static final DOMImpl impl = GWT.create(DOMImpl.class); 40

Rozdział 5: IMPLEMENTACJA APLIKACJI 41

5.1 ZAŁOŻENIA Zaprojektowana aplikacja ma na celu w interaktywny sposób prezentować zbiór fotograficzny będący w posiadaniu Regionalnego Zarządu Gospodarki Wodnej w Krakowie. Prace obejmują również skatalogowanie istniejącego zbioru oraz budowę bazy danych służącej do przechowywania tegoż zbioru. Aplikacja umożliwiać ma wygodny dostęp do takich atrybutów zbioru fotograficznego jak lokalizacja, czas czy kategoria uwidocznionego obiektu. W tym celu wykorzystano jedno z najmłodszych będących do dyspozycji rozwiązań Google Web Toolkit. Z racji wykorzystania GWT całe oprogramowanie tworzone jest w tym samym języku programowania Java. W pracy używa się jednego z darmowych środowisk developerskich takich jak: Netbeans lub Eclipse. Programista nie musi więc uczyć się obsługi innych narzędzi czy też nowych języków programowania. Bazą danych, którą posługujemy się w pracy jest MySQL. W publikacji celowo pomijam rozdział zapoznający czytelnika z budową bazy danych. Kolejnym założeniem jest to, aby stworzona web aplikacja mogła uruchamiać się na dowolnej przeglądarce internetowej. Aplikacja do poprawnego działania nie będzie potrzebować dodatkowych wtyczek. Oprogramowanie, które użyte jest do zbudowania, jak również oprogramowanie potrzebne do działania web aplikacji jest darmowe. 42

5.2 IMPLEMENTACJA TWORZENIE INTERFEJS UŻYTKOWNIKA W przypadku tradycyjnych stron internetowych interfejs użytkownika definiowany jest przez odpowiednie znaczniki HTML-a. Interfejs użytkowania w GWT tworzony jest przez wywołanie odpowiednich metod. Jest to całkowicie odmienne podejście. Komponenty utworzone przez GWT są w momencie kompilacji zamieniane na odpowiadające im znaczniki HTML-a oraz powiązany z nimi kod JavaScriptu.. Na potrzeby web aplikacji stworzono szereg komponentów, które wyodrębniono i umieszczono w osobnym pakiecie gogo.rzgw.client.view(rys.10). Rysunek 10: Klasy komponentów interfejsu użytkownika Powyższe klasy odpowiadają wyłącznie za stworzenie komponentów interfejsu użytkownika. Poniżej prezentacja jednej z wymienionych klas przybliżająca sposób budowy komponentów interfejsu użytkownika. Klasa Wyszukaj buduje przewijalny panel, który przypomina rozwiązanie stosowane w programie Microsoft Outlook. Klasa to rozszerza klasę Composite, dzięki czemu możemy zdefiniować własny komponent interfejsu. Należy pamietać, że tak zdefiniowany komponent inicjalizowany jest metodą initwidget(). Inicjalizacja tak zdefiniowanego komponentu może odbyć się tylko raz, w przeciwnym wypadku pojawi się błąd. Poniżej przedstawiono wygląd panelu Wyszukaj. 43

Rysunek 11: Komponent Wyszukaj Listing: Kod odpowiedzialny za stworzenie komponentu Wyszukaj. public class Wyszukaj extends Composite { private static StackPanel stackpanel = null; MyImageBundle myimagebundle = (MyImageBundle)GWT.create(MyImageBundle.class); MojeStale mojestale = (MojeStale) GWT.create(MojeStale.class); AbstractImagePrototype InfoImgPrototype = myimagebundle.infoicon(); AbstractImagePrototype TaskImgPrototype = myimagebundle.taskicon(); AbstractImagePrototype KMLImgPrototype = myimagebundle.kmlicon(); public Wyszukaj() { stackpanel = new StackPanel(); stackpanel.add(new Wyszukiwanie(), createheaderhtml(infoimgprototype.createimage(), mojestale.discover()),true); stackpanel.add(obiekty.getinstance(),createheaderhtml( TaskImgPrototype.createImage(), mojestale.object()), true); stackpanel.add(new KML(),createHeaderHTML( KMLImgPrototype.createImage(), "KML"), true); stackpanel.showstack(0); initwidget(stackpanel); } private String createheaderhtml(image image, String caption) { return "<table align='left'><tr>" + "<td>" + image + "</td>" + "<td style='vertical-align:middle'><b style='white-space:nowrap'>" + caption + "</b></td>" + "</tr></table>"; }} 44

Powyższy listing przedstawia tworzenie komponentu Wyszukaj. Można zauważyć sporą analogię do tworzenia interfejsu użytkownika w Swingu. Podobieństwo to jest celowe. Programista, który wcześniej programował interfejs przy pomocy Swinga powinien bez trudu odnaleźć się w interfejsie użytkownika GWT. Jest to całkowicie odmienne podejście w sposobie tworzenia interfejsów w porównaniu do tradycyjnych technik. Kod powyżej przedstawiony kompilowany jest do odpowiadających mu znaczników HTML-a. To zadaniem kompilatora GWT jest stworzenie odpowiadających znaczników i elementów. Poniżej przedstawiono fragment kodu HTML-a wygenerowanego przez kompilator GWT dla przeglądarki Firefox. Listing: Fragment Html-a wygenerowanego na podstawie klasy Wyszukaj. <table cellspacing="0" cellpadding="0" class="gwt-stackpanel"> <tbody> <tr> <td height="1" class="gwt-stackpanelitem gwt-stackpanelitemfirst"> <div> <table align="left"> <tbody> <tr> <td> <img border="0" style="background: transparent url(http://localhost/rzgw/gogo.rzgw.main/b73817fc244c5faa1c346540f1228 00D.cache.png) no-repeat scroll -324px -17px; width: 32px; height: 32px; -moz-background-clip: -moz-initial; -moz-background-origin: - moz-initial; -moz-background-inline-policy: -moz-initial;" src="http://localhost/rzgw/gogo.rzgw.main/clear.cache.gif" class="gwt- Image"/> </tr> </tr> </td> <td style="vertical-align: middle;"> </td> </tbody> </table> </div> </td> <b style="white-space: nowrap;">wyszukaj</b> 45

WYKORZYSTANIE IMAGE BUNDLE Technikę Image Bundle wykorzystano w budowie szeregu komponentów. Komponenty te zawierają obrazki. Jak wspomniano w poprzednim rozdziale, technika ta generuje na podstawie szeregu obrazków jeden obrazek. Przypomina ona technikę Image Spites. Jednakże w przypadku tej techniki programista uwolniony jest całkowicie od wstawiania odpowiednich selektorów w pliku CSS. Jedynym wymaganiem w stosunku do programisty jest zdefiniowanie interfejsu, który rozszerzać będzie interfejs ImageBundle. W intefejesie tym tworzymy metody zwracające obiekt klasy AbstractImagePrototype. Przed każdą metodą wstawiamy tag @gwt.resource, który informuje kompilator o nazwie obrazka. W implementowanej aplikacji interfejs służący budowie Image Bundle zdefiniowano w pliku MyImageBundle. Poniżej przedstawiono fragment listingu pliku MyImageBundle. Listing: Fragment pliku MyImageBundle. public interface MyImageBundle extends ImageBundle { /** * @gwt.resource gogo/rzgw/public/info.png */ public AbstractImagePrototype InfoIcon(); /** * @gwt.resource gogo/rzgw/public/kml.png */ public AbstractImagePrototype KMLIcon(); /** * @gwt.resource gogo/rzgw/public/task.gif */ public AbstractImagePrototype TaskIcon(); Aby móc skorzystać z powyższego interfejsu należy stworzyć egzemplarz klasy MyImageBundle. Egzemplarz ten tworzony jest wywołaniem metody GWT.create(). MyImageBundle myimagebundle = (MyImageBundle)GWT.create(MyImageBundle.class); 46

Mając już egzemplarz interfejsu MyImageBundle można wywołać uprzednio zdefiniowaną metodę zwracającą obiekt AbstractImagePrototype. Końcowym punktem jest wywołanie metody createimage() na powyższym obiekcie. Przykładem tworzenia obrazków jest poniższy fragment pliku TopPanel. Listing: Fragment pliku TopPanel przykład tworzenia zbioru obrazków za pomocą techniki Image Bundle. MyImageBundle myimagebundle = (MyImageBundle) GWT.create(MyImageBundle.class); AbstractImagePrototype RzgwHeader = myimagebundle.rzgwheader(); AbstractImagePrototype RzgwPolska = myimagebundle.rzgwpolska(); AbstractImagePrototype _1972 = myimagebundle._1972(); AbstractImagePrototype kosciol = myimagebundle.kosciol(); public TopPanel() { horizontal.add(_1972.createimage()); horizontal.add(kosciol.createimage()); horizontal.add(rzgwheader.createimage()); Poniżej przedstawiono wygenerowany plik zawierający zbiór obrazków na podstawie interfejsu MyImageBundle. Rysunek 12: Plik wygenerowany na podstawie interfejsu MyImageBundle 47

UŻYCIE KASKADOWYCH ARKUSZY STYLÓW W GWT wygląd każdego komponentu zależy od kaskadowych arkuszy styli (CSS). Domyślnie styl komponentu określony jest w regule, którą definiuje się następująco: gwt-<nazwa klasy komponentu>. Nic nie stoi na przeszkodzie, aby własnym komponentom nadawać własne style. Służy temu metoda setstylename(nazwa reguły), która za parametr przyjmuje nazwę odpowiedniej reguły. W aplikacji ustalono wygląd szeregu komponentów. Jednym z nich jest komponent Wyszukiwanie, w którym zdefiniowano, że regułą odpowiedzialną za wygląd jest rzgw-flextable. layout.setstylename("rzgw-flextable"); Poniżej na listingu przedstawiono regułę rzgw-flextable. Listing: Fragment pliku welcome.css przykład definiowania wyglądu komponentu..rzgw-flextable td { border: 1px solid #6565FF; padding: 3px; font-size: 12px; width: 270px; vertical-align: bottom; text-align: center; } Poniżej wygląd komponentu zdefiniowanego przez powyżej zdefiniowaną regułę. Rysunek 13: Przykład użycia CSS do zdefiniowania wyglądu komponentu 48

WYKORZYSTANIE INTERNACJONALIZACJA Internacjonalizacja w przypadku tej aplikacji została przeprowadzona w oparciu o pliki właściwości. Poniżej przedstawiono fragment kodu odpowiedzialnego za lokalizację dla komponentu Wyszukiwanie. Listing: Fragment pliku Wyszukiwanie przykład internacjionalizacji MojeStale mojestale = (MojeStale) GWT.create(MojeStale.class); ListBox kategorie = new ListBox(); kategorie.additem(mojestale.all(),"wszystko"); kategorie.additem(mojestale.flood(),"powodz"); kategorie.additem(mojestale.bridge(),"most"); kategorie.additem(mojestale.build(),"budowa"); Ato fragmenty pliku właściwości dla lokalizacji hiszpańskiej oraz angielskiej. Listing: Fragment pliku MojeStale_sp.properties. find = Encontrar category = Categoría river = Río place = Lugar years = Años search = Buscar Listing: Fragment pliku MojeStale_en.properties. find = Find category = Category river = River place = Place years = Years search = Search 49

Poniższe rysunki demonstrują użycie internacjonalizacji. Rysunek 14: Hiszpańska wersja komponentu Wyszukiwanie Rysunek 15: Anielska wersja komponentu Wyszukiwanie. 50

WYKORZYSTANIE JAVASCRIPT NATIVE INTERFACE JavaScript Native Interface (JSNI) to technika wykorzystania GWT, bez której stworzenie systemu opierającego się o mapy Google a nie byłoby w ogóle realne. W czasie powstania tej aplikacji firma Google nie udostępniała żadnej biblioteki umożliwiającej wykonanie funkcji JavaScript dostępnych dla Google Maps Api z poziomu GWT. Aby wstawić mapę oraz obsłużyć interakcje użytkownika związaną z obsługą map autor musiał sam napisać niezbędne funkcje obsługujące JavaScript. Stanowi to tym samym bardzo dobry przykład wykorzystania JSNI. Firma Google dopiero niedawno udostępniła bibliotekę umożliwiającą wgląd do Google Maps Api bezpośrednio z poziomu GWT bez pisania dodatkowego kodu JavaScript. Tym samym tworzona aplikacja wyprzedzała rozwiązania dostarczane przez Google a. Aby możliwe było dodanie mapy Google a stworzono specjalny komponent GMap2Widget. Komponent ten rozszerza klasę Widget. Zawiera on klasę GMap2, której konstruktor jest wywoływany w konstruktorze klasy Widget. Poniżej przedstawiono listing komponentu Widget. Listing: Kodu źródłowego komponentu Widget. public class GMap2Widget extends Widget { private GMap2 gmap2; public GMap2Widget() { Element e = DOM.createDiv(); setelement(e); int szerokosc = Window.getClientWidth(); int dlugosc = Window.getClientHeight(); gmap2 = GMap2.create(e, szerokosc, dlugosc); } } Klasa GMap2 stanowi opakowanie natywnego obiektu JavaScriptObject, który nie może być tworzony bezpośrednio. Obiekt ten powinien być deklarowany jako typ zwracany przez metodę natywną. Tą metodą na niżej przedstawionym listingu jest metoda create(). 51

Listing: Kod źródłowy komponentu GMap2. public class GMap2 extends JavaScriptObject { private static GMap2Impl impl = new GMap2Impl(); protected GMap2() {} public static final GMap2 create(element e,int szerok,int wysok){ return impl.create(e, szerokosc, wysokosc); } Pozostała jeszcze do omówienia klasa implementująca wyżej przedstawiony obiekt. Klasa ta to GMap2Impl. Stworzenie jej przedstawiało pewną trudność z uwagi na to, że należało dokładnie wczytać się we właściwości i funkcje obiektu JavaScript GMap2 dostarczanego w bibliotece Google Maps Api. Poniżej przedstawiono listing klasy GMap2Impl. Listing: Fragment kodu źródłowego klasy GMap2Impl. public class GMap2Impl { /*-{ var gmap2; * var markery[]; }-*/ public native GMap2 getgmap2()/*-{ return this.gmap2;}-*/; public native GMap2 create(element e, int szer,int wys)/*-{ var options = { size : new $wnd.gsize(szer-345, wys-140) } gmap2 = new $wnd.gmap2(e,options); gmap2.addcontrol(new $wnd.glargemapcontrol()); gmap2.addcontrol(new $wnd.gmaptypecontrol()); gmap2.addcontrol(new $wnd.gscalecontrol()); gmap2.addcontrol(new $wnd.goverviewmapcontrol()); gmap2.addmaptype($wnd.g_physical_map); gmap2.setcenter(new $wnd.glatlng(49.75,21.50), 8); gmap2.enablescrollwheelzoom(); return gmap2; }-*/; 52

Na powyższym listingu przedstawiono metodę create(), która zwraca obiekt JavaScript GMap2. Zastosowanie JavaScript Native Interface nie jest prostą sprawą, aczkolwiek dzięki tej technice otrzymujemy z poziomu GWT dostęp do wielu natywnych bibliotek JavaScript. Bez wykorzystania tych bibliotek tworzone aplikacje nie będą posiadać pewnych funkcjonalności. W przypadku pisania tej aplikacji, bez posłużenia się techniką JSNI w ogóle nie byłoby wykonalne wstawienie mapy Google a. Technika ta daje ogromne możliwości integracji już istniejącego kodu JavaScript z GWT. Korzystając z niej musimy jednakże pamiętać o tym, że kompilator GWT nie jest w stanie efektywnie go zoptymalizować. GWT RPC W aplikacji implementacja zdalnego wywoływania procedur (RPC) ma na celu wyszukiwanie obiektów o pożądanych przez użytkownika parametrach. Do specyfikacji parametrów służy prezentowany wcześniej komponent Wyszukiwanie. Składa się on z szeregu rozwijanych list umożliwiających wybór odpowiednich parametrów. Po sprecyzowaniu właściwości takich jak: kategoria poszukiwanego obiektu, rzeka, na jakiej jest zlokalizowany, miejsca oraz zakres lat. Serwis, który jest zdefiniowany w części serwerowej ma możliwość przepytania bazy danych pod kątem istnienia określonych przez użytkownika parametrów. Jeśli takowe obiekty istnieją serwis w odpowiedzi przesyła ich listę. Przyjrzyjmy się teraz implementacji interfejsów po stronie klienckiej. Listing: Kod źródłowy synchronicznego interfejsu Szukaj public interface Szukaj extends RemoteService { /** * @gwt.typeargs <gogo.rzgw.client.model.obiekt> */ public ArrayList<gogo.rzgw.client.model.Obiekt> myszukaj(string s); } 53

Listing: Kod źródłowy asynchronicznego interfejsu SzukajAsync. public interface SzukajAsync { } public void myszukaj(string s, AsyncCallback callback); Jak widać definiowanie interfejsów po stronie klienckiej jest czynnością dość łatwą. Pozostaje jeszcze zdefiniowanie kodu po stronie serwera. Serwis, który definiowany będzie po stronie serwera, musi implementować synchroniczny interfejs, który został uprzednio zdefiniowany. Serwis ten musi również rozszerzać klasę RemoteServiceServlet. Aby wykonać połączenie i otrzymać wygenerowaną odpowiedź, konieczne jest stworzenie danego serwisu używając znanej funkcji GWT.crete(). Funkcja ta zdefiniowana została w specjalnej klasie Controller, która tworzy instancje serwisów oraz odbiera i zarządza odpowiedzią serwera. Otrzymana odpowiedź serwera powinna być w jakiś sposób zarządzana. Służy temu implementacja asynchronicznego obiektu nasłuchującego odpowiedzi. Po zdefiniowaniu wszystkich tych interfejsów pozostaje tylko wykonanie zapytania. 54

5.3 PREZENTACJA DZIAŁANIA APLIKACJI WYGLĄD INTERFEJSU UŻYTKOWNIKA Aplikacja podzielona została na trzy odrębne panele (rys.16). Panel umieszczony na górze strony (kolor obramowania zielony) stanowi element dekoracyjny. Zawiera on z prawej strony linki do zmiany języka wyświetlania strony. Panel po lewej Wybór i Lista (kolor czerwony) zawiera komponenty, które ułożone są jeden nad drugim. Komponenty te to Wyszukaj, Obiekt oraz KML. Zawartość tylko jednego z nich może być w danej chwili wyświetlona. Posiadają one nagłówek, który w momencie klikniecia na niego rozwija zawartość komponentu. Panel zajmujący najwięcej miejsca (kolor niebieski) zawiera mapę Google a. Na mapie tej wyświetlane są markery. Poniższy rysunek obrazuje widok ogólny aplikacji. Rysunek 16: Widok ogólny aplikacji 55

Użytkownik przy pomocy panelu znajdującego się po lewej stronie (rys.17) ma możliwość wyboru charakterystki poszukiwanych przez siebie obiektów. Do wyboru są kategorie obiektu hyrotechniczego bądź zjawiska hydrologicznego. Kolejną opcją jest wybór rzeki oraz miejsca. Możliwe jest też określenie przedziału lat. Użytkownik w momencie wybrania charakterystyki poszukiwanych obiektów wysyła odpowiednie zapytanie do serwera, który przesyła w odpowiedzi poszukiwaną przez użytkownika listę obiektów. Lista ta jest prezentowana w komponencie Obiekty. W momencie odbioru danych komponent Obiekty automatycznie rozwija się przedstawiając otrzymane informacje(rys. 18). Rysunek 17: Panel służący do wyszukiwaniu obiektów oraz prezentacji listy wyników 56

Rysunek 18: Rozwinięty komponent "Obiekty" prezentujący listę wyników wyszukiwania Klikniecie na któryś z obiektów znajdujących się na liście automatycznie zmienia widok mapy tak, aby prezentowała ten obiekt. Użytkownikowi w momencie klikniecia na marker obiektu pokazywane jest okienko z informacją o obiekcie, które zawiera również zdjęcie prezentowanego obiektu. Okno to mieści dwie zakładki. Zawartością drugiej zakładki Info jest krótki opis prezentowanego obiektu. Poniżej przedstawiono zawartość zakładki Info. Rysunek 19: Okno informacyjne zakładka Info 57