![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.](https://image.slidesharecdn.com/googlewebtoolkit-091026161825-phpapp02/85/Google-Web-Toolkit-technical-report-12-320.jpg)
Google Web Toolkit - technical report
- 2. Table of Contents 1. Prezentare generală ................................................................................................................ 3 2. Principii de bază GWT .............................................................................................................. 3 3. Arhitectura GWT ...................................................................................................................... 4 3.1 Structura unui proiect GWT ................................................................................................. 6 3.2 Interoperabilitatea cu Standardele Web şi Serviciile Web ................................................... 8 4. Instrumente GWT .................................................................................................................... 8 4.1 Compilatorul Java‐to‐JavaScript ........................................................................................... 9 4.2 JSNI (JavaScript Native Interface) ....................................................................................... 11 4.3 Widget‐uri şi Panel Library ................................................................................................ 12 4.4 Protocolul Remote Procedure Call (RPC) ............................................................................ 13 4.5 Managementul butonului “Back” al browser‐ului / Browser History ................................ 16 4.6 Integrarea JUnit cu GWT .................................................................................................... 17 5. Modul Host vs Modul Web .................................................................................................... 18 6. Utilitatea GWT ....................................................................................................................... 23 7. Comparație cu alte framework‐uri ........................................................................................ 24 7.1 GWT vs SWING .................................................................................................................... 24 7.2 GWT vs. Echo2 .................................................................................................................... 25 7.3 GWT vs JSF .......................................................................................................................... 25 7.4 GWT vs Ruby on Rails .......................................................................................................... 26
- 3. 1. Prezentare generală Platforma Web 2.0 împreună cu tehnologia Ajax din cadrul acesteia, a câştigat tot mai multă atenție datorită faptului că pentru aplicațiile web, cel mai important beneficiu adus de Ajax îl constituie îmbunătățirea experienței utilizatorilor. Deşi JavaScript şi DHTML ‐ limbaje aflate la baza tehnologiei Ajax ‐ sunt disponibile de câțiva ani, cei mai mulți programatori încearcă să le evite datorită dificultății de folosire a acestora. Astăzi, framework‐uri scrise în JavaScript precum Dojo, pot fi folosite pentru realizarea aplicațiilor Ajax, însă, acest fapt necesită cunoştințe solide de JavaScript. Ca soluție la acestă problemă, Google vine în sprijinul programatorilor Java, cu un nou framework pentru crearea de aplicații Ajax mult mai productive: Google Web Toolkit (GWT). 2. Principii de bază GWT Pe parcursul ultimilor ani, s‐au dezvoltat numeroase framework‐uri Java pentru realizarea aplicațiilor web. Din prima generație de astfel de framework‐uri face parte venerabilul Apache Struts, iar a doua generație cuprinde framework‐uri precum Tapestry şi JavaServerFaces. Google Web Toolkit dă startul celei de‐a treia generații de framework‐uri, oferind, la fel ca cea de‐a doua generație, suport pentru folosirea componentelor (componentele pot fi folosite de dezvoltatori pentru crearea de noi componente care pot fi adăugate în aplicație pentru îmbunătățirea funcționalității paginlor web), numite în GWT widgets, însă se diferențiază de predecesorii săi prin faptul că nu este o tehnologie care foloseşte clasicele form‐uri. GWT este primul framework pentru crearea de aplicații web folosind limbajul Java care permite realizarea de aplicații asemănătoare cu cele pentru desktop, dar care sunt rulate în browser. Cu această inovație, dezvoltatorii pot renunța la construcția de aplicații web compuse din “arhaicele” pagini, trecând la aplicații care rulează într‐o singură fereastră a browserului, similar cu aplicațiile pentru desktop construite cu AWT, Swing sau SWT. Astfel, GWT nu e o evoluție, ci o
- 4. revoluție deoarece desființează în totalitate fundamentele modalității de construire a aplicațiilor web. Google Web Toolkit(GWT) este un set de unelte de dezvoltare, utilități de programare şi widget‐uri care permit crearea cu uşurință a aplicațiilor AJAX. Această tehnologie este disponibilă open‐souce sub licență Apache 2.0 pentru platformele: Windows, Mac OS X şi Linux. Cea mai importantă parte a GWT‐ului poate fi considerat compilatorul responsabil cu transformarea codului Java în cod JavaScript pentru a putea fi rulat in browser. Această inovație adusă de GWT este foarte importantă, însă nu este singurul lucru care face ca această nouă tehnologie să fie deosebită. GWT vine şi cu: un echipament de testare folosit pentru depanarea bytecodului Java în mod direct atunci când este rulat în mediul oferit de GWT ce simulează browserul, un set de widget‐ uri principale pentru construirea interfeței cu utilizatorul, precum şi un sistem Remote Procedure Call pentru realizarea comunicației cu serverul web. Pe scurt, GWT reuneşte avantajele oferite de librăriile JavaScript, abilitățile de comunicare ale DWR –ului, precum şi avantajele uneltelor Java din Echo2 sau XML11, într‐un singur pachet. 3. Arhitectura GWT GWT continuă să folosească HTML şi CSS deoarece sunt relativ simple, încă eficiente şi suportate în mod nativ de browsere. O aplicație GWT bine realizată se va baza pe patternul MVC, însă se va întoarce şi la modelul de programare client‐server. Cu GWT se va folosi MVC pe partea de client. MVC este un şablon architectural proiectat pentru separarea responsabilităților în cadrul aplicațiilor software. Pentru aplicațiile web, MVC presupune o defalcare în trei straturi: modelul reprezentat de informațiile de pe partea de server, view‐ul oferit de către HTML şi controller‐ul reprezentat de o pagină sau un servlet de pe server, acestea având propriile responsabilități. În mediul GWT (similar cu alte aplicații bazate pe AJAX), toate aceste responsabilități ale aplicației sunt mutate de pe server pe client.
- 5. View‐ul generat de server prin tehnologii de genul JSP, este înlocuit cu componente pentru UI inteligente care leagă informațiile din cadrul lor de modelul aplicației. Modelul este sincronizat cu serverul prin intermediul unor tehnici tradiționale care permit comunicarea dintre server şi client. Această modalitate de a folosi MVC pe client oferă posibilitatea clientului de a coordona cele mai multe tranziții de stare din UI precum şi relaționarea logică a interfeței, fără a mai apela la serviciile serverului. Acest lucru presupune îmbunătățirea performanței şi a scalabilității chiar dacă lățimea de bandă sau latența rețelei prezintă probleme. Această îmbunătățire derivă din faptul că clientul poate să dirijeze mai multe responsabilități, fără a fi nevoit să comunice cu serverul pentru a modifica view‐ul pentru acelaşi set de date. Mai mult, se pot obține infomații ale aplicației sau sincronizări cu serverul printr‐o metodă elegantă, asincronă, care oferă la rândul ei avantaje. O caracteristică a GWT‐ului este că trebuie să fie prezentă şi pe server o reprezentare a modelului, iar modelul de pe client trebuie să comunice cu serverul pentru a obține sau sincroniza informațiile; acesta comunicare este realizată prin intermediul mecanismului RPC şi a facilităților oferite de serializarea obiectelor. Pentru a face posibilă comunicarea dintre server şi client, GWT foloseşte implementarea serviciul SOA (Service Oriented Arhitecture), permițând astfel controller‐ului de pe client să invoce seviciile puse la dispoziție de către server şi să actualizeze modelul de pe client când este nevoie. Reprezentările modelului de pe client şi server pot folosi aceleaşi obiecte, sau copii exacte ale acestora, GWT putând serializa şi deserializa automat datele din JavaScript în Java şi viceversa. Următoarea figură este o diagramă simplificată care descrie modalitatea de sincronizare între serverul şi clientul GWT, facilitată de mecanismul RPC oferit de GWT şi capabilitățile oferite de serializarea/deserializarea obiectelor.
- 6. Din D mai mu ulte puncte de vedere GWT rep e, prezintă o reîntoarcere la tradițio e onala arhitectu ură cu trei st traturi, unde e aplicația cl lient este res sponsabilă c cu tratarea t tuturor acțiu unilor efectuate e de utilizator şi cu com municarea cu u serverul ca are oferă accesul asupra a datelor sto ocate într‐un m mod persistent de genul RDBMS (Rel lational Data abase Management Syst tem). Acest mo odel împreună cu avanta ajul de a nu avea nevoie e de altceva a înafară de browser instalat, duce la o îmbunătăț consider o țire rabilă a experienței util lizatorului asupra utiliză aplicațiilor ce ării conțin se ervere web. 3.1 Structu 3 ura unui p proiect GW WT Un U proiect GWT are o st G tructură sim milară cu stru uctura unui pachet Java Pachetul GWT a. inițial, ge enerat atunci când con nstruim un p proiect GWT nou, difer T rențiază în m vizibil unde mod trebuie s se afle co să odul sursă p pentru partea de client față de co t odul sursă p pentru parte de ea server şi față de resu urse. Un proiect GWT arat tă în felul urm mător:
- 7. Pachetul principal al proiectului. Acesta conține com/example/app toate modulele proiectului, şi nu poate conține fişiere cu cod. Subpachetul care conține toate fişierele cu codul com/example/app/client sursă pentru partea de client. Subpachetul care conține toate fişierele cu codul com/example/app/server sursă pentru server. Subpachetul care conține toate resursele statice com/example/app/public de care este nevoie în aplicație. Fiecare proiect GWT poate fi alcătuit din unul sau mai multe module. Citând definiția dată de Google, un “modul GWT este pur şi simplu o încapsulare a funcționalității”. Modulul reuneşte toate configurările necesare pentru a utiliza codul pe care îl scriem într‐un proiect GWT. Modulele sunt definite în aplicație în cadrul fişierelor descriptor XML a căror denumire se termină cu extensia .gwt.xml. Conceptul descriptorului de modul din GWT este similar descriptorilor din Tomcat sau alte servere de aplicații. Conținutul unui fişier descriptor XML este folosit pentru a specifica: Modulele moştenite, cele din care aplicația moşteneşte setări şi cod. Numele unei clase ce reprezintă punctul de intrare în aplicație (opțional); o clasă de tip entry point este o clasă ce implementeză interfața EntryPoint. Când un modul este încărcat, fiecare clasă entry point definită în fişierul .gwt.xml este instanțiată şi apelată metoda onModuleLoad() din cadrul acesteia. Este posibil să creăm un modul cu mai mult de o clasă entry point, şi de asemenea este posibil să creăm un modul cu nicio clasă de tip entry point, acest tip de modul fiind folosit ca o librărie GWT de cod reutilizabil. Intrările Source Path, folosite pentru a specifica care subpachet conține codul sursă care urmează a fi transformat în JavaScript. Subpachetul care conține codul pentru client este inclus automat în source path.
- 8. Intrările Public Path, folosite pentru a specifica care subpachete sunt publice (vizibile în toată aplicația). Toate fişierele aflate in Public Path vor fi copiate în directorul de ieşire a modulului în momentul când aplicația este compilată. 3.2 Interoperabilitatea cu Standardele Web şi Serviciile Web GWT nu încearcă să fie doar un framework cu care se pot construi aplicații; el se vrea a fi un set de unelte care îmbunătățeşte vizibil posibilitatea de a crea aplicații Ajax. Pentru a îndeplini acesta este necesar să fie îmbinate standardele web actuale şi serviciile web. Astfel, GWT nu îndrumă spre o singură tehnologie, ci permite folosirea oricărei tehnologii. În particular, GWT furnizează librăriile JSON şi XML care permit translatarea datelor în alte tipuri de obiecte. De asemeni GWT oferă o modalitate de a conecta componentele care alcătuiesc interfața cu fişierul CSS pentru a putea profita de beneficiile aduse de această tehnologie. Pentru a obține efecte mai spectaculoase acest toolkit permite integrarea cu alte librării JavaScript existente prin intermediul JavaScript Native Interface (JSNI), o modalitate de a utiliza cod JavaScript în cadrul codului Java. 4. Instrumente GWT GWT oferă un set amplu de unelte necesare pentru rezolvarea problemei mutării aplicațiilor tip desktop în browser. Toolbox‐ul GWT conține un parser XML, mai multe instrumente pentru comunicarea cu serverul, unelte pentru configurare şi internaționalizare precum şi un sistem de management al istoriei paginilor vizualizate în browser. Următoarea figură constituie o hartă vizuală a aspectelor centrale ale GWT‐ului, acestea fiind împărțite în două categorii: cele legate de compilator şi librăriile Java care alcătuiesc API‐uri GWT.
- 9. 4.1 Compilatorul Jav 4 vatoJavaS Script Responsabilit tatea compil latorului GW WT este să co onvertească codul Java î în cod JavaScript, într‐o m atorul care transformă codul Jav în bytec maniera asemănătoare cu compila ă va code. Compilar rea pro oiectului se face f de către e prog gramul Java com.go oogle.gwt TCompiler căruia i se dă ca para t.dev.GWT r e ametru loca unde se află ația e fişierul de definiție al modulului. Procesul de compilare începe cu u clasa entry y‐point, urm mând apoi de ependințele necesare pe entru a compila codul Java Compilato GWT lu a. orul ucrează diferit față de u compilator standard Java un deoarece acesta nu compilează tot ce se gaseşte în modul, ci n e ă numai ceea ce este fo a olosit. Acesta lucru este avantajos deoarece pe a ermite să se poată de e brarie amplă de ezvolta o lib ente şi tool‐uri, iar com compone mpilatorul v include n va numai acele clase şi m e metode care sunt folosite d de clasa entr ry‐point. Compilat torul are trei tipuri de st tiluri care de etermina cum m va arăta c codul Java Sc cript rezultat t: plicit este cel obfusca şi face ca codul JavaScript să arate ca o stilul imp ate amesteca re ceea ce îl face a fi imp atură de liter posibil de de pul acestui stil nu escifrat. Scop
- 10. este de a face imposibil de citit codul ci pentru a menține fişierul JavaScript cât mai mic posibil. Un exemplu de cod care are acest stil arată în felul următor: function b(){return this.c + '@' + this.d();} stilul pretty, generează cod JavaScript care poate fi citit cu uşurința. Pentru exemplificare vom folosi acelaşi cod ca la stilul anterior. De acesta dată ne putem da seama că este metoda toString(), însă încă nu putem şti din care clasă este această metoda: function _toString(){ return this._typeName + '@' + this._hashCode(); } stilul detailed, care seamănă cu stilul pretty, cu completarea că, vom avea numele complet al clasei din care face parte metoda, ca parte a numelui metodei JavaScript function java_lang_Object_toString__(){ return this.java_lang_Object_typeName + '@' +this.hashCode__(); } Stilurile pretty şi detailed sunt folosite îndeosebi în procesul de dezvoltare pentru a putea detecta cu uşurința eventualele erori JavaScript apărute în browser. Un alt aspect important al compilatorului GWT este că acesta foloseşte codul sursă Java, nu codul Java binar. Acesta presupune că, codul sursă pentru toate clasele Java să fie disponibile. Acest lucru este important şi atunci când vrem să distribuim cod GWT pentru a fi
- 11. refolosit. Când se construiesc fişiere .jar, care urmează a fi distribuite, trebuie să fie incluse atât clasele Java cât şi fişierele cu cod sursă. O ultimă caracteristică notabilă este aceea că după compilarea codului Java în JavaScript, rezultă un singur fişier JavaScript pentru fiecare tip de browser. Browser‐ele pentru care se generează fişiere JavaScript sunt: Internet Explorer, Firefox, Mozillla, Opera şi Safari. Când este rulat scriptul de pornire pentru browser (bootstrap), acesta încarcă fişierul corespunzător pentru browserul respectiv. Avantajul este că nu se va mai încarca cod pe care browserul nu va putea să îl folosească. 4.2 JSNI (JavaScript Native Interface) Cu toate că codul GWT trebuie scris in Java, uneori pot apărea situații cand trebuie să facem apeluri directe la cod JavaScript. O astfel de situație este atunci când trebuie să facem apel la API‐ul browser‐ului pentru care nu există echivalent în GWT. O altă situație poate apărea atunci când vrem să utilizăm în aplicația noastră anumite librării JavaScript mai deosebite. Accesând JavaScript direct, aplicația este expusă incompatibilităților dintre browsere. Va fi nevoie de teste extra pentru a avea siguranța că, codul JSNI va funcționa pe mai multe browsere. JSNI permite execuția codului JavaScript din codul Java, precum şi viceversa. Acest lucru este făcut posibil de către compilatorul GWT care poate îmbina cod nativ JavaScript cu cod JavaScript generat dupa compilarea codului Java. Pentru a scrie o metodă pură JavaScript prin intermediul JSNI trebuie doar să declarăm acea metodă ca native şi să furnizăm implementarea în JavaScript între comentarii: public native void fillData (String msg) /*-{ $wnd.alert(msg); }-*/;
- 12. De asemenea, GWT oferă şi o modalitate pentru a apela cod Java în cadrul codului JavaScript. Signatura unei astfel de metode este următoarea: [instance-expr.]@class- name::method-name(param-signature)(arguments), unde [instance-expr.] specifică faptul că este vorba de o metodă ne‐statică. 4.3 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.
- 13. Alte exemple de acest fel de componente sunt: MenuBar, care oferă o cale usoară de a crea un meniu cu mai multe nivele, PopupPanel, StackPanel etc. Trebuie să observăm, însă, că widget‐urile din GWT nu intenționează să semene perfect cu cele dintr‐o aplicație pentru desktop; astfel, ele se integrează bine cu browserul şi oferă o experiență familială utilizatorului. De asemenea, aplicația creată cu GWT poate fi integrată cu oricare parte a unei pagini HTML, însă permițându‐i să arate ca o pagină web obişnuită. Există peste 30 de widget‐uri şi panel‐uri conținute în pachetul com.google.gwt.user.client.ui din GWT, însă e puțin probabil ca acestea să satisfacă toate nevoile dezvoltatorilor. Lista widget‐urilor din GWT cuprinde calendare, tabele sortabile, calculatoare, panel‐uri pentru desenare, panel‐uri cu rol de tooltip etc. Există, de asemeni, widget‐uri care includ librării JavaScript, cum sunt Google Maps API, Google Search API, sau efecte obținute cu Scriptaculous. Înafara widget‐urilor de bază pentru HTML, există şi widget‐ uri disponibile pentru Scalar Vector Graphics (SVG). Există şi posibilitatea să ne creem propriile noastre widget‐uri extinzându‐le pe cele din GWT, însă este recomandat ca atunci când recurgem la această posibilitate să accesăm obiecte JavaScript care se află la baza browser‐elor. 4.4 Protocolul Remote Procedure Call (RPC) Din punctul de vedere al locului unde este rulat codul, aplicațiile Ajax în general şi cele GWT în particular se încadrează în categoria Rich Internet Applications(RIA). Acest tip de aplicații sunt o combinație între Fat client applications, unde codul rulează doar pe maşina utilizatorului (ex. Microsoft Word), şi Thin client applications unde codul rulează pe o maşină server, iar desktopul clientului este folosit doar pentru afişarea interfeței prin intermediul unui browser (aici se încadrează majoritatea aplicațiilor web: Ebay, Amazon etc). Faptul că se încadrează în ambele categorii oferă GWT‐ului complexitate şi interactivitate, deoarece poate profita de anumite puteri de procesare pe partea de client.
- 14. De fiecare dată când avem cod care rulează în doua părți diferite, avem nevoie de un mecanism pentru a comunica între cele două. Cea mai simplă modalitate în această situație o reprezintă apelul procedurilor la distanță (Remote Procedure Call), care presupune o cale prin care clientul să execute codul pe server şi să primească rezultatul execuției; în acestă situație poate fi folosit oricare dintre următoarele protocoalele RPC: RMI, .NET Remoting, SOAP, REST sau XML‐RPC. Însă GWT nu foloseşte nici unul dintre acestea, având implementat propriul protocol de tip RPC, aceasta pentru a putea realiza apelurile asincrone de la browser. În GWT librăria RPC este divizată în două pachete: pachetul com.google.gwt.user.client.rpc folosit pe partea de client şi pachetul com.google.gwt.user.server.rpc folosit pe partea de server. Partea pentru client oferă interfețele necesare pentru interconectarea interfețelor aplicației care vor fi folosite pentru implementarea RPC‐ului. Când este transformat codul de pe client în cod JavaScript de către compilatorul GWT, codul folosit pentru RPC este generat pe baza interfețelor interconectate. Pachetul pentru partea de server folosit pentru implementarea RPC‐ului este construit astfel încât să fie folosit într‐un container de servleturi Java cum este Tomcat sau Jetty. Din fericire, browser‐ul host oferit de GWT conține un server Tomcat integrat, şi astfel pot fi testate şi depanate apelurile RPC de pe server în orice IDE care oferă suport pentru GWT. S‐a mers pe ideea ca protocolul trebuie să fie simplu. Browser‐ul descarcă tot codul de la client când acesta porneşte aplicația , iar dacă codul depăşeşte 100K atunci se va observa o pauză. De astfel, codul JavaScript care rulează în browser este destul de lent, aşa încât implementarea unui protocol complex precum SOAP ar presupune descărcarea unei cantități mari de cod care ar incetini considerabil execuția. Astfel, când mecanismul oferit de RPC este folosit în mod corespunzător, oferă avantajul de a muta tot codul pentru logica UI pe client, obținând astfel vizibile creşteri de performanță, reducerea încărcării serverului web, precum şi o experiență plăcută pentru utilizator. Prin acest mecanism, codul de pe partea de server este
- 15. invocat ş şi referit de către client precum un serviciu, îns t să în acest c context, term menul de ser rviciu (service) nu are acela aşi înțeles cu u conceptul general de “ “serviciu web b”. Fi igura anteri ioară reprez zintă o descriere vizua a ceea c înseamnă crearea unui ală ce serviciu c cu mecanism mul pus la dis spoziție de G GWT‐RPC. Fiecare s serviciu dețin ne un set de e interfețe şi clase ajutătoare. Unele e dintre aceste clase, cu um ar fi serviciu u proxy, est te generat a automat în s spate fără ca a programat torul să ştie de existenț ța sa. Primul pa as pentru crearea unui a apel RPC est te să definim m un templat te care să de escrie apelul. Din păcate ac cest lucru tr rebuie făcut de trei ori: o o dată pe pa artea de serv ver, o data p pe client şi o dată în interfa ața care este e partajată d client. GWT foloseşte o convenție de nume pen de server şi c ntru a le conect ta pe toate. Problema care poat să apară este serializ a te zarea obiect telor care sunt trimise/ /recepționat În te. mod ide entic cu RM şi .NET R MI Remoting, G GWT‐RPC nu este limita doar la primitive pe u at entru
- 16. serializare. Orice tip de dată care este serializabil poate fi trimis/returnat ca parametrul în apelul la distanță. Trebuie să se țină seama că ideea de tip “GWT serializabil” diferă de ideea de tip “Java serializabil”. Un tip este “GWT serializabil” dacă: este primitivă, precum: char, byte, short, int, long, boolean, float sau double; este primitivă de tip wrapper(Character, Byte, etc); este String sau Date; este un vector de tipuri serializabile (incluzând vectori de vectori); este un tip declarat de utilizator, a cărui clasă are toate câmpurile serializabile; implementează interfața IsSerializable. Colecțiile precum Set, List, Map şi HashMap sunt problematice; trebuie să folosim o adnotare specială în JavaDoc pentru a‐i spune compilatorului GWT ce tip de obiecte vor fi incluse în colecție. 4.5 Managementul butonului “Back” al 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
- 17. această muncă, totul fiind rezolvat de framework, dezvoltatorul trebuie doar să creeze un obiect history token căruia să îi asocieze un listener care implementează interfața HistoryListen şi să‐l înregistreze ca un obiect de tip History. Acest history token este un string în care se memorează orice stare a aplicației cum ar fi numele tabului curent dintr‐o pagină care conține mai multe taburi. Google nu precizează dimensiunea maximă a acestui token, însă este recomandat să nu se depăşească 100 de caractere. Tokenul curent este modificat atunci când utilizatorul face click pe un obiect Hyperlink sau când acționeză butoanele Back sau Forward din browser, sau poate fi modificat în mod programatic apelând History.newItem(), History.back() sau History.forward(). Cu ajutorul listener‐ului înregistrat, putem depista schimbările apărute în tokenul înregistrat. Pentru utilizator, token‐ul va apărea afişat în bara de adrese a browser‐ului ca parte a URL‐ului, sub forma: http://www.gwtpowered.org/#Xyzzy. Intern, managementul paginilor accesate este înregistrat în fişierul html al aplicației printr‐un tag special numit <iframe>. Când se crează acest token se crează un frame ascuns programatorului care va fi încărcat cu o nouă pagină. Deoarece frame‐ul este încărcat cu o nouă pagină, browser‐ul o va considera o pagină diferită şi o va adăuga la history. Astfel, prin faptul că modificarea conținutului frame‐ului ascuns este semnalată de metoda onHistoryChange() din HistoryListener, toate stările prin care trece aplicația sunt salvate, fiind posibil astfel ca atunci când utilizatorul face click pe butonul “Back” al browser‐ului să fie încărcată vechea pagină, producându‐se comportamentul aşteptat de utilizator. La fel se petrec lucrurile şi pentru butonul “Forward”. 4.6 Integrarea JUnit cu GWT Deoarece JUnit este instrumentul de testare cel mai popular, fiind integrat şi în cadrul unor IDE‐uri, GWT oferă suport pentru folosirea acestuia pentru a permite testarea codului Ajax cu aceiaşi uşurință cu care este facută testarea codului Java.
- 18. Pentru a crea un test, trebuie sa creem o clasă pe care să o extindem din GWTTestCase, care extinde la rândul ei clasa TestCase, apoi să implementăm o anumită metodă, getModuleName(), urmată de un număr de teste efective. Numele modulului este folosit de GWT pentru a localiza fişierul de configurare. public class MathTest extends GWTTestCase { public String getModuleName () { return "org.mycompany.MyApplication"; } public void testAbsoluteValue () { int absVal = Math.abs(-5); assertEquals(5, absVal); } } Înafară de testele obişnuite, GWT permite şi testarea apelurile RPC către server. În această situație GWT va porni propria versiune de Tomcat, va executa codul GWT compilat, şi va testa dacă codul apelat de client va primi rezultatul aşteptat de la server. 5. Modul Host vs Modul Web Pe lângă suportul pentru JUnit sau compilatorul Java‐To‐JavaScript, Google Web Toolkit oferă şi alte instrumente care să uşureze munca programatorilor web, şi anume un shell pentru dezvoltarea şi testarea aplicațiilor, GWTShell , precum şi un browser web propriu numit Hosted Mode Browser.
- 19. GWTShell est G te o aplicație e de tipul “Eclipse Rich C Client application” sub f formă de consolă grafică c care atunci când este la ansată invocă resursele din proiec e ctul GWT, afişează mes sajele informaționale şi lansează brows ser‐ul care p permite afişa area paginii î în modul host. Hosted Mode Browser permite testarea codu Java în timpul dezv H ului voltării aplic cației, într‐un m mediu de dezvoltare hibrid asemă ănător cu ce al browser‐ului, însă înainte de a fi el ă e transform mat în cod JavaScript. A Aceasta însea amnă că JRE E‐ul este cel care execut tă componentele Ajax ale aplicației, permițând d p depanarea c claselor dire din IDE‐le în care s lucreză. A ect se Acest browser caracterist tic GWT‐ul lui este o compone o entă bazată pe SWT şi simulează ă T comportamentul bro owserul implicit de pe fi emeni, este de un real a iecare patformă. De ase ajutor dezvoltarea aplicației şi obținerea de feedback prin inte pentru d apelurilor de tip erpretarea a callback către codul Java al aplic cației ce rule ează pe platforma de de ezvoltare. Următoarea f figură înfățişeaz shell‐ul GWT precum şi browse ză G m er‐ul host în timpul rul n lării aplicație “Kitchen Sink” ei oferită ca a exemplu de GWT.
- 20. Browser‐ul host din figură are două conexiuni cu shell‐ul de dezvoltare din spate: una dintre ele este o conexiune HTTP obişnuită pentru a încărca paginile web, fişierele .css, imagini, servleturi folosite pentru apelul serviciilor de la server şi alte resurse. Toate aceste sunt administrate de către serverul Apache Tomcat inclus în GWT folosind un servlet numit com.google.gwt.dev.shell.GWTShellServlet. În cazul când pe server sunt integrate alte componente, trebuie configurată corespunzător această variantă de Tomcat internă, sau trebuie folosită o versiune externă. Cea de‐a doua conexiune este un fel de “uşă din spate” care interceptează toate interacțiunile care apar în browser‐ul host şi le redirecționează către codul java din shell (nu către codul JavaScript). Acest cod Java apelează codul de la client care a fost compilat anterior de către IDE. Detaliile cum se executa aceste acțiuni sunt ascunse in codul shell‐ului care nu este open‐source. Atunci când se acționează butonul Compile/Browse din browser‐ul host, compilatorul GWT translatează codul din pachetul .client în cod JavaScript pe care îl deschide într‐un browser web normal pentru a putea vizualiza aplicația. La acest punct paginile sunt încă furnizate de instanța Tomcat‐ului inclus în shell, dar la fel de bine pot fi furnizate din fişiere sistem sau un server web obişnuit. O altă modalitate de a invoca compilatorul GWT este prin intermediul scriptului aflat la baza aplicației (MyApp-compile). De asemeni se poate scrie un script care sa fie rulat cu Ant. De fiecare dată cand este invocat, compilatorul GWT combină codul nostru cu o versiune JavaScript a API‐ului GWT (echivalentul pentru gwt-user.jar) într‐un fişier JavaScript. Acest cod împreună cu alte fişiere auxiliare sunt plasate în diectorul www al proiectului. De asemeni, tot ce se găseşte în directorul public al proiectului va fi copiat.
- 21. Figura de e mai sus pre ezintă paşii p pentru încăr rcarea unei p pagini în mo odul host: 1. programul sh hell deschide e o fereastră care conțin ne un browse er de tip hos st, în care încarcă pagina MyAp pp.html; 2. M MyApp.html încarcă gwt. .js printr‐un tag <script> >; 3. gw wt.js scanează MyApp p.html pentru a extrag numele modului din tagul: <meta ge name=’gwtm module’>; 4. G GWT citeşte fişierul modul M MyApp.gwt.x xml pentru a găsi numele c u clasei EntryPoint(M MyApp); 5. cl lasa MyApp este instan nțiată şi este apelată m e metoda onMo oduleLoad. De aici porn neşte aplicația; 6. co odul aplicați iei apelează librăria din G GWT (gwt‐user.jar); odul din gwt‐user.jar manipulează DOM‐ul bro 7. co owser‐ului pe entru a adău uga compon nente UI pe pagina web şi pentru a redirect U ta toate evenimentele d din browser c către aplicaț ție.
- 22. Urmă ătoarea figur ră prezintă f fluxul execuț țiilor pentru u a încărca o o pagină în m modul web: 1. browser‐ul w web încarcă M MyApp.html; 2. M MyApp.html încarcă gwt. .js folosind t tag‐ul <scrip> >; 3. gw wt.js parcu urge MyAp pp.html pe entru a a afla numele modulului din: <meta e name=’gwtm module’>; 4. gw wt.js modifică pagina pentru a include un <ifra ame> care c cauzează încărcarea fişie erului module‐name m e.nochache. .html; 5. co odul JavaScript din fişie erul module e‐name.noca ache.html d determină tipul browser‐ului apoi selectează fişierul co orect pentru u acel browser; 6. este executa codul JavaScript ehivalent m at metodei on nModuleLoad d(), lansând du‐se aplicația. Manipularea D DOM‐ului din browser e n este făcută prin apeluri HTML dina amice din codul Java aScript compilat.
- 23. 6. Utilitatea GWT Premisa care a stat la baza GWT‐ului a fost simplă: dezvoltarea de aplicații Ajax într‐un mod mult mai simplu, şi anume scutindu‐i pe programatori de incompabilitatea dintre browser‐ e şi permițând dezvoltatorului să lucreze într‐un mediu de dezvoltare Java familiar (fără a fi nevoie de cunoştințe solide de JavaScript si DHTML). După cum aminteam mai sus, GWT este primul framework pentru crearea de aplicații web folosind limbajul Java care permite realizarea de aplicații asemănătoare cu cele pentru desktop, dar care sunt rulate în browser. Google Web Toolkit unifică codul pentru client şi server într‐o singură aplicație scrisă într‐un singur limbaj: Java. Acest lucru are numeroase avantaje. Unul dintre acestea ar fi că mai mulți dezvoltatori folosesc Java față de JavaScript sau Flash. Un alt motiv ar fi acela că pentru Java există numeroase medii de dezvoltare: Eclipse, NetBeans, IntelliJ IDEA etc. GWT permite crearea unei aplicații web într‐un mod asemănător cu crearea unei aplicații Swing – crearea de componente vizuale, setarea event‐handler‐ilor, depanare etc – toate aceste în IDE‐ul preferat. Prin folosirea aceluiaşi limbaj se poate folosi acelaşi cod atât pentru server cât şi pentru client. De exemplu, se poate rula acelaşi cod de validare odată pe partea de client pentru feed‐back imediat, precum şi pe partea de server pentru securitate maximă. De asemeni, se poate muta cod între “straturile” aplicației în momentul când rearanjăm structura aplicației. Nevoia de a scrie cod in Java, şi nu în JavaScript, este fundamentală pentru aplicațiile Web complexe, deoarece se reduce dimensiunea aplicației, aceasta devenind mai uşor de administrat. Însă, GWT permite integrarea codului JavaScript în aplicație, precum şi integrarea unor servicii pentru partea de server. GWT este construit deasupra tehnologiilor web, conferindu‐i astfel o mai mare putere. Această putere provine din faptul că aplicațiile GWT pot rula pe orice tip de browser şi pe mai multe sisteme de operare, precum şi din faptul că acest gen de aplicații pot fi rulate cu uşurință pe mai multe calculatoare. Totuşi, dezvoltatorii de aplicații care folosesc acest toolkit, nu trebuie să folosească direct tehnologiile web, GWT “ascunzând” aceste tehnologii din fața
- 24. programatorului prin folosirea unei abstracții de genul unui framework ce foloseşte limbajul Java. 7. Comparaţie cu alte 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.
- 25. Aceste diferențe minore fac din GWT un mediu de dezvoltare destul de familiar dezvoltatorilor de aplicații Swing. 7.2 GWT vs. Echo2 Echo2 este un alt toolkit popular în rândul dezvoltatorilor de aplicații web ce folosesc limbajul Java. Acesta se aseamănă cu GWT datorită modalității asemănătoare de a construi interfața cu utilizatorul. Echo2 foloseşte clasele din API pentru crearea de instanțe a componentelor, apoi le adaugă view‐ului. Deşi cele două framework‐uri folosesc API‐uri similare, ele lucrează în maniere total diferite. Aplicațiile Echo2 rulează pe server, față de aplicațiile GWT care rulează pe client. Cu GWT codul sursă Java este compilat şi transformat în JavaScript pentru a putea fi rulat în browser, pe când cu Echo2 codul sursă Java este compilat în clase Java apoi este rulat pe server, această obligând programatorul să trateze pe server eventualele evenimente apărute pe client. Aceasta duce la consecința de a se face mai multe apeluri la server în Echo2, însă nu este nevoie de a fi implementat un mecanism de tip RPC, deoarece totul se petrece pe server. O alta consecintă a modului de funcționare a Echo2, este aceea că nu este nevoie să fie trimis browser‐ului tot codul JavaScript rezultat în urma compilării, ci doar ceea ce este nevoie pentru stadiul curent al aplicației. 7.3 GWT vs JSF Java Server Faces (JSF) este un framework pentru crearea aplicațiilor web bazate pe limbajul Java în cadrul căruia se folosesc bean‐uri pe server pentru reprezentarea modelului, plus un set de librării de taguri folosite în paginile JSP pentru a referi proprietățile modelului. În implementarea JSF standard, toate procesările sunt făcute de către server, iar paginile web
- 26. sunt reîncărcate după fiecare tranzacție, ceea ce nu face ca JSF să fie viabil pentru construirea componentelor pentru aplicații RIA, însă cu puțin efort este posibil. Primul pas pentru crearea unei aplicații folosind JSF este să creem clasa care reprezintă modelul, apoi să înregistrăm în fişierul de configurare acea clasă ca fiind de tip managed‐bean. Următorul pas este să construim pagina JSP care va reprezenta view‐ul aplicației. JSF diferă foarte mult de GWT prin faptul că JSF oferă puține avantaje pentru crearea suportului pentru funcționalitatea pe partea de client a unei aplicații RIA; este posibilă construcția de componente reutilizabile pentru partea de client apelându‐se la JavaScript, însă componentele custom au puține şanse de a fi reutilizate. Datorită faptului că JSF integrează şi partea client, poate fi considerată o tehnologie în competiție cu GWT, însă există şanse ca cele două să fie integrate. 7.4 GWT vs Ruby on Rails Acest titlu poate să ducă în eroare deoarece GWT şi Ruby on Rails (RoR) nu se află în competiție cu toate că la unele aspecte se pot suprapune. Ruby on Rails este un framework care foloseşte limbajul Ruby pentru a implementa partea de server a aplicației, fiind special creat pentru a executa automat o mare parte din munca din spate. Pe partea de server, RoR oferă suport pentru Ajax, permițând să fie folosit în codul HTML echivalentul Java pentru o librarie de taguri. Rezultatul final este acela că RoR poate trimite informații către server când este declanşată o acțiune a utilizatorului, iar răspunsul este afişat în pagină. RoR nu este creat pentru tratarea interacțiunilor complexe dintre server şi client. Analizând puterea celor două limbaje, se poate afirma ca în locul unei competiții dintre cele două, ar putea lua naştere o colaborare. La această concluzie se poate ajunge datorită faptului ca GWT deține unele avantaje privitoare la mecanismele de transmitere a informațiilor între server şi client. S‐a observat că din ce în ce mai mulți programatori care folosesc alte tehnologii decât Java pe partea de server, sunt mulțumiți de rezultate pe care GWT le oferă pe partea de client prin integrarea cu alte tehnologii pe partea de server.