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

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 

 

 

 

 

 

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 

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.  

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. 

   

  D

arhitectu

efectuate

într‐un m

Acest mo

duce  la o

conțin se

 

  3

  U

inițial,  ge

trebuie  s

server şi 

Un proie

Din  mai  mu

ură cu trei st

e de utilizat

mod persiste

odel împreu

o  îmbunătăț

ervere web. 

3.1  Structu

Un proiect G

enerat  atun

să  se  afle  co

față de resu

ct GWT arat

ulte  puncte 

traturi, unde

or şi cu com

nt de genul 

nă cu avanta

țire consider

ura unui p

GWT are o st

ci  când  con

odul  sursă  p

urse. 

tă în felul urm

de  vedere

e aplicația cl

municarea cu

RDBMS (Rel

ajul de a nu

rabilă a exp

proiect GW

tructură  sim

nstruim  un  p

pentru  part

mător: 

e,  GWT  rep

lient este res

u serverul ca

lational Data

 avea nevoie

erienței util

WT 

milară cu  stru

proiect GWT

ea  de  client

prezintă  o 

sponsabilă c

are oferă ac

abase Mana

e de altceva

lizatorului a

uctura unui 

T  nou,  difer

t  față  de  co

reîntoarcere

cu tratarea t

cesul asupra

gement Syst

a înafară de 

supra utiliză

pachet  Java

rențiază  în m

odul  sursă  p

e  la  tradițio

tuturor acțiu

a datelor sto

tem).  

browser ins

ării aplicațiil

a. Pachetul 

mod  vizibil 

pentru  parte

 

onala 

unilor 

ocate 

talat, 

or ce 

GWT 

unde 

ea  de 

com/example/app 

Pachetul  principal  al  proiectului.  Acesta  conține 

toate modulele  proiectului,  şi  nu  poate  conține 

fişiere cu cod. 

com/example/app/client Subpachetul  care  conține  toate  fişierele  cu  codul 

sursă pentru partea de client. 

com/example/app/server Subpachetul  care  conține  toate  fişierele  cu  codul 

sursă pentru server. 

com/example/app/public Subpachetul  care  conține  toate  resursele  statice 

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. 

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. 

   4

  R

într‐o  m

Compilar

com.go

fişierul d

Procesul 

a compil

deoarece

Acesta  l

compone

folosite d

Compilat

4.1 Compil

esponsabilit

maniera  ase

rea  pro

oogle.gwt

e definiție a

de compila

a codul  Java

e  acesta  nu

ucru  este  a

ente  şi  tool

de clasa entr

torul are tre

stilul  imp

amesteca

atorul Jav

tatea compil

mănătoare 

oiectului 

t.dev.GWT

l modulului.

re începe cu

a. Compilato

  compilează

avantajos  d

‐uri,  iar  com

ry‐point. 

i tipuri de st

plicit  este 

atură de liter

va­to­JavaS

latorului GW

cu  compila

se  f

TCompiler

 

u clasa entry

orul GWT  lu

ă  tot  ce  se 

eoarece  pe

mpilatorul  v

tiluri care de

cel  obfusca

re ceea ce îl 

Script 

WT este să co

atorul  care 

face  d

r  căruia  i  se

y‐point, urm

ucrează dife

gaseşte  în 

ermite  să  se

va  include  n

etermina cum

ate    şi  fac

face a fi imp

onvertească 

transformă

e  către

e  dă  ca  para

mând apoi de

rit  față de u

modul,  ci  n

e  poată  de

numai  acele

m va arăta c

e  ca  codul

posibil de de

codul Java î

ă  codul  Jav

e  prog

ametru  loca

ependințele 

un compilat

numai  ceea

ezvolta  o  lib

e  clase  şi m

codul Java Sc

  JavaScript 

escifrat. Scop

 

în cod JavaS

va  în  bytec

gramul 

ația  unde  se

necesare pe

or standard

a  ce  este  fo

brarie  ampl

metode  care 

cript rezultat

să  arate 

pul acestui s

cript, 

code. 

Java 

e  află 

entru 

  Java 

olosit. 

ă  de 

sunt 

t: 

ca  o 

til nu 

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 

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);

}-*/; 

 

  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.  

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.  

  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 

invocat ş

(service) 

  Fi

serviciu c

Fiecare s

fi serviciu

Primul pa

păcate ac

în interfa

le conect

Problema

mod  ide

şi referit de 

nu are acela

igura  anteri

cu mecanism

serviciu dețin

u proxy, est

as pentru cr

cest lucru tr

ața care este

ta pe toate. 

a  care  poat

entic  cu  RM

către client 

aşi înțeles cu

ioară  reprez

mul pus la dis

ne un set de

te generat a

earea unui a

rebuie făcut 

e partajată d

te  să  apară 

MI  şi  .NET  R

t precum un 

u conceptul 

zintă  o  des

spoziție de G

e interfețe ş

automat  în s

apel RPC est

de trei ori: o

de server şi c

este  serializ

Remoting,  G

serviciu, îns

general de “

criere  vizua

GWT‐RPC.  

i clase ajută

spate  fără ca

te să definim

o dată pe pa

client. GWT 

zarea  obiect

GWT‐RPC  nu

să în acest c

“serviciu web

