Google Web Toolkit - technical report

1,993 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,993
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Google Web Toolkit - technical report

  1. 1.       Google Web Toolkit  Tutorial      Anişoara Sava, OC2  Marcela Daniela Mihai, OC2      10/19/2009   
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 

×