Dojo for programmers (TXJS 2010)

2,860 views

Published on

Explanation of modules and OOP in Dojo.

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

No Downloads
Views
Total views
2,860
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
82
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide





































  • Dojo for programmers (TXJS 2010)

    1. 1. Dojo for Programmers Finest tools for programmers by programmers.
    2. 2. About me • I am Eugene Lazutkin (read: la-ZOOT-kin). • Started to work with JavaScript since ~1998. • Worked with Dojo Toolkit since 2005. • Dojo Committer responsible for core improvements, DnD, graphics, and charting. 2
    3. 3. This talk is about... • Programmer's tools of trade. • Different programming paradigms... • ...in JavaScript • ...and how Dojo supports them. • Why do we need them. 3
    4. 4. This talk is not about... • Widgets, maps, charts, grids. • Browsers, DOM, CSS. • HTTP, XML, JSON. 4
    5. 5. JS before ~2005 • Progressive enhancements: • Project code base is small. • General complexity is low. • No need to structure the code. 5
    6. 6. JS now • Web applications are on the rise: • 100s kbytes of minified code. • Asynchronous exchange of data with servers. • Teams of developers. • Reusable components. • Modularity. 6
    7. 7. Code structure • Tried and true techniques: • Modules • OOP • AOP • EDP • FP 7
    8. 8. Modules • Separation of concerns. • Well-defined API improves maintainability. • For reusable components: a distribution unit. • Browsers: a loading unit. • Usually roughly corresponds to <script>. 8
    9. 9. Modules in Dojo I • One module - one file. • Can load other modules. • Just two functions are visible: • dojo.provide() - declare a name of the module. • dojo.require() - request other module.  9
    10. 10. Modules in Dojo II • There is no restriction on content of a module. Anything goes. • Usually module defines discoverable names by attaching them to well-known global names. • Dojo defines "dojo" as a global namespace. • General convention is to define your own namespaces. 10
    11. 11. Modules in Dojo III • Module names all follow a simple convention: • "dojox.gfx.svg" => "dojox/gfx/svg.js". • Top name can be mapped. • The default mapping: • "myapp.foo" => "dojo/../myapp/foo.js" • Custom mapping can be defined too. 11
    12. 12. Modules in Dojo IV • Your custom modules are first class citizens. • The default mapping takes care of a common case when your subdirectory is a peer of "dojo": • /dojo • /myapp • Custom mapping takes care of specific requirements of your deployment. 12
    13. 13. Example dojo.provide("dojox.charting.Theme"); dojo.require("dojox.color"); dojo.require("dojox.color.Palette"); dojo.require("dojox.lang.utils"); dojo.require("dojox.gfx.gradutils"); dojo.declare("dojox.charting.Theme", null, { // summary: // A Theme is a pre-defined object, primarily JSON-based, // style a chart. 13
    14. 14. Why? • We don't need to track dependencies manually. • No need to include dependencies manually. • We can use the same modules in different environments. • Dojo is used with Rhino, Spidermonkey, Node.js... • We can automatically optimize our application. 14
    15. 15. Dojo tools I • In browser Dojo comes with two loaders: • Simple synchronous XHR-based loader for debugging. • Cross-domain asynchronous loader for CDNs. 15
    16. 16. Dojo tools II • Dojo Builder is used to prep an app for deployment. • Collecting all required modules in one or more layer files. • Minification of layers. • Collecting and minifying CSS files. • Inlining external resources (e.g., HTML snippets) in JS. 16
    17. 17. OOP • Proven technique to tame the complexity. • Modularity on a different level. • Objects are chunks of state with a well-defined compact API. • Possibility to reuse common behaviors using inheritance. 17
    18. 18. OOP in JS • Everything is an object. • Prototypal inheritance. • Constructors. • Dynamic nature: • Duck typing - satisfying APIs dynamically. 18
    19. 19. OOP in Dojo • Dojo doesn't try to make JS the language "better". • Dojo doesn't go against the grain. • Dojo provides helpers for existing patterns. 19
    20. 20. OOP the JS way • Constructor + delegation: var MyCtor = function () { // construct an object this.name = “circle”; }; MyCtor.prototype = { // delegate all undefined properties to this object radius: 1, area: function() { return Math.PI * this.radius * this.radius; } }; 20
    21. 21. Delegation I • Common idiom: function Temp () {} // does nothing dojo.delegate = function (obj, props) { Temp.prototype = obj; var t = new Temp(); Temp.prototype = null; if (props) { dojo.mixin(t, props); } return t; }; 21
    22. 22. Delegation II • dojo.delegate() is one of the oldest functions in Dojo. • This pattern is so common that it was enshrined in JS5 as Object.create(). • Still as you can see the constructor function is unused. 22
    23. 23. Modern OOP techniques • Problems with classic OOP: • Single inheritance is no good at code reuse. • A fish, a duck, a hippo, and a submarine can swim. Does it mean they have a common ancestor? • Modern approaches: mixins, traits, aspects, delegates. 23
    24. 24. Mixins I • Assemble objects from independent "bricks", which encapsulate a state and a functionality. • Each mixin is like a mini-object, yet it doesn't make sense on its own. • It can be composed of other mixins. • It is (re)used in different objects => all dependencies should be anonymous. 24
    25. 25. Mixins II • It can reuse and update existing object variables and methods. • It can have its own state and methods. • It can be composed of other mixins. • It participates in a lifecycle. 25
    26. 26. Object's lifecycle • Constructing an object. • Destructing an object. • Required if object uses external resources. • Application-specific events: • Dijit defines events before and after building DOM for a widget. 26
    27. 27. Interaction with mixin I • Mixin can use host object's variables and methods. • The simplest way is to use a convention. • Mixin knows names it uses. • Object provides proper semantic units using those names. 27
    28. 28. Interaction with mixin II • Mixin can refer to object's methods anonymously. • There is a way to specify how certain methods are called: • Automatically before/after its host's method. • Replacing a host's method and using some means (a super call) to call host. 28
    29. 29. dojo.declare() I • Simple object + single inheritance: // no parent, inherits from Object var A = dojo.declare(null, {}); var a = new A(); // single inheritance var B = dojo.declare(A, {}); var b = new B(); a instanceof A; // true b instanceof A; // true b instanceof B; // true 29
    30. 30. dojo.declare() II • Mixins: var Duck = dojo.declare([Bird, Swimmer], { constructor: function (name) { this.name = name; }, say: function () { return “Quack!”; } }); var duck_1 = new Duck(“Donald”); var duck_2 = new Duck(“Daisy”); var duck_3 = new Duck(“Daffy”); 30
    31. 31. dojo.declare() III • Conventions: • All mixins and base classes are sorted according to C3 MRO (topological sort used by Dylan, Perl, Python). • All dups are eliminated. • Order of dependencies is satisfied. • Native prototypal inheritance is used to chain all bases and mixins. 31
    32. 32. dojo.declare() IV • Conventions: • Constructors are called in reversed order. • The deepest one is called first. • A super call: this.inherited() • No need to know who is "next in chain". • Automatic after/before chaining can be specified for methods. 32
    33. 33. dojo.declare() V • In general dojo.declare() operates in terms of dojo.delegate(). • It automates a frequently occurring pattern using simple conventions. • The only non-trivial addition is a super call. 33
    34. 34. How to reach me • My web site: http://lazutkin.com • Twitter: http://twitter.com/uhop • Email: eugene@dojotoolkit.org • Slides: http://www.slideshare.net/elazutkin 34
    35. 35. But wait! There is more! • Dojo offers much more: • AOP tools: • Discussed in http://lzt.me/dBc • Pete Higgins will talk more about it today. • FP tools: • Discussed in http://lzt.me/dB6 35
    36. 36. And even more! • Even more tools: • EDP: • dojo.Deferred is included in the Base to handle asynchronous events. • dojox.lang.async provides high-level primitives to combine/synchronize events: seq(), par(), any(), select(), ifThen(), loop(). 36
    37. 37. That’s all for now! 37

    ×