37
Dojo for Programmers Finest tools for programmers by programmers.

Dojo for programmers (TXJS 2010)

Embed Size (px)

Citation preview

Page 1: Dojo for programmers (TXJS 2010)

Dojo for ProgrammersFinest tools for programmers by programmers.

Page 2: Dojo for programmers (TXJS 2010)

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

Page 3: Dojo for programmers (TXJS 2010)

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

Page 4: Dojo for programmers (TXJS 2010)

This talk is not about...

• Widgets, maps, charts, grids.

• Browsers, DOM, CSS.

• HTTP, XML, JSON.

4

Page 5: Dojo for programmers (TXJS 2010)

JS before ~2005

• Progressive enhancements:

• Project code base is small.

• General complexity is low.

• No need to structure the code.

5

Page 6: Dojo for programmers (TXJS 2010)

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

Page 7: Dojo for programmers (TXJS 2010)

Code structure

• Tried and true techniques:

• Modules

• OOP

• AOP

• EDP

• FP

7

Page 8: Dojo for programmers (TXJS 2010)

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

Page 9: Dojo for programmers (TXJS 2010)

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

Page 10: Dojo for programmers (TXJS 2010)

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

Page 11: Dojo for programmers (TXJS 2010)

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

Page 12: Dojo for programmers (TXJS 2010)

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

Page 13: Dojo for programmers (TXJS 2010)

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

Page 14: Dojo for programmers (TXJS 2010)

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

Page 15: Dojo for programmers (TXJS 2010)

Dojo tools I

• In browser Dojo comes with two loaders:

• Simple synchronous XHR-based loader for debugging.

• Cross-domain asynchronous loader for CDNs.

15

Page 16: Dojo for programmers (TXJS 2010)

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

Page 17: Dojo for programmers (TXJS 2010)

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

Page 18: Dojo for programmers (TXJS 2010)

OOP in JS

• Everything is an object.

• Prototypal inheritance.

• Constructors.

• Dynamic nature:

• Duck typing - satisfying APIs dynamically.

18

Page 19: Dojo for programmers (TXJS 2010)

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

Page 20: Dojo for programmers (TXJS 2010)

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

Page 21: Dojo for programmers (TXJS 2010)

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

Page 22: Dojo for programmers (TXJS 2010)

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

Page 23: Dojo for programmers (TXJS 2010)

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

Page 24: Dojo for programmers (TXJS 2010)

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

Page 25: Dojo for programmers (TXJS 2010)

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

Page 26: Dojo for programmers (TXJS 2010)

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

Page 27: Dojo for programmers (TXJS 2010)

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

Page 28: Dojo for programmers (TXJS 2010)

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

Page 29: Dojo for programmers (TXJS 2010)

dojo.declare() I• Simple object + single inheritance:

// no parent, inherits from Objectvar A = dojo.declare(null, {});var a = new A();

// single inheritancevar B = dojo.declare(A, {});var b = new B();

a instanceof A; // trueb instanceof A; // trueb instanceof B; // true

29

Page 30: Dojo for programmers (TXJS 2010)

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

Page 31: Dojo for programmers (TXJS 2010)

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

Page 32: Dojo for programmers (TXJS 2010)

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

Page 33: Dojo for programmers (TXJS 2010)

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

Page 34: Dojo for programmers (TXJS 2010)

How to reach me

• My web site: http://lazutkin.com

• Twitter: http://twitter.com/uhop

• Email: [email protected]

• Slides: http://www.slideshare.net/elazutkin

34

Page 35: Dojo for programmers (TXJS 2010)

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

Page 36: Dojo for programmers (TXJS 2010)

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

Page 37: Dojo for programmers (TXJS 2010)

That’s all for now!

37