Dojo: The Definitive Guide

Conventions Used in This Book

The following typographical conventions are used in this book:

Plain text

Indicates menu titles, menu options, menu buttons, and keyboard accelerators (such as Alt and Ctrl).

Italic

Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities.

Constant width

Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, or the output from commands.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values.

Tip

This icon signifies a tip, suggestion, or general note.

Warning

This icon indicates a warning or caution.

Style Conventions

Two additional conventions should also be noted as they relate to effectively communicating the meaning of content:

Qualifying references

Fully qualified namespaces are generally not used when the context is obvious. For example, if a code listing just introduced a dijit.form.Button widget, then the following discussion might opt to simply refer to the widget as Button.

Some terms such as constructor may be used in multiple ways within the same paragraph or context. Whenever this happens, the constant width font is used to differentiate whenever possible. For example, the sentence, "You create a widget by invoking an ordinary JavaScript constructor function, but a widget also has a special lifecycle method called constructor that can be used to perform initialization tasks" attempts to de-conflict the meaning of the term "constructor" by applying the constant width font.

API listings

In general, this book strives to provide standalone API listings by using a convention that relates the types of parameters by standardized constructor function names. For example, consider a function that would be invoked along the lines of loadUpArray("foo", 4) and return back ["foo", "foo", "foo", "foo"]. The API listing would be related as follows:

loadUpArray(/*String*/ value, /*Integer*/ length) //returns Array

Because JavaScript is a very dynamic, weakly typed language, however, there are some situations in which a parameter or value returned from a function could be any possible value. In these cases, the convention Any will be used to relate this feature. Whenever a parameter is optional, a question mark follows its type, like so: /*Integer?*/.

If you end up browsing Dojo source code, you may notice that some of the parameter names in the source code differ from the names the API listings use in this book. Because JavaScript function parameters are unnamed and positional, their actual names so far as an API listing is inconsequential; this language characteristic was leveraged to relate API listings in the most intuitive manner. As much care as possible was taken to provide API listings in the most uniform way possible, but there are bound to be small deviations occasionally.