1.
Google Web Toolkit
Tutorial
Anişoara Sava, OC2
Marcela Daniela Mihai, OC2
10/19/2009

2. Table of Contents
1. Prezentare generală ................................................................................................................ 3
2. Principii de bază GWT .............................................................................................................. 3
3. Arhitectura GWT ...................................................................................................................... 4
3.1 Structura unui proiect GWT ................................................................................................. 6
3.2 Interoperabilitatea cu Standardele Web şi Serviciile Web ................................................... 8
4. Instrumente GWT .................................................................................................................... 8
4.1 Compilatorul Java‐to‐JavaScript ........................................................................................... 9
4.2 JSNI (JavaScript Native Interface) ....................................................................................... 11
4.3 Widget‐uri şi Panel Library ................................................................................................ 12
4.4 Protocolul Remote Procedure Call (RPC) ............................................................................ 13
4.5 Managementul butonului “Back” al browser‐ului / Browser History ................................ 16
4.6 Integrarea JUnit cu GWT .................................................................................................... 17
5. Modul Host vs Modul Web .................................................................................................... 18
6. Utilitatea GWT ....................................................................................................................... 23
7. Comparație cu alte framework‐uri ........................................................................................ 24
7.1 GWT vs SWING .................................................................................................................... 24
7.2 GWT vs. Echo2 .................................................................................................................... 25
7.3 GWT vs JSF .......................................................................................................................... 25
7.4 GWT vs Ruby on Rails .......................................................................................................... 26

3.
1. Prezentare generală
Platforma Web 2.0 împreună cu tehnologia Ajax din cadrul acesteia, a câştigat tot mai
multă atenție datorită faptului că pentru aplicațiile web, cel mai important beneficiu adus de
Ajax îl constituie îmbunătățirea experienței utilizatorilor.
Deşi JavaScript şi DHTML ‐ limbaje aflate la baza tehnologiei Ajax ‐ sunt disponibile de
câțiva ani, cei mai mulți programatori încearcă să le evite datorită dificultății de folosire a
acestora. Astăzi, framework‐uri scrise în JavaScript precum Dojo, pot fi folosite pentru
realizarea aplicațiilor Ajax, însă, acest fapt necesită cunoştințe solide de JavaScript. Ca soluție la
acestă problemă, Google vine în sprijinul programatorilor Java, cu un nou framework pentru
crearea de aplicații Ajax mult mai productive: Google Web Toolkit (GWT).
2. Principii de bază GWT
Pe parcursul ultimilor ani, s‐au dezvoltat numeroase framework‐uri Java pentru realizarea
aplicațiilor web. Din prima generație de astfel de framework‐uri face parte venerabilul Apache
Struts, iar a doua generație cuprinde framework‐uri precum Tapestry şi JavaServerFaces.
Google Web Toolkit dă startul celei de‐a treia generații de framework‐uri, oferind, la fel ca cea
de‐a doua generație, suport pentru folosirea componentelor (componentele pot fi folosite de
dezvoltatori pentru crearea de noi componente care pot fi adăugate în aplicație pentru
îmbunătățirea funcționalității paginlor web), numite în GWT widgets, însă se diferențiază de
predecesorii săi prin faptul că nu este o tehnologie care foloseşte clasicele form‐uri. GWT este
primul framework pentru crearea de aplicații web folosind limbajul Java care permite realizarea
de aplicații asemănătoare cu cele pentru desktop, dar care sunt rulate în browser. Cu această
inovație, dezvoltatorii pot renunța la construcția de aplicații web compuse din “arhaicele”
pagini, trecând la aplicații care rulează într‐o singură fereastră a browserului, similar cu
aplicațiile pentru desktop construite cu AWT, Swing sau SWT. Astfel, GWT nu e o evoluție, ci o

4. revoluție deoarece desființează în totalitate fundamentele modalității de construire a
aplicațiilor web.
Google Web Toolkit(GWT) este un set de unelte de dezvoltare, utilități de programare şi
widget‐uri care permit crearea cu uşurință a aplicațiilor AJAX. Această tehnologie este
disponibilă open‐souce sub licență Apache 2.0 pentru platformele: Windows, Mac OS X şi Linux.
Cea mai importantă parte a GWT‐ului poate fi considerat compilatorul responsabil cu
transformarea codului Java în cod JavaScript pentru a putea fi rulat in browser. Această inovație
adusă de GWT este foarte importantă, însă nu este singurul lucru care face ca această nouă
tehnologie să fie deosebită.
GWT vine şi cu: un echipament de testare folosit pentru depanarea bytecodului Java în mod
direct atunci când este rulat în mediul oferit de GWT ce simulează browserul, un set de widget‐
uri principale pentru construirea interfeței cu utilizatorul, precum şi un sistem Remote
Procedure Call pentru realizarea comunicației cu serverul web. Pe scurt, GWT reuneşte
avantajele oferite de librăriile JavaScript, abilitățile de comunicare ale DWR –ului, precum şi
avantajele uneltelor Java din Echo2 sau XML11, într‐un singur pachet.
3. Arhitectura GWT
GWT continuă să folosească HTML şi CSS deoarece sunt relativ simple, încă eficiente şi
suportate în mod nativ de browsere. O aplicație GWT bine realizată se va baza pe patternul
MVC, însă se va întoarce şi la modelul de programare client‐server.
Cu GWT se va folosi MVC pe partea de client. MVC este un şablon architectural
proiectat pentru separarea responsabilităților în cadrul aplicațiilor software. Pentru aplicațiile
web, MVC presupune o defalcare în trei straturi: modelul reprezentat de informațiile de pe
partea de server, view‐ul oferit de către HTML şi controller‐ul reprezentat de o pagină sau un
servlet de pe server, acestea având propriile responsabilități.
În mediul GWT (similar cu alte aplicații bazate pe AJAX), toate aceste responsabilități ale
aplicației sunt mutate de pe server pe client.

