Post on 29-Nov-2014
description
transcript
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
vatoJavaS
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 Widgeturi ş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 browserului / 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 frameworkuri 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.