Dojo for Programmers
Finest tools for programmers by programmers.
About me

• I am Eugene Lazutkin (read: la-ZOOT-kin).
• Started to work with JavaScript since ~1998.
• Worked with Dojo To...
This talk is about...

• Programmer's tools of trade.
• Different programming paradigms...
  • ...in JavaScript
     • ...a...
This talk is not about...


• Widgets, maps, charts, grids.
• Browsers, DOM, CSS.
• HTTP, XML, JSON.



                  ...
JS before ~2005


• Progressive enhancements:
  • Project code base is small.
  • General complexity is low.
  • No need t...
JS now

• Web applications are on the rise:
  • 100s kbytes of minified code.
  • Asynchronous exchange of data with server...
Code structure

• Tried and true techniques:
  • Modules
  • OOP
  • AOP
  • EDP
  • FP
                       7
Modules

• Separation of concerns.
• Well-defined API improves maintainability.
• For reusable components: a distribution u...
Modules in Dojo I

• One module - one file.
• Can load other modules.
• Just two functions are visible:
  • dojo.provide() ...
Modules in Dojo II

• There is no restriction on content of a module.
 Anything goes.

• Usually module defines discoverabl...
Modules in Dojo III

• Module names all follow a simple convention:
  • "dojox.gfx.svg" => "dojox/gfx/svg.js".
• Top name ...
Modules in Dojo IV

• Your custom modules are first class citizens.
• The default mapping takes care of a common
 case when...
Example

dojo.provide("dojox.charting.Theme");


dojo.require("dojox.color");
dojo.require("dojox.color.Palette");
dojo.re...
Why?

• We don't need to track dependencies manually.
  • No need to include dependencies manually.
• We can use the same ...
Dojo tools I


• In browser Dojo comes with two loaders:
  • Simple synchronous XHR-based loader for
    debugging.

  • C...
Dojo tools II
• Dojo Builder is used to prep an app for
 deployment.

  • Collecting all required modules in one or
    mo...
OOP

• Proven technique to tame the complexity.
• Modularity on a different level.
• Objects are chunks of state with a wel...
OOP in JS

• Everything is an object.
• Prototypal inheritance.
• Constructors.
• Dynamic nature:
  • Duck typing - satisf...
OOP in Dojo


• Dojo doesn't try to make JS the language
 "better".

• Dojo doesn't go against the grain.
• Dojo provides ...
OOP the JS way

• Constructor + delegation:
 var MyCtor = function () {
      // construct an object
      this.name = “ci...
Delegation I
• Common idiom:
 function Temp () {} // does nothing


 dojo.delegate = function (obj, props) {
      Temp.pr...
Delegation II

• dojo.delegate() is one of the oldest functions
 in Dojo.

• This pattern is so common that it was
 enshri...
Modern OOP techniques

• Problems with classic OOP:
  • Single inheritance is no good at code reuse.
     • A fish, a duck,...
Mixins I

• Assemble objects from independent "bricks",
  which encapsulate a state and a functionality.

• Each mixin is ...
Mixins II

• It can reuse and update existing object
  variables and methods.

• It can have its own state and methods.
• ...
Object's lifecycle

• Constructing an object.
• Destructing an object.
  • Required if object uses external resources.
• A...
Interaction with mixin I

• Mixin can use host object's variables and
 methods.

  • The simplest way is to use a conventi...
Interaction with mixin II
• Mixin can refer to object's methods
 anonymously.

  • There is a way to specify how certain
 ...
dojo.declare() I
• Simple object + single inheritance:
 // no parent, inherits from Object
 var A = dojo.declare(null, {})...
dojo.declare() II

• Mixins:
 var Duck = dojo.declare([Bird, Swimmer], {
      constructor: function (name) {
           t...
dojo.declare() III
• Conventions:
  • All mixins and base classes are sorted
    according to C3 MRO (topological sort use...
dojo.declare() IV
• Conventions:
  • Constructors are called in reversed order.
    • The deepest one is called first.
  • ...
dojo.declare() V


• In general dojo.declare() operates in terms of
 dojo.delegate().

• It automates a frequently occurri...
How to reach me


• My web site: http://lazutkin.com
• Twitter: http://twitter.com/uhop
• Email: eugene@dojotoolkit.org
• ...
But wait! There is more!

• Dojo offers much more:
  • AOP tools:
    • Discussed in http://lzt.me/dBc
    • Pete Higgins w...
And even more!
• Even more tools:
  • EDP:
    • dojo.Deferred is included in the Base to
      handle asynchronous events...
That’s all for now!




         37
Upcoming SlideShare
Loading in...5
×

Dojo for programmers (TXJS 2010)

2,504

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,504
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
81
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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×