Published on

Présentation de GWT par Olivier Gérardin

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • <number>
  • <number>
  • <number>
  • MyERP: Mime_Inc, admin/9p5fJJ_AH
    Compiere: Server: User ID:    Olivier Gérardin Password:    20004098
  • <number>
  • A améliorer (dessin/anim)
  • A améliorer (dessin/anim)
  • Étayer les arguments
  • Origine du nom JavaScript: accord entre Netscape et Sun pour promouvoir la marque “Java”
  • <number>
  • BrowserBpook:
  • Side discussion: high-level languages vs low-level languages. Make the point that although using GWT means giving up some JS idioms, the benefits are elsewhere.
  • GWT performs “Browser sniffing” (controversy)
  • GWT

    1. 1. GWT = Easy AJAX L o r ra i n e J u g 7 / 1 2/ 20 09
    2. 2. Who am I? Olivier Gérardin Technical Director, Sfeir Benelux (groupe Sfeir) Java / Web architect 13+ years Java 3 years GWT  
    3. 3. Agenda Little GWT showcase Why GWT? How does it work? Key features Myths & misconceptions Pointers, Conclusion, Q&A
    4. 4. GWT Showcase Ext-GWT explorer Piano Etudes GWTUML Clarity Accounting ContactOffice MyERP, Compiere And more: Google Wave, Timetonote CRM …
    5. 5. Why GWT?
    6. 6. The web 0.0 Or “The Link Era”  A web page is just a bunch of images and text with links  Links take you to a new page  Click on link  HTTP request is built (from static link URL) and sent  Wait for server to reply  Server replies with HTML page (usually from static storage)  Response received  blank screen  Wait for entire page to load
    7. 7. “Dynamic” web with forms (web 1.0) Or “The Form Era”  In addition to images and text, a web page can contain fields and other widgets  A designated button submits the form  Fill in form  Submit  HTTP request is built (from form parameters and field values) and sent  Wait for server to reply  Server replies with HTML page (usually generated on server)  Response received  blank screen  Wait for entire page to load
    8. 8. An example of form-based web application: Squirrel mail
    9. 9. Server side processing CGI  Basic bridge to OS commands  Very ineffective (1 request = 1 process) Web server with dedicated module (PHP, …)  Scripted  Usually interpreted Application server with thread pool management (JSP, …)  More effective  JSPs are compiled at first invocation ASP, perl, whatever …still requires full page reload
    10. 10. Java Applets Plain Java application inside a web page! Server interaction without page reload! Rich UI (Swing)! But…  No consistent JVM support (MS vs Netscape/Sun)  Sloooooooow start  Hard to interface with the rest of the page  Mostly seen as a gadget for irritating animations
    11. 11. There comes JavaScript Client-side scripting First usage: server-side form validation  Avoid server round-trip when invalid  Instant feedback With DHTML: polymorphic client page  Menus, animations, etc. Cross-browser (almost) Still no server interaction without submit/reload 
    12. 12. XHTTPR and AJAX MS introduces Office Web Access  JavaScript “clone” of desktop client (Outlook)  Fetches data from server without reloading page! How is that possible?  New class: XmlHttpRequest  Allows server interaction without page reload  Response received asynchronously  Interface updated through DOM AJAX is born!
    13. 13. The first AJAX app: Outlook Web Access
    14. 14. JavaScript frenzy JS becomes hype… Cool-looking, nice to use web UIs Everyone wants to do JavaScript Any serious web site must have dynamic content, auto- completion or other AJAX goodies Widget sets / frameworks begin to emerge  Scriptaculous, YUI, dojo, jScript, … Anything seems possible in JavaScript  JavaScript OS, AjaxSwing (WebCream), …
    15. 15. JavaScript hangover Serious JavaScript hurts…  Cross-browser compatibility nightmare  Fix in one, break in another  JavaScript Guru required!  Developing/Debugging nightmare  Weird runtime errors  No static typing  No refactoring  And..  Memory leaks  Heavy pages  Security issues
    16. 16. JavaScript confusion Source: BrowserBook © Visibone
    17. 17. What to do? Change jobs? Subcontract? Give up dynamic pages?  Back to web 1.0… Target a single browser?  Not an option for Internet apps Give up AJAX and use other technology?  Plugin required  SEO unfriendly  Proprietary environment / learning curve  What server-side technology to match?
    18. 18. Use GWT ! GWT gives you AJAX without the pain of JavaScript development  Takes care of cross-browser issues  Allows full debugging (breakpoints, step by step, inspecting/watching variables)  Strong static typing  early error detection  Full refactoring options  No browser plugin or mandatory IDE  Short learning curve  Simple RPC mechanism  But can communicate with any server technology
    19. 19. Program in Java… GWT allows developing client-side web apps in full Java (with only a few restrictions)  Leverage existing Java tools and skills  Use any IDE (Eclipse, NetBeans, IntelliJ, …) Program like a traditional graphical client (Swing, SWT, …)  Widgets, containers, listeners, etc.  Use OO patterns (MVC, MVP, observer, composite, etc.) Test like any Java app  Use standard Java debuggers  Test with JUnit
    20. 20. … forget JavaScript! JavaScript is only generated:  For deployment  To test in actual web mode GWT’s promise is that the generated JavaScript app behaves exactly like the Java app  And it does (most of the time) (forgetting JavaScript not mandatory)
    21. 21. How does it work?
    22. 22. 4 easy pieces 1) Java-to-JavaScript compiler 2) JRE emulation library 3) Java libraries 4) Hosted Development mode
    23. 23. GWT compiler Generates JS code from Java sources Performs numerous optimizations  In most cases better than hand coding  Can generate obfuscated (ultra-compact) code JS plays a role similar to bytecode for compiled Java applications
    24. 24. JRE Emulation library Provides a GWT-compatible version of Java core classes  Most of java.lang  Most of java.util  Some classes of and java.sql  For convenience only! No real I/O or JDBC! Used when running in web mode  Hosted mode runs in a JVM with standard JRE
    25. 25. GWT Java libraries Utility classes  RPC, I18N, … Widget set  Simple widgets (Button, TextField, …)  Base building blocks  In most cases map to native HTML object  Composites = widgets built from other widgets  Panels = widget containers  Panels enforce a layout (vertical, horizontal, grid, …)
    26. 26. GWT widgets: Simple widgets
    27. 27. GWT widgets: Composites
    28. 28. GWT widgets: Panels
    29. 29. Hosted / Development mode Allows running GWT apps without converting them to JavaScript  Code runs as Java bytecode in a standard JVM  Embedded web browser emulates HTML rendering  platform-dependant…  Performs extensive checks to make sure the code is compilable to JavaScript Bottom line: if a GWT application performs as expected in development mode, it will perform identically in web mode  True 99,9% of the time
    30. 30. Key features
    31. 31. Easy development During development, you are writing and running a classic Java app  Use your favorite IDE  All IDE features available (code completion, code analysis, refactoring, links, Javadoc, …)  Plugins help GWT-specific tasks (launching, compiling, creating RPC services, …)
    32. 32. Easy RPC RPC mechanism based on Java servlets Easy as: 1. Define service interface int add (int x, int y); 3. Derive asynchronous interface void add (int x, int y, AsyncCallback<Integer> callback); 5. Implement service interface (server-side) public int add (int x, int y) { return x + y; }
    33. 33. Easy JSON generation Easy as: JSONObject livre = new JSONObject(); livre.put("Titre", new JSONString("GWT")); livre.put("Pages", new JSONNumber(123)); JSONArray chapitres = new JSONArray(); chapitres.set(0, new JSONString("Introduction"));
    34. 34. Easy JSON parsing Easy as: JSONObject livre = new JSONObject(json); String titre = livre.get("Titre").isString().stringValue(); double pages = livre.get("Pages").isNumber().doubleValue(); JSONArray chapitres = livre.isArray(); String chap0 = chapitres.get(0).isString().stringValue();
    35. 35. Deferred binding Appropriate code for user environment (browser, locale) is chosen at application startup time  ≠ dynamic binding (implementation chosen at runtime)  ≠ static binding (implementation chosen at compile time) Code for every combination is generated at compile time Advantages:  Allows app-wide optimizations  Compensates for the lack of dynamic (runtime) loading Disadvantages:  Increases compilation time
    36. 36. Deferred Binding (explicit) Deferred binding can be called explicitly: Foo foo = GWT.create(Foo.class); Implementation is provided by either:  Substitution: an existing class is designated  Generation: class is generated during compilation
    37. 37. Easy native JavaScript integration Implement a method directly in JavaScript: public static native void alert(String msg) /*-{ $wnd.alert(msg); }-*/;  Call back Java methods from JavaScript  Pass objects back and forth Useful to wrap legacy JavaScript libraries
    38. 38. Easy Widget reuse Create your own widgets:  Extend existing widget  Works but not the most efficient  Might expose unwanted methods from superclass  Extend Composite  Recommended method  Use JSNI  To wrap existing JavaScript widgets
    39. 39. Easy history support AJAX app = single page  “back” button  catastrophe… GWT solution:  Encode app state in URL as “fragment”  E.g. http://myserver/myGwtApp#x=1;y=2  Save state:  History.newItem(token);  React to state change (“back” button)  History.addValueChangeHandler(…);
    40. 40. Easy i18n Taking advantage of Deferred Binding 1. Define interface: public interface AppConstants extends Constants { String title(); } 3. “Implement” interface ( title = Hello, World 5. Use: AppConstants appConstants = GWT.create(AppConstants.class); String title = appConstants.title();
    41. 41. Easy i18n More advanced i18n 1. Define interface: public interface AppMessages extends Messages { String mailStatus(int n, String s); } 3. “Implement” interface ( mailStatus = You have {0} messages in folder {1} 5. Use: AppMessages msgs = GWT.create(AppMessages.class); String status = msgs.mailStatus(15, “Inbox”);
    42. 42. Easy debugging In development mode, application runs as bytecode (just like any old Java app…) So you can debug it just like any classic Java app:  Set breakpoints  Step through code  Inspect variables  Change variables  …
    43. 43. Easy client-server testing Integrated application server for testing RPC services  Can be disabled to use external server JUnit integration to run client-side test cases  Hosted mode or web mode  Full access to RPC services  GWTTestCase, GWTTestSuite for automation Selenium for automated GUI testing
    44. 44. Short dev cycle Change client code:  press “Reload”.. Done! Change server code:  Embedded server: press “Restart”.. Done!  External server: hotswap /redeploy if needed
    45. 45. Easy scaling All session data resides on client  Similar to classic fat client No session information on server-side  Forget session affinity  Add/remove servers on the fly  Restart server without losing clients
    46. 46. “Easy” styling Styling relies entirely on CSS  Widgets have well-known styles  Programmer can add custom styles No shift from traditional HTML styling  HTML/DOM build page “skeleton”  Appearance tuned with CSS Separate UI construction from styling  With well thought styles, it’s possible to reskin completely an application without changing one line of code GWT styling has all the benefits of CSS with all problems of CSS  Be careful with brower dependencies!
    47. 47. Easy Google APIs Project gwt-google-apis  Libraries that wrap Google JavaScript APIs  Gears,  gadgets,  AJAX search,  Maps,  Visualization,  Language,  AjaxLoader  Standalone libraries (do not require JavaScript libraries)
    48. 48. [new in 2.0] in-browser development mode Before: hosted mode uses customized browser engine  Heavily customized  Only one supported browser per platform (IE on Windows, WebKit on Mac, Mozilla on Linux)  Platform-specific code (SWT)  Difficult to keep up-to-date  Browser and hosted application share the same process  Most plugins don’t work (including Google Gears…)
    49. 49. [new in 2.0] in-browser development mode After:  Hosted mode shell runs outside browser  Communicates with browser using plugin through TCP
    50. 50. [new in 2.0] in-browser development mode Benefits  Use any (supported) browser/version on any platform  Behavior closer to web mode  No interference with browser plugins  No more platform-specific stuff in GWT (one jar for all!)  Network protocol cross-platform possible  Dev mode shell on machine X, slave browser on machine Y  E.g. dev on Linux, test in IE on Windows…
    51. 51. [new in 2.0] code splitting Before: monolithic download can become very big  Slow startup times After:  Programmer can insert “split points” in code  Hints for the compiler to place everything not required up to split point in separate download  Compiler divides code in several “chunks”, which are loaded on-demand Benefits:  Initial loading time reduced 50% on average with a single split point  Allows on-demand module loading
    52. 52. [new in 2.0] declarative UI Declarative construction of GUI using XML grammar Allows automatic binding with Java code  Assign widget references to Java fields  Automatically attach methods as event handlers Benefits:  Clearly separate:  Static UI construction (XML)  Dynamic UI behavior (Java)
    53. 53. [new in 2.0] resource bundle Download multiple heterogeneous resources from server in a single request  Images (already possible in pre-2.0)  CSS  Text  Any binary resource Benefits:  Fewer round trips to the server  Less overhead  More responsive interface
    54. 54. Myths & misconceptions
    55. 55. Myth: GWT is a JS library/framework/widget set GWT is not for JavaScript developers Provides only Java classes
    56. 56. Myth: GWT is a framework GWT is a toolkit (set of tools) Frameworks may be built on top of it
    57. 57. Myth: GWT is applets GWT app is full JavaScript No runtime/plugin No JRE required
    58. 58. Myth: GWT is only for Java programmers Yes, GWT uses Java as programming language… BUT you can also see it this way: GWT lets you write/debug/test/refactor AJAX apps with state-of-the-art IDEs and tools using a statically-typed object-oriented language GWT makes it worth learning Java!
    59. 59. Myth: GWT generates poorly performing JS The GWT compiler generates highly optimized and compact code Hand written JavaScript might be marginally faster in some cases, but it’s not worth the trouble
    60. 60. Myth: GWT only works with a Java backend GWT includes a simple and efficient RPC mechanism that relies on Java servlets BUT it plays nice with any server-side technology that can handle HTTP requests (even PHP)  Includes XML encoding/decoding library  Includes JSON encoding/decoding library
    61. 61. Myth: GWT has poor UI components Yes, GWT’s builtin widgets are minimalistic… BUT it’s not the point to provide a complete and beautiful widget set GWT provides the basis for rich and good-looking components Create your own or use 3rd party  See Ext-GWT, SmartGWT
    62. 62. Myth: GWT apps have long startup times Not longer than any JavaScript app Obfuscation reduces size Deferred binding loads just the necessary code for the platform/language GWT 2.0’s code splitting can split code in several chunks  Smaller initial download  On-demand downloading
    63. 63. Myth: GWT doesn’t integrate with existing sites GWT was designed from the beginning with the goal to integrate well into existing sites Very easy to add GWT to an existing page  Only a few lines of HTML  Can “hook up” to any DOM element
    64. 64. Myth: GWT has poor skinning possibilities GWT uses CSS for styling Can reskin a whole application without changing a line of code (done that!) Can split work between developer (behavior) and designer (appearance) Caution: CSS can introduce browser dependencies
    65. 65. Conclusion Is GWT the future of web development? GWT has passed reality check Who wants to hand-write JavaScript for 6 different browsers (and maintain it) ? GWT = easy AJAX now ! =
    66. 66. Pointers GWT home (downloads, docs, FAQs, guides, etc.)  Google groups “GWT” group  onGWT: fresh news about GWT  LinkedIn “GWT Users” group 
    67. 67. Shameless self-promotion
    68. 68. Thank you Questions?