5. View‐ul generat de server prin tehnologii de genul JSP, este înlocuit cu componente pentru UI
inteligente care leagă informațiile din cadrul lor de modelul aplicației.
Modelul este sincronizat cu serverul prin intermediul unor tehnici tradiționale care permit
comunicarea dintre server şi client.
Această modalitate de a folosi MVC pe client oferă posibilitatea clientului de a coordona cele
mai multe tranziții de stare din UI precum şi relaționarea logică a interfeței, fără a mai apela la
serviciile serverului.
Acest lucru presupune îmbunătățirea performanței şi a scalabilității chiar dacă lățimea de bandă
sau latența rețelei prezintă probleme. Această îmbunătățire derivă din faptul că clientul poate
să dirijeze mai multe responsabilități, fără a fi nevoit să comunice cu serverul pentru a modifica
view‐ul pentru acelaşi set de date. Mai mult, se pot obține infomații ale aplicației sau
sincronizări cu serverul printr‐o metodă elegantă, asincronă, care oferă la rândul ei avantaje.
O caracteristică a GWT‐ului este că trebuie să fie prezentă şi pe server o reprezentare a
modelului, iar modelul de pe client trebuie să comunice cu serverul pentru a obține sau
sincroniza informațiile; acesta comunicare este realizată prin intermediul mecanismului RPC şi a
facilităților oferite de serializarea obiectelor.
Pentru a face posibilă comunicarea dintre server şi client, GWT foloseşte implementarea
serviciul SOA (Service Oriented Arhitecture), permițând astfel controller‐ului de pe client să
invoce seviciile puse la dispoziție de către server şi să actualizeze modelul de pe client când este
nevoie. Reprezentările modelului de pe client şi server pot folosi aceleaşi obiecte, sau copii
exacte ale acestora, GWT putând serializa şi deserializa automat datele din JavaScript în Java şi
viceversa.
Următoarea figură este o diagramă simplificată care descrie modalitatea de sincronizare între
serverul şi clientul GWT, facilitată de mecanismul RPC oferit de GWT şi capabilitățile oferite de
serializarea/deserializarea obiectelor.

6.
Din
D mai mu
ulte puncte de vedere GWT rep
e, prezintă o reîntoarcere la tradițio
e onala
arhitectu
ură cu trei st
traturi, unde
e aplicația cl
lient este res
sponsabilă c
cu tratarea t
tuturor acțiu
unilor
efectuate
e de utilizator şi cu com
municarea cu
u serverul ca
are oferă accesul asupra
a datelor sto
ocate
într‐un m
mod persistent de genul RDBMS (Rel
lational Data
abase Management Syst
tem).
Acest mo
odel împreună cu avanta
ajul de a nu avea nevoie
e de altceva
a înafară de browser instalat,
duce la o îmbunătăț consider
o țire rabilă a experienței util
lizatorului asupra utiliză aplicațiilor ce
ării
conțin se
ervere web.
3.1 Structu
3 ura unui p
proiect GW
WT
Un
U proiect GWT are o st
G tructură sim
milară cu stru
uctura unui pachet Java Pachetul GWT
a.
inițial, ge
enerat atunci când con
nstruim un p
proiect GWT nou, difer
T rențiază în m vizibil unde
mod
trebuie s se afle co
să odul sursă p
pentru partea de client față de co
t odul sursă p
pentru parte de
ea
server şi față de resu
urse.
Un proiect GWT arat
tă în felul urm
mător:

7. Pachetul principal al proiectului. Acesta conține
com/example/app toate modulele proiectului, şi nu poate conține
fişiere cu cod.
Subpachetul care conține toate fişierele cu codul
com/example/app/client
sursă pentru partea de client.
Subpachetul care conține toate fişierele cu codul
com/example/app/server
sursă pentru server.
Subpachetul care conține toate resursele statice
com/example/app/public
de care este nevoie în aplicație.
Fiecare proiect GWT poate fi alcătuit din unul sau mai multe module. Citând definiția dată de
Google, un “modul GWT este pur şi simplu o încapsulare a funcționalității”. Modulul reuneşte
toate configurările necesare pentru a utiliza codul pe care îl scriem într‐un proiect GWT.
Modulele sunt definite în aplicație în cadrul fişierelor descriptor XML a căror denumire se
termină cu extensia .gwt.xml. Conceptul descriptorului de modul din GWT este similar
descriptorilor din Tomcat sau alte servere de aplicații.
Conținutul unui fişier descriptor XML este folosit pentru a specifica:
Modulele moştenite, cele din care aplicația moşteneşte setări şi cod.
Numele unei clase ce reprezintă punctul de intrare în aplicație (opțional); o clasă de tip
entry point este o clasă ce implementeză interfața EntryPoint. Când un modul este
încărcat, fiecare clasă entry point definită în fişierul .gwt.xml este instanțiată şi apelată
metoda onModuleLoad() din cadrul acesteia. Este posibil să creăm un modul cu mai
mult de o clasă entry point, şi de asemenea este posibil să creăm un modul cu nicio
clasă de tip entry point, acest tip de modul fiind folosit ca o librărie GWT de cod
reutilizabil.
Intrările Source Path, folosite pentru a specifica care subpachet conține codul sursă care
urmează a fi transformat în JavaScript. Subpachetul care conține codul pentru client este
inclus automat în source path.

