Dojo (QCon 2007 Slides)

1,671 views

Published on

My old slides on Dojo 0.4 written for QCon 2007, where I introduced the upcoming Dojo 0.9. Preserved here mostly for their historical value. :-)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,671
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
49
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dojo (QCon 2007 Slides)

  1. 1. Modern web applications with Dojo: the cutting edge Eugene Lazutkin, DojoToolkit.org
  2. 2. Disclaimer ● I am a Staff Engineer of Sun Microsystems, but this presentation doesn't necessarily reflect any official stance of said company ● Today I speak with you as a Dojo committer and a fellow software developer 2
  3. 3. Modern web applications 3 (cc) Darren Hester, http://www.flickr.com/photos/ppdigital/3095634/
  4. 4. Drivers of modern web apps (client) ● JavaScript – More-or-less uniform support of the standard across browsers ● DOM (Document Object Model) – Better access to layout engine – Better support for CSS standards 4
  5. 5. Drivers of modern web apps (client) ● Events – Consistent support of interactive features ● XHR (XMLHTTPRequest) – Interaction with the server: ● Ajax ● Comet 5
  6. 6. Drivers of modern web apps (client) ● Performance improvements – Faster hardware, software, networks ● Human factor – Listen what your users tell you – We do, and the most common request is... 6
  7. 7. “We want better user experience!” (cc) Jacob Appelbaum, http://www.flickr.com/photos/ioerror/407491823/ 7 Zombie Mob (San Francisco, CA, USA)
  8. 8. Ajax web applications: “The enhancer” ● Add a helper to enhance the existing non-Ajax functionality ● The application provides a natural fallback, if the client doesn't support Ajax ● Majority of UI generation/processing is on the server. 8
  9. 9. Ajax web applications: “The enhancer” ● Example: an auto-suggest input box – If the client doesn't support JavaScript, we expect our user to enter complete input strings. – We can “complete” user's input on the server, and present choices back. 9
  10. 10. Ajax web applications: “The enhancer” ● Pros: – Scales down naturally for “dumb” clients – Minimizes the development costs, if majority of clients do not support Ajax ● Cons: – Scaling up for “smart” clients is limited – Some UI techniques are impossible 10
  11. 11. Ajax web applications: “The enhancer” ● When to use: – A “cosmetic surgery” of an existing “Web 1.0” application – Majority of targeted users use “dumb” clients: ● Mobile users ● Legacy browsers ● Accessibility concerns ● Legal concerns 11
  12. 12. Ajax web applications: “Web 2.0” ● Some essential parts of UI are on the client. ● The application has a non-Ajax path. ● Server generates the UI and provides a low- level data access API. 12
  13. 13. Ajax web applications: “Web 2.0” ● Example: drag-and-drop (DnD) – Doesn't lend itself for a non-Ajax fallback – Can be replaced with a set of buttons (hard to use) – In some cases we need to redesign the non-Ajax UI replacement – We will review DnD later (time permitting) 13
  14. 14. Ajax web applications: “Web 2.0” ● Pros: – We can build attractive user interfaces for capable browsers – Reduces the server load ● Cons: – Hard to scale down – May need a separate path for “dumb” clients 14
  15. 15. Ajax web applications: “Web 2.0” ● When to use: – Majority of targeted users use “smart” clients – We try to balance our development efforts: ● Is it easier to do on the server? ● Is it easier to do on the client? – We redesign an existing “Web 1.0” application by modules 15
  16. 16. Ajax web applications: “One-page app” ● All UI functionality is on the client ● “Legacy” clients are supported separately, if they supported at all. ● The application runs locally (literally) and may have completely “local” look and feel replacing “connected applications” 16
  17. 17. Ajax web applications: “One-page app” ● Example: the dialog box based CRUD application – All functionality falls neatly into list/viewer/editor pattern conforming to Create/Update/Delete – The server provides REST/SOAP API to data – All files (HTML, CSS, JS) are static ● The server doesn't spend time on unnecessary tasks ● We can cache aggressively 17
  18. 18. Ajax web applications: “One-page app” ● Pros: – Gives users the experience of local applications + the universal access of web applications – Minimizes the server load ● Cons: – Requires a completely different path for “dumb” clients or we should have a complete control over our client base – It is hard to implement 18
  19. 19. Ajax web applications: “One-page app” ● When to use: – We control what users use, so we can reject “dumb” clients: ● IT ● A subscription service ● Specially targeted users – We can afford providing a reduced functionality for “dumb” clients simplifying the non-Ajax path – We want to unload servers to the max 19
  20. 20. The way of Dojo: helping hands 20
  21. 21. The Dojo way: JavaScript ● Dojo provides numerous enhancements and common algorithms including: – OOP helpers – simple way to setup single and multiple inheritance (dojo.declare) – JS object creators – mixins, delegation (dojo.lang.common) – Python-like repr facility with support for custom formatters (dojo.lang.repr) – FP helpers – currying, map/reduce, and so on. 21
  22. 22. The Dojo way: DOM ● Dojo normalizes differences in DOM implementation, and implements common algorithms – Node, parent/child, ancestor/descendant manipulations – Class manipulations – Opacity, and color functions – Layout calculations – Metrics, and much much more 22
  23. 23. The Dojo way: Events ● Dojo implements a subset of AOP (Aspect- Oriented programming) ● It allows to chain event handlers using following advices: – After – the handler is attached to the end of the queue – Before – the handler is attached to the front of the queue – Around – the handler replaces the queue 23
  24. 24. The Dojo way: Events ● Handlers can be dynamically connected and disconnected ● Disconnecting handlers reverts the queue to the previous state ● Browser events are normalized ● Uniform support for canceling bubbling events, and return values 24
  25. 25. The Dojo way: Events ● Examples: dojo.event.connect(node, “onclick”, my_handler); dojo.event.connect(dojo.body(), “onmousemove”, obj, “onmousemove”); dojo.event.connectBefore(node, “onclick”, my_handler2); dojo.event.disconnect(node, “onclick”, my_handler); 25
  26. 26. The Dojo way: Events ● You can invent your own events ● In fact any method call is an event! ● Example: var x = { ... add: function(a, b){...}, ...}; dojo.event.connect(x, “add”, function(a,b){ alert(“a=” + a + “b=” + b); }); 26
  27. 27. The Dojo way: Events ● Topics: custom named events ● Very powerful and clean way to structure an application ● Clients can subscribe and unsubscribe from events ● Servers can publish events ● Any number of parameters can be sent 27
  28. 28. The Dojo way: Events ● Examples: dojo.event.topic.subscribe(“start”, my_obj1, “onstart”); dojo.event.topic.subscribe(“start”, my_obj2, “onstartstop”); dojo.event.topic.publish(“start”, 1, 2, 3, 4, 5); 28
  29. 29. The Dojo way: XHR ● Dojo exposes XHR through dojo.io.bind(): – Supports different I/O methods ● GET, POST, multipart POST... – Supports data conversion for XML and JSON returned data – Pluggable transports ● XmlHTTPRequest object, IFRAME, <SCRIPT>... 29
  30. 30. The Dojo way: XHR ● Examples: dojo.io.bind({ // GET request url: “...”, content: {arg: 1} }); dojo.io.bind({ // POST request url: “...”, content: {arg: 1}, method: “POST” }); 30
  31. 31. The Dojo way: XHR ● More examples: dojo.io.bind({ // multipart POST url: “...”, content: {arg: 1}, method: “POST”, multipart: true }); dojo.io.bind({ // multipart POST url: “...”, file: {name: “A”, contentType: “text/plain”, content: “hello”} 31 });
  32. 32. That was easy! 32
  33. 33. Dojo packages ● All Dojo functionality organized in packages or widgets ● How to request a package? dojo.require(“dojo.dom”); ● Dojo Loader translates package names to file names, and loads packages on demand ● The loader makes sure that all packages loaded only once 33
  34. 34. Dojo packages ● More-or-less complete example: ... <script src=”dojo/dojo.js”></script> <script> dojo.require(“dojo.dom”); dojo.dom.something(); </script> ... 34
  35. 35. Dojo packages ● How does it work? – The loader keeps track of all loaded packages – If a package is not loaded yet, the loader maps the package name to a file name – The file is loaded synchronously if required – There is no need to include required packages manually with <script> (unless your debugger requires that) – All dependencies are satisfied automatically 35
  36. 36. Dojo packages ● Example: translate “dojo.dom” and “dojo.gfx.path” – Assuming that dojo.js file is in “dojo/” directory – “dojo.dom” ⇒ “dojo/src/dom.js” – “dojo.gfx.path” ⇒ “dojo/src/gfx/path.js” 36
  37. 37. Dojo packages ● Special value * is treated as “__package__.js” file ● Example: – “dojo.event.*” ⇒ “dojo/src/event/__package__.js” ● Usually it loads the default configuration 37
  38. 38. Dojo packages ● You can create your own packages with your own root ● Example: dojo.require(“dojo.dom”); dojo.require(“custom.dom.extra”); ● The Dojo loader can be hinted how to treat your custom namespace, but defaults are quite sensible 38
  39. 39. Dojo packages ● Default translation of a custom package name – Example: translate “custom.dom.extras”: ● Assuming that dojo.js is in “dojo/” directory ● “custom.dom.extras” ⇒ “dojo/../custom/dom/extras.js” ● ...or simply “custom/dom/extras.js” ● If your custom directory next to dojo, you don't need to do anything ● Otherwise you should tell the loader how to map your namespace 39
  40. 40. Dojo packages ● Loading a small number of packages is fast, but loading a lot of small packages takes time ● Before going to production you should prep packages: – Combine frequently used packages together – Compress resulting files using some syntax-aware algorithms (eliminate unnecessary whitespaces, reduces local names, and so on) – Compress the result with gzip 40
  41. 41. Dojo packages ● Dojo Build system does it for you – It takes a list your “seed” packages and builds a custom dojo.js file – The custom dojo.js will include all packages and their dependencies already processed ● Can I include my custom packages in the build? – Yes!!! 41
  42. 42. Dojo packages ● We provide Dojo in several pre-built flavors ● Example (the Ajax Dojo profile): var dependencies = ["dojo.io.*", "dojo.io.BrowserIO", "dojo.event.*", "dojo.lfx.*"]; load("getDependencyList.js"); ● You can build your very own custom-tailored Dojo profile with your custom packages 42
  43. 43. Dojo widgets (a very quick overview) ● Widget encapsulates a functionality of a visual entity (example: a drop-down data picker) ● It is specified by an HTML snippet (template), a CSS snippet, and a JavaSript code ● It can be instantiated directly from HTML using special attributes, or programmatically on the fly ● Widgets provide convenient building blocks for your application 43
  44. 44. “Fresh from the shed” Dojo (cc) Stanislav Lvovsky, http://www.flickr.com/photos/lvovsky/142611807/ Istanbul, Turkey 44
  45. 45. Dojo Graphics (dojo.gfx) ● “A picture is worth a thousand words” ● Because we are visual-oriented beings ● Because picture can convey more information than text on the same piece of screen 45
  46. 46. Dojo Graphics (dojo.gfx) ● Implements DOM-based vector graphics ● Supported shapes: – Path, polyline/polygon, rectangle, ellipse, circle, line, image, text, textpath ● Supported fills: – Solid color fill (with opacity), linear gradient, radial gradient ● Supports different strokes, fonts 46
  47. 47. Dojo Graphics (dojo.gfx) ● Arbitrary 2D transformations: – Shifts, scaling, rotation, skewing, and so on... ● Groups – Shapes can be transformed together ● All attributes can be changed dynamically, the picture will be regenerated automatically ● Event handlers can be attached to shapes 47
  48. 48. Dojo Graphics (dojo.gfx) ● Why DOM-based vector graphics? – Simpler to use (HTML is DOM too) – easy to modify a picture – Shapes can be used for catching events without additional coding – Automatic regeneration when objects are modified ● While procedural graphics is easier conceptually, it can be difficult to scale for complex cases (e.g., grouping, transformations...) 48
  49. 49. Dojo Graphics (dojo.gfx) ● Right now 2 back-ends are supported automatically: – SVG – Mozilla Firefox, Opera, Webkit – VML – Microsoft Internet Explorer ● In the future we may add more back-ends ● In the future we may add a Canvas-like API 49
  50. 50. Everybody loves charts... (cc) Brendan Dolan-Gavitt, http://www.flickr.com/photos/moyix/174053226/ 50 New Hampshire, USA
  51. 51. ...in both camps Uncensored original: (cc) J Clark, http://www.flickr.com/photos/idledesigns/14795430/ 51
  52. 52. Dojo Charting (dojo.charting) ● Based on SVG or VML ● At present time doesn't use dojo.gfx ● We will transition it to dojo.gfx in the near future adding more chart types ● Yes, we will add pseudo-3D charts including a pie chart 52
  53. 53. Offline applications 53 (cc) Michael Randall, http://www.flickr.com/photos/pigpogm/40889785/
  54. 54. Dojo Offline ● Ongoing project ● Supports the offline mode ● Can detect if it is offline or online ● Synchronizes data when online, caches when offline ● Relies on a persistent storage supported by browsers ● Natively supports Firefox 3 54
  55. 55. The way ahead 55
  56. 56. Dojo contributors/sponsors ● Corporate contributors/sponsors – AOL, LLC; BEA Systems; Curam Software, Ltd.; Defence Science & Technology Organisation; Elastic Path; Emerald Hand, Inc.; EuroClick, LLC; GCGF; Global Media Systems; GreenPlum; IBM; Indico Group; Laszlo Systems, Inc.; Media Hive; Meebo; Nexaweb Technologies, Inc.; OneTrackMind; OpenBravo; RedHat; Renkoo; SitePen, Inc.; Spider Strategies; Sun Microsystems, Inc.; Suretec Systems, Ltd.; Weswit S.R.L.; Wotan, LLC; Yuma Union High School District #70 56
  57. 57. Dojo contributors/sponsors ● ~200 individual contributors ● ~25 committers 57
  58. 58. In case you didn't see warnings... 58
  59. 59. Dojo 0.9 ● Why 0.9? – Because we want to have a milestone release before 1.0 ● Refactoring Dojo – Code duplication removal – More consistent idioms – Task-oriented fast paths – Reducing inter-dependencies 59
  60. 60. Dojo 0.9 ● Restructuring Dojo – Dojo Base – packaging all frequently used functionality in one small file – Dojo Core – a superset of Dojo Base with strict control of new additions – DojoX – Dojo eXtented – a place for less common packages – Dijit – Dojo Widgets 60
  61. 61. Dojo 0.9 ● Don't worry – 0.4.x line will be supported too! ● We will provide a detailed guide for 0.9 migration (if you want to migrate) ● Tentative 0.9 timeline – “the end of 2007”, but it can be changed ● We already started working on it 61
  62. 62. The end 62 (cc) Su Neko, http://www.flickr.com/photos/suneko/373310729/
  63. 63. Backup slides 63
  64. 64. Revisiting drag-and-drop (DnD) ● DnD is an extremely valuable but under- appreciated UI device ● It is absolutely indispensable when: – Reordering containers (e.g., lists, or trees) – Building a list (or any container) from several sources ● The alternatives are usually messy ● It helps us to reduce the UI complexity 64
  65. 65. Revisiting drag-and-drop (DnD) ● How familiar is it for users? – The File Manager of any modern OS uses DnD to copy/move files, and restructure directories ● Why is it underused in modern web apps? – Inadequate support of DnD in many JS toolkits – Web developers should think more like local app developers, and they don't – Conceptual gaps 65
  66. 66. Revisiting drag-and-drop (DnD) ● Main DnD players (the user point of view) – Data sources – Data targets – Data we want to move/copy from sources to targets – The application itself 66
  67. 67. Revisiting drag-and-drop (DnD) ● Huh? Data? – Some implementations of DnD “forget” that frequently user doesn't want to move DOM nodes, but wants to exchange the underlying data ● The application??? – The page should cooperate with DnD providing a visual feedback to the user – At the very least it should “show” available targets 67

×