ală  a  ceea  c

toare. Unele

a programat

m un templat

artea de serv

foloseşte o 

telor  care  s

u  este  limita

context, term

b”. 

ce  înseamn

e dintre ace

torul să ştie

te care să de

ver, o data p

convenție d

unt  trimise/

at  doar  la 

menul de ser

ă    crearea 

ste clase, cu

 de existenț

escrie apelu

pe client şi o

e nume pen

/recepționat

primitive  pe

rviciu 

unui 

um ar 

ța sa. 

l. Din 

 dată 

ntru a 

te.  În 

entru 

 

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 

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. 

  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.  

  G

grafică  c

informaț

  H

într‐un m

transform

Ajax  ale 

browser 

comport

pentru  d

callback 

înfățişeaz

oferită ca

GWTShell est

care  atunci 

ionale şi lan

Hosted Mod

mediu  de  d

mat în cod J

aplicației,  p

caracterist

amentul bro

dezvoltarea 

către codul 

ză shell‐ul G

a exemplu d

te o aplicație

când  este  la

sează brows

e Browser   

ezvoltare  h

avaScript. A

permițând  d

tic  GWT‐ul

owserul imp

aplicației  ş

Java al aplic

GWT   precum

e GWT. 

e de tipul “E

ansată  invo

ser‐ul care p

permite  te

ibrid  asemă

Aceasta însea

depanarea  c

lui  este  o

licit de pe fi

i  obținerea 

cației ce rule

m  şi browse

clipse Rich C

că  resursele

permite afişa

starea  codu

ănător  cu  ce

amnă că JRE

claselor  dire

o  compone

iecare patfo

de  feedba

ează pe plat

er‐ul   host  în

Client applic

e  din  proiec

area paginii î

ului  Java  în 

el  al  brows

E‐ul este cel 

ect  din  IDE‐

entă  bazată

rmă. De ase

ck  prin  inte

forma de de

n  timpul  rul

ation”  sub f

ctul  GWT,  a

în modul ho

timpul  dezv

er‐ului,  însă

care execut

le  în  care  s

ă  pe  SWT

emeni, este 

erpretarea  a

ezvoltare. U

lării aplicație

formă de co

fişează mes

st. 

voltării  aplic

ă  înainte  de

tă compone

se  lucreză.  A

T  şi  simu

de un real a

apelurilor  d

rmătoarea f

ei “Kitchen 

 

nsolă 

sajele 

cației, 

e  a  fi 

ntele 

Acest 

lează 

ajutor 

e  tip 

figură 

Sink” 

  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. 

Figura de

1. p

p

2. M

3. gw

n

4. G

E

5. cl

a

6. co

7. co

U

e mai sus pre

rogramul sh

agina  MyAp

MyApp.html 

wt.js  scane

ame=’gwtm

GWT  citeşt

ntryPoint(M

lasa MyApp

plicația; 

odul aplicați

odul din gw

UI pe pagina 

ezintă paşii p

hell deschide

pp.html; 

încarcă gwt.

ază  MyApp

module’>; 

e  fişierul 

MyApp); 

 este  instan

iei apelează 

t‐user.jar m

web şi pent

pentru încăr

e o fereastră

.js printr‐un 

p.html  pent

modul  M

nțiată  şi este

librăria din G

anipulează 

ru a redirect

rcarea unei p

 care conțin

tag <script>

ru  a  extrag

MyApp.gwt.x

e apelată m

GWT (gwt‐u

DOM‐ul bro

ta toate eve

pagini în mo

ne un browse

>; 

ge  numele 

xml  pentru

metoda onMo

ser.jar); 

owser‐ului pe

nimentele d

odul host: 

er de tip hos

modului  d

u  a  găsi 

oduleLoad. 

entru a adău

din browser c

st, în care în

in  tagul:  <

numele  c

De aici porn

uga compon

către aplicaț

carcă 

meta 

clasei 

neşte 

nente 

ție. 

Urmă

1. b

2. M

3. gw

n

4. gw

m

5. co

a

6. e

a

d

 

 

 

ătoarea figur

rowser‐ul w

MyApp.html 

wt.js  parcu

ame=’gwtm

wt.js modifi

module‐name

odul  JavaSc

poi selectea

ste  executa

plicația. Ma

in codul Java

ră prezintă f

web încarcă M

încarcă gwt.

urge  MyAp

module’>; 

că pagina p

e.nochache.

ript  din  fişie

ză fişierul co

at  codul   

nipularea D

aScript com

fluxul execuț

MyApp.html

.js folosind t

pp.html  pe

entru a  incl

.html; 

erul module

orect pentru

JavaScript 

DOM‐ului din

pilat. 

țiilor pentru

; 

tag‐ul <scrip>

entru  a  a

ude un <ifra

e‐name.noca

u acel brows

ehivalent  m

n browser  e

u a încărca o

>; 

afla  numele

ame> care c

ache.html  d

er; 

metodei  on

este  făcută 

o pagină în m

e  modulul

cauzează  înc

determină  ti

nModuleLoad

prin  apeluri

modul  web:

ui  din:  <

ărcarea fişie

pul  browse

d(),  lansând

 HTML dina

 

meta 

erului 

r‐ului 

du‐se 

amice  

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 

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.  

  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 

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.