8. Intrările Public Path, folosite pentru a specifica care subpachete sunt publice (vizibile în
toată aplicația). Toate fişierele aflate in Public Path vor fi copiate în directorul de ieşire a
modulului în momentul când aplicația este compilată.
3.2 Interoperabilitatea cu Standardele Web şi Serviciile Web
GWT nu încearcă să fie doar un framework cu care se pot construi aplicații; el se vrea a fi
un set de unelte care îmbunătățeşte vizibil posibilitatea de a crea aplicații Ajax. Pentru a
îndeplini acesta este necesar să fie îmbinate standardele web actuale şi serviciile web. Astfel,
GWT nu îndrumă spre o singură tehnologie, ci permite folosirea oricărei tehnologii.
În particular, GWT furnizează librăriile JSON şi XML care permit translatarea datelor în
alte tipuri de obiecte. De asemeni GWT oferă o modalitate de a conecta componentele care
alcătuiesc interfața cu fişierul CSS pentru a putea profita de beneficiile aduse de această
tehnologie. Pentru a obține efecte mai spectaculoase acest toolkit permite integrarea cu alte
librării JavaScript existente prin intermediul JavaScript Native Interface (JSNI), o modalitate de
a utiliza cod JavaScript în cadrul codului Java.
4. Instrumente GWT
GWT oferă un set amplu de unelte necesare pentru rezolvarea problemei mutării
aplicațiilor tip desktop în browser. Toolbox‐ul GWT conține un parser XML, mai multe
instrumente pentru comunicarea cu serverul, unelte pentru configurare şi internaționalizare
precum şi un sistem de management al istoriei paginilor vizualizate în browser.
Următoarea figură constituie o hartă vizuală a aspectelor centrale ale GWT‐ului, acestea fiind
împărțite în două categorii: cele legate de compilator şi librăriile Java care alcătuiesc API‐uri
GWT.

9.
4.1 Compilatorul Jav
4 va­to­JavaS
Script
Responsabilit
tatea compil
latorului GW
WT este să co
onvertească codul Java î
în cod JavaScript,
într‐o m atorul care transformă codul Jav în bytec
maniera asemănătoare cu compila ă va code.
Compilar
rea pro
oiectului se face
f de către
e prog
gramul Java
com.go
oogle.gwt TCompiler căruia i se dă ca para
t.dev.GWT r e ametru loca unde se află
ația e
fişierul de definiție al modulului.
Procesul de compilare începe cu
u clasa entry
y‐point, urm
mând apoi de
ependințele necesare pe
entru
a compila codul Java Compilato GWT lu
a. orul ucrează diferit față de u compilator standard Java
un
deoarece acesta nu compilează tot ce se gaseşte în modul, ci n
e ă numai ceea ce este fo
a olosit.
Acesta lucru este avantajos deoarece pe
a ermite să se poată de
e brarie amplă de
ezvolta o lib
ente şi tool‐uri, iar com
compone mpilatorul v include n
va numai acele clase şi m
e metode care sunt
folosite d
de clasa entr
ry‐point.
Compilat
torul are trei tipuri de st
tiluri care de
etermina cum
m va arăta c
codul Java Sc
cript rezultat
t:
plicit este cel obfusca şi face ca codul JavaScript să arate ca o
stilul imp ate
amesteca re ceea ce îl face a fi imp
atură de liter posibil de de pul acestui stil nu
escifrat. Scop

10. este de a face imposibil de citit codul ci pentru a menține fişierul JavaScript cât mai
mic posibil.
Un exemplu de cod care are acest stil arată în felul următor:
function b(){return this.c + '@' + this.d();}
stilul pretty, generează cod JavaScript care poate fi citit cu uşurința.
Pentru exemplificare vom folosi acelaşi cod ca la stilul anterior. De acesta dată ne putem
da seama că este metoda toString(), însă încă nu putem şti din care clasă este această
metoda:
function _toString(){
return this._typeName + '@' + this._hashCode();
}
stilul detailed, care seamănă cu stilul pretty, cu completarea că, vom avea numele
complet al clasei din care face parte metoda, ca parte a numelui metodei JavaScript
function java_lang_Object_toString__(){
return this.java_lang_Object_typeName + '@' +this.hashCode__();
}
Stilurile pretty şi detailed sunt folosite îndeosebi în procesul de dezvoltare pentru a putea
detecta cu uşurința eventualele erori JavaScript apărute în browser.
Un alt aspect important al compilatorului GWT este că acesta foloseşte codul sursă Java,
nu codul Java binar. Acesta presupune că, codul sursă pentru toate clasele Java să fie
disponibile. Acest lucru este important şi atunci când vrem să distribuim cod GWT pentru a fi

11. refolosit. Când se construiesc fişiere .jar, care urmează a fi distribuite, trebuie să fie incluse atât
clasele Java cât şi fişierele cu cod sursă.
O ultimă caracteristică notabilă este aceea că după compilarea codului Java în
JavaScript, rezultă un singur fişier JavaScript pentru fiecare tip de browser. Browser‐ele pentru
care se generează fişiere JavaScript sunt: Internet Explorer, Firefox, Mozillla, Opera şi Safari.
Când este rulat scriptul de pornire pentru browser (bootstrap), acesta încarcă fişierul
corespunzător pentru browserul respectiv. Avantajul este că nu se va mai încarca cod pe care
browserul nu va putea să îl folosească.
4.2 JSNI (JavaScript Native Interface)
Cu toate că codul GWT trebuie scris in Java, uneori pot apărea situații cand trebuie să
facem apeluri directe la cod JavaScript. O astfel de situație este atunci când trebuie să facem
apel la API‐ul browser‐ului pentru care nu există echivalent în GWT. O altă situație poate apărea
atunci când vrem să utilizăm în aplicația noastră anumite librării JavaScript mai deosebite.
Accesând JavaScript direct, aplicația este expusă incompatibilităților dintre browsere. Va
fi nevoie de teste extra pentru a avea siguranța că, codul JSNI va funcționa pe mai multe
browsere.
JSNI permite execuția codului JavaScript din codul Java, precum şi viceversa. Acest lucru
este făcut posibil de către compilatorul GWT care poate îmbina cod nativ JavaScript cu cod
JavaScript generat dupa compilarea codului Java.
Pentru a scrie o metodă pură JavaScript prin intermediul JSNI trebuie doar să declarăm acea
metodă ca native şi să furnizăm implementarea în JavaScript între comentarii:
public native void fillData (String msg)
/*-{
$wnd.alert(msg);
}-*/;

12. De asemenea, GWT oferă şi o modalitate pentru a apela cod Java în cadrul codului
JavaScript. Signatura unei astfel de metode este următoarea: [instance-expr.]@class-
name::method-name(param-signature)(arguments), unde [instance-expr.] specifică
faptul că este vorba de o metodă ne‐statică.
4.3 Widget­uri şi Panel Library
GWT vine cu o gamă largă de widget‐uri şi panel‐uri care pot fi folosite în codul Java al
aplicațiilor Ajax. Acestea sunt construite cu HTML, iar JavaScript este folosit pentru tratarea
evenimentelor; atunci când codul aplicației este compilat şi transformat în JavaScript, browserul
încarcă aceste componente în cadrul unei pagini web tradiționale, fără a fi nevoie de plugin‐uri
sau JRE.
Există trei categorii de componente pentru crearea interfeței cu utilizatorul: widget‐uri, panel‐
uri pentru aşezare şi panel‐uri interactive.
Lucrul cu aceste componente este asemănator cu cel din Swing şi AWT (Abstract
Window Toolkit), cu diferența că GWT oferă în loc de layout‐manageri, un set de panel‐uri
care afişează elementele componente într‐o maniera anume. De exemplu, HorizontalPanel
afişează elementele de la stânga la dreapta, FlowPanel afişează folosind regulile de la fluxul
HTML, iar AbsolutePanel foloseşte poziția exactă a componentelor pe care le conține.
Pentru a crea o interfață cu utilizatorul, trebuie să instanțiem aceste widget‐uri, apoi să le
adăugăm panel‐urilor, care la rândul lor trebuiesc adaugate panelului principal al aplicației
(Root Panel). Panelul principal este un container de nivel înalt, care conține toate
componentele unei interfețe.
GWT‐ul vine cu componente care sunt deseori intâlnite la aplicațiile desktop şi mai rar la
cele web. Un astfel de exemplu este TabPanel care permite plasarea widget‐urilor în taburi
diferite, fiind vizibile la un moment dat doar widget‐urile de pe un singur tab.

13. Alte exemple de acest fel de componente sunt: MenuBar, care oferă o cale usoară de a crea un
meniu cu mai multe nivele, PopupPanel, StackPanel etc.
Trebuie să observăm, însă, că widget‐urile din GWT nu intenționează să semene perfect cu cele
dintr‐o aplicație pentru desktop; astfel, ele se integrează bine cu browserul şi oferă o experiență
familială utilizatorului. De asemenea, aplicația creată cu GWT poate fi integrată cu oricare parte
a unei pagini HTML, însă permițându‐i să arate ca o pagină web obişnuită.
Există peste 30 de widget‐uri şi panel‐uri conținute în pachetul
com.google.gwt.user.client.ui din GWT, însă e puțin probabil ca acestea să satisfacă toate
nevoile dezvoltatorilor. Lista widget‐urilor din GWT cuprinde calendare, tabele sortabile,
calculatoare, panel‐uri pentru desenare, panel‐uri cu rol de tooltip etc. Există, de asemeni,
widget‐uri care includ librării JavaScript, cum sunt Google Maps API, Google Search API, sau
efecte obținute cu Scriptaculous. Înafara widget‐urilor de bază pentru HTML, există şi widget‐
uri disponibile pentru Scalar Vector Graphics (SVG).
Există şi posibilitatea să ne creem propriile noastre widget‐uri extinzându‐le pe cele din
GWT, însă este recomandat ca atunci când recurgem la această posibilitate să accesăm obiecte
JavaScript care se află la baza browser‐elor.
4.4 Protocolul Remote Procedure Call (RPC)
Din punctul de vedere al locului unde este rulat codul, aplicațiile Ajax în general şi cele
GWT în particular se încadrează în categoria Rich Internet Applications(RIA). Acest tip de
aplicații sunt o combinație între Fat client applications, unde codul rulează doar pe maşina
utilizatorului (ex. Microsoft Word), şi Thin client applications unde codul rulează pe o maşină
server, iar desktopul clientului este folosit doar pentru afişarea interfeței prin intermediul unui
browser (aici se încadrează majoritatea aplicațiilor web: Ebay, Amazon etc).
Faptul că se încadrează în ambele categorii oferă GWT‐ului complexitate şi interactivitate,
deoarece poate profita de anumite puteri de procesare pe partea de client.

14. De fiecare dată când avem cod care rulează în doua părți diferite, avem nevoie de un
mecanism pentru a comunica între cele două. Cea mai simplă modalitate în această situație o
reprezintă apelul procedurilor la distanță (Remote Procedure Call), care presupune o cale prin
care clientul să execute codul pe server şi să primească rezultatul execuției; în acestă situație
poate fi folosit oricare dintre următoarele protocoalele RPC: RMI, .NET Remoting, SOAP, REST
sau XML‐RPC. Însă GWT nu foloseşte nici unul dintre acestea, având implementat propriul
protocol de tip RPC, aceasta pentru a putea realiza apelurile asincrone de la browser.
În GWT librăria RPC este divizată în două pachete:
pachetul com.google.gwt.user.client.rpc folosit pe partea de client şi
pachetul com.google.gwt.user.server.rpc folosit pe partea de server.
Partea pentru client oferă interfețele necesare pentru interconectarea interfețelor aplicației
care vor fi folosite pentru implementarea RPC‐ului. Când este transformat codul de pe client în
cod JavaScript de către compilatorul GWT, codul folosit pentru RPC este generat pe baza
interfețelor interconectate.
Pachetul pentru partea de server folosit pentru implementarea RPC‐ului este construit astfel
încât să fie folosit într‐un container de servleturi Java cum este Tomcat sau Jetty. Din fericire,
browser‐ul host oferit de GWT conține un server Tomcat integrat, şi astfel pot fi testate şi
depanate apelurile RPC de pe server în orice IDE care oferă suport pentru GWT.
S‐a mers pe ideea ca protocolul trebuie să fie simplu. Browser‐ul descarcă tot codul de
la client când acesta porneşte aplicația , iar dacă codul depăşeşte 100K atunci se va observa o
pauză. De astfel, codul JavaScript care rulează în browser este destul de lent, aşa încât
implementarea unui protocol complex precum SOAP ar presupune descărcarea unei cantități
mari de cod care ar incetini considerabil execuția. Astfel, când mecanismul oferit de RPC este
folosit în mod corespunzător, oferă avantajul de a muta tot codul pentru logica UI pe client,
obținând astfel vizibile creşteri de performanță, reducerea încărcării serverului web, precum şi
o experiență plăcută pentru utilizator. Prin acest mecanism, codul de pe partea de server este

15. invocat ş
şi referit de către client precum un serviciu, îns
t să în acest c
context, term
menul de ser
rviciu
(service) nu are acela
aşi înțeles cu
u conceptul general de “
“serviciu web
b”.
Fi
igura anteri
ioară reprez
zintă o descriere vizua a ceea c înseamnă crearea unui
ală ce
serviciu c
cu mecanism
mul pus la dis
spoziție de G
GWT‐RPC.
Fiecare s
serviciu dețin
ne un set de
e interfețe şi clase ajutătoare. Unele
e dintre aceste clase, cu
um ar
fi serviciu
u proxy, est
te generat a
automat în s
spate fără ca
a programat
torul să ştie de existenț
ța sa.
Primul pa
as pentru crearea unui a
apel RPC est
te să definim
m un templat
te care să de
escrie apelul. Din
păcate ac
cest lucru tr
rebuie făcut de trei ori: o
o dată pe pa
artea de serv
ver, o data p
pe client şi o dată
în interfa
ața care este
e partajată d client. GWT foloseşte o convenție de nume pen
de server şi c ntru a
le conect
ta pe toate.
Problema care poat să apară este serializ
a te zarea obiect
telor care sunt trimise/
/recepționat În
te.
mod ide
entic cu RM şi .NET R
MI Remoting, G
GWT‐RPC nu este limita doar la primitive pe
u at entru

16. serializare. Orice tip de dată care este serializabil poate fi trimis/returnat ca parametrul în
apelul la distanță.
Trebuie să se țină seama că ideea de tip “GWT serializabil” diferă de ideea de tip “Java
serializabil”. Un tip este “GWT serializabil” dacă:
este primitivă, precum: char, byte, short, int, long, boolean, float sau double;
este primitivă de tip wrapper(Character, Byte, etc);
este String sau Date;
este un vector de tipuri serializabile (incluzând vectori de vectori);
este un tip declarat de utilizator, a cărui clasă are toate câmpurile serializabile;
implementează interfața IsSerializable.
Colecțiile precum Set, List, Map şi HashMap sunt problematice; trebuie să folosim o adnotare
specială în JavaDoc pentru a‐i spune compilatorului GWT ce tip de obiecte vor fi incluse în
colecție.
4.5 Managementul butonului “Back” al browser­ului / Browser History
Una dintre cele mai acute probleme ale aplicațiilor Ajax este acțiunea care se execută la
apăsarea butonului “Back” al browser‐ului. Aceasta presupune că dacă înlocuim dinamic o parte
a conținutului paginii web cu JavaScript, browser‐ul nu îşi poate da seama că s‐a schimbat ceva
în conținutul paginii.
Ceea ce se întâmplă cel mai adesea este că utilizatorul observă faptul că pagina s‐a schimbat, şi
îşi imaginează că dacă acționează butonul “Back” se va întoarce la vechiul conținut al paginii,
însă această presupunere este falsă. Pentru a putea ajuta utilizatorii, dezvoltatorii trebuie să
găsească o modalitate de a rezolva problema într‐un mod cât mai transparent pentru utilizator.
Soluția cea mai populară pentru această problemă tinde să fie destul de complicată de
implementat şi folosit. Ea presupune adăugarea unui frame ascuns şi a unui număr de scripturi
pentru a obține funcționarea corectă. Folosind GWT programatorul nu trebuie să facă el

17. această muncă, totul fiind rezolvat de framework, dezvoltatorul trebuie doar să creeze un
obiect history token căruia să îi asocieze un listener care implementează interfața
HistoryListen şi să‐l înregistreze ca un obiect de tip History.
Acest history token este un string în care se memorează orice stare a aplicației cum ar fi
numele tabului curent dintr‐o pagină care conține mai multe taburi. Google nu precizează
dimensiunea maximă a acestui token, însă este recomandat să nu se depăşească 100 de
caractere.
Tokenul curent este modificat atunci când utilizatorul face click pe un obiect Hyperlink sau când
acționeză butoanele Back sau Forward din browser, sau poate fi modificat în mod programatic
apelând History.newItem(), History.back() sau History.forward().
Cu ajutorul listener‐ului înregistrat, putem depista schimbările apărute în tokenul înregistrat.
Pentru utilizator, token‐ul va apărea afişat în bara de adrese a browser‐ului ca parte a URL‐ului,
sub forma: http://www.gwtpowered.org/#Xyzzy.
Intern, managementul paginilor accesate este înregistrat în fişierul html al aplicației printr‐un
tag special numit <iframe>. Când se crează acest token se crează un frame ascuns
programatorului care va fi încărcat cu o nouă pagină. Deoarece frame‐ul este încărcat cu o
nouă pagină, browser‐ul o va considera o pagină diferită şi o va adăuga la history. Astfel, prin
faptul că modificarea conținutului frame‐ului ascuns este semnalată de metoda
onHistoryChange() din HistoryListener, toate stările prin care trece aplicația sunt salvate,
fiind posibil astfel ca atunci când utilizatorul face click pe butonul “Back” al browser‐ului să fie
încărcată vechea pagină, producându‐se comportamentul aşteptat de utilizator. La fel se petrec
lucrurile şi pentru butonul “Forward”.
4.6 Integrarea JUnit cu GWT
Deoarece JUnit este instrumentul de testare cel mai popular, fiind integrat şi în cadrul
unor IDE‐uri, GWT oferă suport pentru folosirea acestuia pentru a permite testarea codului Ajax
cu aceiaşi uşurință cu care este facută testarea codului Java.

18. Pentru a crea un test, trebuie sa creem o clasă pe care să o extindem din GWTTestCase,
care extinde la rândul ei clasa TestCase, apoi să implementăm o anumită metodă,
getModuleName(), urmată de un număr de teste efective. Numele modulului este folosit de
GWT pentru a localiza fişierul de configurare.
public class MathTest extends GWTTestCase
{
public String getModuleName ()
{
return
"org.mycompany.MyApplication";
}
public void testAbsoluteValue ()
{
int absVal = Math.abs(-5);
assertEquals(5, absVal);
}
}
Înafară de testele obişnuite, GWT permite şi testarea apelurile RPC către server. În
această situație GWT va porni propria versiune de Tomcat, va executa codul GWT compilat, şi
va testa dacă codul apelat de client va primi rezultatul aşteptat de la server.
5. Modul Host vs Modul Web
Pe lângă suportul pentru JUnit sau compilatorul Java‐To‐JavaScript, Google Web Toolkit
oferă şi alte instrumente care să uşureze munca programatorilor web, şi anume un shell pentru
dezvoltarea şi testarea aplicațiilor, GWTShell , precum şi un browser web propriu numit Hosted
Mode Browser.

19. GWTShell est
G te o aplicație
e de tipul “Eclipse Rich C
Client application” sub f
formă de consolă
grafică c
care atunci când este la
ansată invocă resursele din proiec
e ctul GWT, afişează mes
sajele
informaționale şi lansează brows
ser‐ul care p
permite afişa
area paginii î
în modul host.
Hosted Mode Browser permite testarea codu Java în timpul dezv
H ului voltării aplic
cației,
într‐un m
mediu de dezvoltare hibrid asemă
ănător cu ce al browser‐ului, însă înainte de a fi
el ă e
transform
mat în cod JavaScript. A
Aceasta însea
amnă că JRE
E‐ul este cel care execut
tă componentele
Ajax ale aplicației, permițând d
p depanarea c
claselor dire din IDE‐le în care s lucreză. A
ect se Acest
browser caracterist
tic GWT‐ul
lui este o compone
o entă bazată pe SWT şi simulează
ă T
comportamentul bro
owserul implicit de pe fi emeni, este de un real a
iecare patformă. De ase ajutor
dezvoltarea aplicației şi obținerea de feedback prin inte
pentru d apelurilor de tip
erpretarea a
callback către codul Java al aplic
cației ce rule
ează pe platforma de de
ezvoltare. Următoarea f
figură
înfățişeaz shell‐ul GWT precum şi browse
ză G m er‐ul host în timpul rul
n lării aplicație “Kitchen Sink”
ei
oferită ca
a exemplu de GWT.

20. Browser‐ul host din figură are două conexiuni cu shell‐ul de dezvoltare din spate: una
dintre ele este o conexiune HTTP obişnuită pentru a încărca paginile web, fişierele .css, imagini,
servleturi folosite pentru apelul serviciilor de la server şi alte resurse. Toate aceste sunt
administrate de către serverul Apache Tomcat inclus în GWT folosind un servlet numit
com.google.gwt.dev.shell.GWTShellServlet. În cazul când pe server sunt integrate alte
componente, trebuie configurată corespunzător această variantă de Tomcat internă, sau
trebuie folosită o versiune externă.
Cea de‐a doua conexiune este un fel de “uşă din spate” care interceptează toate
interacțiunile care apar în browser‐ul host şi le redirecționează către codul java din shell (nu
către codul JavaScript). Acest cod Java apelează codul de la client care a fost compilat anterior
de către IDE. Detaliile cum se executa aceste acțiuni sunt ascunse in codul shell‐ului care nu
este open‐source.
Atunci când se acționează butonul Compile/Browse din browser‐ul host, compilatorul
GWT translatează codul din pachetul .client în cod JavaScript pe care îl deschide într‐un
browser web normal pentru a putea vizualiza aplicația. La acest punct paginile sunt încă
furnizate de instanța Tomcat‐ului inclus în shell, dar la fel de bine pot fi furnizate din fişiere
sistem sau un server web obişnuit. O altă modalitate de a invoca compilatorul GWT este prin
intermediul scriptului aflat la baza aplicației (MyApp-compile). De asemeni se poate scrie un
script care sa fie rulat cu Ant.
De fiecare dată cand este invocat, compilatorul GWT combină codul nostru cu o
versiune JavaScript a API‐ului GWT (echivalentul pentru gwt-user.jar) într‐un fişier JavaScript.
Acest cod împreună cu alte fişiere auxiliare sunt plasate în diectorul www al proiectului. De
asemeni, tot ce se găseşte în directorul public al proiectului va fi copiat.

21. Figura de
e mai sus pre
ezintă paşii p
pentru încăr
rcarea unei p
pagini în mo
odul host:
1. programul sh
hell deschide
e o fereastră care conțin
ne un browse
er de tip hos
st, în care încarcă
pagina MyAp
pp.html;
2. M
MyApp.html încarcă gwt.
.js printr‐un tag <script>
>;
3. gw
wt.js scanează MyApp
p.html pentru a extrag numele modului din tagul: <meta
ge
name=’gwtm
module’>;
4. G
GWT citeşte fişierul modul M
MyApp.gwt.x
xml pentru a găsi numele c
u clasei
EntryPoint(M
MyApp);
5. cl
lasa MyApp este instan
nțiată şi este apelată m
e metoda onMo
oduleLoad. De aici porn
neşte
aplicația;
6. co
odul aplicați
iei apelează librăria din G
GWT (gwt‐user.jar);
odul din gwt‐user.jar manipulează DOM‐ul bro
7. co owser‐ului pe
entru a adău
uga compon
nente
UI pe pagina web şi pentru a redirect
U ta toate evenimentele d
din browser c
către aplicaț
ție.

22. Urmă
ătoarea figur
ră prezintă f
fluxul execuț
țiilor pentru
u a încărca o
o pagină în m
modul web:
1. browser‐ul w
web încarcă M
MyApp.html;
2. M
MyApp.html încarcă gwt.
.js folosind t
tag‐ul <scrip>
>;
3. gw
wt.js parcu
urge MyAp
pp.html pe
entru a a
afla numele modulului din: <meta
e
name=’gwtm
module’>;
4. gw
wt.js modifică pagina pentru a include un <ifra
ame> care c
cauzează încărcarea fişie
erului
module‐name
m e.nochache.
.html;
5. co
odul JavaScript din fişie
erul module
e‐name.noca
ache.html d
determină tipul browser‐ului
apoi selectează fişierul co
orect pentru
u acel browser;
6. este executa codul JavaScript ehivalent m
at metodei on
nModuleLoad
d(), lansând
du‐se
aplicația. Manipularea D
DOM‐ului din browser e
n este făcută prin apeluri HTML dina
amice
din codul Java
aScript compilat.

23. 6. Utilitatea GWT
Premisa care a stat la baza GWT‐ului a fost simplă: dezvoltarea de aplicații Ajax într‐un
mod mult mai simplu, şi anume scutindu‐i pe programatori de incompabilitatea dintre browser‐
e şi permițând dezvoltatorului să lucreze într‐un mediu de dezvoltare Java familiar (fără a fi
nevoie de cunoştințe solide de JavaScript si DHTML).
După cum aminteam mai sus, GWT este primul framework pentru crearea de aplicații
web folosind limbajul Java care permite realizarea de aplicații asemănătoare cu cele pentru
desktop, dar care sunt rulate în browser.
Google Web Toolkit unifică codul pentru client şi server într‐o singură aplicație scrisă
într‐un singur limbaj: Java. Acest lucru are numeroase avantaje. Unul dintre acestea ar fi că mai
mulți dezvoltatori folosesc Java față de JavaScript sau Flash. Un alt motiv ar fi acela că pentru
Java există numeroase medii de dezvoltare: Eclipse, NetBeans, IntelliJ IDEA etc. GWT permite
crearea unei aplicații web într‐un mod asemănător cu crearea unei aplicații Swing – crearea de
componente vizuale, setarea event‐handler‐ilor, depanare etc – toate aceste în IDE‐ul preferat.
Prin folosirea aceluiaşi limbaj se poate folosi acelaşi cod atât pentru server cât şi pentru client.
De exemplu, se poate rula acelaşi cod de validare odată pe partea de client pentru feed‐back
imediat, precum şi pe partea de server pentru securitate maximă. De asemeni, se poate muta
cod între “straturile” aplicației în momentul când rearanjăm structura aplicației.
Nevoia de a scrie cod in Java, şi nu în JavaScript, este fundamentală pentru aplicațiile
Web complexe, deoarece se reduce dimensiunea aplicației, aceasta devenind mai uşor de
administrat. Însă, GWT permite integrarea codului JavaScript în aplicație, precum şi integrarea
unor servicii pentru partea de server.
GWT este construit deasupra tehnologiilor web, conferindu‐i astfel o mai mare putere.
Această putere provine din faptul că aplicațiile GWT pot rula pe orice tip de browser şi pe mai
multe sisteme de operare, precum şi din faptul că acest gen de aplicații pot fi rulate cu uşurință
pe mai multe calculatoare. Totuşi, dezvoltatorii de aplicații care folosesc acest toolkit, nu
trebuie să folosească direct tehnologiile web, GWT “ascunzând” aceste tehnologii din fața

24. programatorului prin folosirea unei abstracții de genul unui framework ce foloseşte limbajul
Java.
7. Comparaţie cu alte framework­uri
Google Web Toolkit nu este primul set de unelte care încearcă să uşureze modalitate de
construcție a aplicațiilor de tip RIA, şi după ritmul de evoluție al tehnologiilor web, este evident
că nu va fi nici ultimul. În cele ce urmează, se vor prezenta diferențele dintre GWT şi alte
framework‐uri din aceeaşi categorie, avându‐se în vedere că fiecare astfel de framework are
puncte tari şi slabe. (Diferența principală între GWT şi celelate framework‐uri existente este
aceea că folosind GWT, codul pentru partea de browser este scris in Java, nu in JavaScript.)
7.1 GWT vs SWING
Swing este toolkit‐ul standart pentru construcția aplicațiilor GUI în limbajul Java. La o
primă vedere s‐ar putea afirma că nu este o idee bună comparația dintre acestea două
deoarece Swing‐ul nu este asociat aplicațiilor web, însă analizând mai de aproape cele două
framework‐uri, se observă că se aseamănă datorită modalității similare, sau chiar identice, de
scriere a codului. Ceea ce diferă sunt cateva denumiri, cum ar fi numele interfeței ClickListener
din GWT, care are ca echivalentă în Swing, interfața ActionListener.
Pentru programatorii Swing, sunt câteva diferențe importante între GWT şi Swing.
Prima ar fi aceea că, componentele echivalente cu cele din GWT nu respectă şablonul de
proiectare MVC. Aceasta înseamnă că nu există un obiect model care să poate fi partiționat de
mai multe componente şi astfel, ele să fie ținute în sincronicitate.
A doua diferență notabilă este aceea că GWT nu foloseşte managerii de afişare (layout
managers) pentru organizarea componentelor în interfață. În schimb, GWT foloseşte panel‐uri,
care sunt construite într‐o manieră asemănătoare cu managerii de afişare.

25. Aceste diferențe minore fac din GWT un mediu de dezvoltare destul de familiar
dezvoltatorilor de aplicații Swing.
7.2 GWT vs. Echo2
Echo2 este un alt toolkit popular în rândul dezvoltatorilor de aplicații web ce folosesc
limbajul Java. Acesta se aseamănă cu GWT datorită modalității asemănătoare de a construi
interfața cu utilizatorul. Echo2 foloseşte clasele din API pentru crearea de instanțe a
componentelor, apoi le adaugă view‐ului.
Deşi cele două framework‐uri folosesc API‐uri similare, ele lucrează în maniere total
diferite.
Aplicațiile Echo2 rulează pe server, față de aplicațiile GWT care rulează pe client.
Cu GWT codul sursă Java este compilat şi transformat în JavaScript pentru a putea fi rulat în
browser, pe când cu Echo2 codul sursă Java este compilat în clase Java apoi este rulat pe server,
această obligând programatorul să trateze pe server eventualele evenimente apărute pe client.
Aceasta duce la consecința de a se face mai multe apeluri la server în Echo2, însă nu este nevoie
de a fi implementat un mecanism de tip RPC, deoarece totul se petrece pe server.
O alta consecintă a modului de funcționare a Echo2, este aceea că nu este nevoie să fie trimis
browser‐ului tot codul JavaScript rezultat în urma compilării, ci doar ceea ce este nevoie
pentru stadiul curent al aplicației.
7.3 GWT vs JSF
Java Server Faces (JSF) este un framework pentru crearea aplicațiilor web bazate pe
limbajul Java în cadrul căruia se folosesc bean‐uri pe server pentru reprezentarea modelului,
plus un set de librării de taguri folosite în paginile JSP pentru a referi proprietățile modelului.
În implementarea JSF standard, toate procesările sunt făcute de către server, iar paginile web

26. sunt reîncărcate după fiecare tranzacție, ceea ce nu face ca JSF să fie viabil pentru construirea
componentelor pentru aplicații RIA, însă cu puțin efort este posibil.
Primul pas pentru crearea unei aplicații folosind JSF este să creem clasa care reprezintă
modelul, apoi să înregistrăm în fişierul de configurare acea clasă ca fiind de tip managed‐bean.
Următorul pas este să construim pagina JSP care va reprezenta view‐ul aplicației.
JSF diferă foarte mult de GWT prin faptul că JSF oferă puține avantaje pentru crearea
suportului pentru funcționalitatea pe partea de client a unei aplicații RIA; este posibilă
construcția de componente reutilizabile pentru partea de client apelându‐se la JavaScript, însă
componentele custom au puține şanse de a fi reutilizate. Datorită faptului că JSF integrează şi
partea client, poate fi considerată o tehnologie în competiție cu GWT, însă există şanse ca cele
două să fie integrate.
7.4 GWT vs Ruby on Rails
Acest titlu poate să ducă în eroare deoarece GWT şi Ruby on Rails (RoR) nu se află în
competiție cu toate că la unele aspecte se pot suprapune.
Ruby on Rails este un framework care foloseşte limbajul Ruby pentru a implementa partea de
server a aplicației, fiind special creat pentru a executa automat o mare parte din munca din
spate. Pe partea de server, RoR oferă suport pentru Ajax, permițând să fie folosit în codul HTML
echivalentul Java pentru o librarie de taguri. Rezultatul final este acela că RoR poate trimite
informații către server când este declanşată o acțiune a utilizatorului, iar răspunsul este afişat în
pagină. RoR nu este creat pentru tratarea interacțiunilor complexe dintre server şi client.
Analizând puterea celor două limbaje, se poate afirma ca în locul unei competiții dintre
cele două, ar putea lua naştere o colaborare. La această concluzie se poate ajunge datorită
faptului ca GWT deține unele avantaje privitoare la mecanismele de transmitere a informațiilor
între server şi client. S‐a observat că din ce în ce mai mulți programatori care folosesc alte
tehnologii decât Java pe partea de server, sunt mulțumiți de rezultate pe care GWT le oferă
pe partea de client prin integrarea cu alte tehnologii pe partea de server.