dojo/ spelling

dojo/DeferredList.rst

@@ -11,7 +11,7 @@ dojo.DeferredList
 
 :ref:`dojo.Deferred <dojo/Deferred>` objects make asynchronous programming as easy as can be reasonably expected. The :ref:`dojo.DeferredList <dojo/DeferredList>` class builds on the "one answer to one question" contract of :ref:`dojo.Deferred <dojo/Deferred>` to provide a "one answer to many questions" system. Lets look at some cases when you might need such a thing:
 
-One common taks is notifying some listener when a list of resources pulled in by different services all become available. For example, a search federated across several bookstores. Hearing about the results of a single search is a good job for a :ref:`Deferred <dojo/Deferred>`, but finding out about when they've all completed takes more juggling.
+One common task is notifying some listener when a list of resources pulled in by different services all become available. For example, a search federated across several bookstores. Hearing about the results of a single search is a good job for a :ref:`Deferred <dojo/Deferred>`, but finding out about when they've all completed takes more juggling.
 
 Lets assume we've installed several proxies for search services on our server. Once all the stores have been searched, we want to send an xhr call with search status to some logging service and provide the user an indication that we've finished up all the work we were doing on their behalf.
 
@@ -113,4 +113,4 @@ To make the above example "live", you only need to note that calls to :ref:`dojo
       });
     }
 
-Dojo makes these patterns easy to work with, reducing the pain of asynchronous programming by using the `Deferred` pattern ubiquitiously.
+Dojo makes these patterns easy to work with, reducing the pain of asynchronous programming by using the `Deferred` pattern ubiquitously.

dojo/NodeList-manipulate.rst

@@ -194,7 +194,7 @@ Assume a DOM created by this markup:
 
 val
 --------------------
-If a value is passed, allows seting the value property of form elements in this
+If a value is passed, allows setting the value property of form elements in this
 NodeList, or properly selecting/checking the right value for radio/checkbox/select
 elements. If no value is passed, the value of the first node in this NodeList
 is returned.

dojo/NodeList.rst

@@ -132,7 +132,7 @@ The `entire NodeList API <http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.NodeLi
       node.innerHTML += " - found";
   });
 
-The syntax is the same as :ref:`dojo.forEach <dojo/forEach>` except that the first parameter (the array) is implicitly provided. This pattern is repeated throught the ``dojo.NodeList`` API.
+The syntax is the same as :ref:`dojo.forEach <dojo/forEach>` except that the first parameter (the array) is implicitly provided. This pattern is repeated throughout the ``dojo.NodeList`` API.
 
 For instance, :ref:`dojo.style() <dojo/style>` styles a single Node around a defined API. That API is mapped into ``NodeList``, dropping the node parameter and calling ``dojo.style`` on each node in the list:
 
@@ -370,7 +370,7 @@ To keep the Base size to a minimum, some NodeList functionality is provided by e
     dojo.query(".readyToFade").fadeIn().play();
   });
 
-The NodeList animations do *not* return the NodeList instance. Instead, they return the created ``Animation`` object, which you have to explictly call ``.play()`` on.
+The NodeList animations do *not* return the NodeList instance. Instead, they return the created ``Animation`` object, which you have to explicitly call ``.play()`` on.
 
 Additional Extensions
 ---------------------

dojo/_base/connect.rst

@@ -44,4 +44,4 @@ Features
 
 * :ref:`dojo.connectPublisher <dojo/connectPublisher>`
 
-  Ensure that everytime an event is called, a message is published on the topic.
+  Ensure that every time an event is called, a message is published on the topic.

dojo/addOnLoad.rst

@@ -68,7 +68,7 @@ conveniently replaces the one above. When the function is small, you may prefer
         document.musicPrefs.other.value="Afrobeat";
     });
 
-This is the function literal or anonymous function construct of JavaScript. If it looks really, really wierd to you, take a peek ahead at Functions as Variables for an explanation.
+This is the function literal or anonymous function construct of JavaScript. If it looks really, really weird to you, take a peek ahead at Functions as Variables for an explanation.
 
 Another use is "embedded onLoad". We'll define an addOnLoad function (anonymous), and within that function will load more components, registering a second addOnLoad function. The first will execute very quickly (assuming you are only loading dojo.js), and the second will wait until the package dependencies are complete:
 

dojo/build/exclude.rst

@@ -3,6 +3,6 @@
 Dojo build system:  conditional exclusions
 ==========================================
 
-TODOC:  Delete this page, I created it in the wrong part of the heirarchy.  Replacement build/exclude
+TODOC:  Delete this page, I created it in the wrong part of the hierarchy.  Replacement build/exclude
 
 :ref:`replacement page <build/exclude>`

dojo/byId.rst

@@ -138,7 +138,7 @@ Examples
 Fade-out a node
 ---------------
 
-The following example lets a node by id dissapear from the screen
+The following example lets a node by id disappear from the screen
 
 .. code-example ::
 

dojo/config.rst

@@ -208,7 +208,7 @@ This creates a `new` configuration parameter named ``myCustomVariable``. To use
     declare("my.Thinger", null, {
       thingerColor: (config.myCustomVariable ? "wasTrue" : "wasFalse"),
       constructor: function(){
-         if(config.myCustomVaraible){ ... }
+         if(config.myCustomVariable){ ... }
       }
     });
   });
@@ -217,7 +217,7 @@ This creates a `new` configuration parameter named ``myCustomVariable``. To use
   dojo.declare("my.Thinger", null, {
       thingerColor: (dojo.config.myCustomVariable ? "wasTrue" : "wasFalse"),
       constructor: function(){
-         if(dojo.config.myCustomVaraible){ ... }
+         if(dojo.config.myCustomVariable){ ... }
       }
   });
 

dojo/connect.rst

@@ -23,13 +23,13 @@ Introduction
 
 `dojo.connect` is the core event handling and delegation method in Dojo. It allows one function to "listen in" on the execution of any other, triggering the second whenever the first is called. Many listeners may be attached to a function, and source functions may be either regular function calls or DOM events.
 
-`dojo.connect` connects listeners to actions, so that after event fires, a listener is called with the same arguments passed to the orginal function.
+`dojo.connect` connects listeners to actions, so that after event fires, a listener is called with the same arguments passed to the original function.
 
 Since `dojo.connect` allows the source of events to be either a "regular" JavaScript function or a DOM event, it provides a uniform interface for listening to all the types of events that an application is likely to deal with though a single, unified interface. DOM programmers may want to think of it as "addEventListener for everything and anything".
 
-When setting up a connection, the `event` parameter must be a string that is the name of the method/event to be listened for. If `obj` is null, `dojo.global` is assumed, meaning that connections to global methods are supported but also that you may inadvertantly connect to a global by passing an incorrect object name or invalid reference.
+When setting up a connection, the `event` parameter must be a string that is the name of the method/event to be listened for. If `obj` is null, `dojo.global` is assumed, meaning that connections to global methods are supported but also that you may inadvertently connect to a global by passing an incorrect object name or invalid reference.
 
-`dojo.connect` generally is forgiving. If you pass the name of a function or method that does not yet exist on `obj`, connect will not fail, but will instead set up a stub method. Similarly, null arguments may simply be omitted such that fewer than 4 arguments may be required to set up a connection See the examples for deails.
+`dojo.connect` generally is forgiving. If you pass the name of a function or method that does not yet exist on `obj`, connect will not fail, but will instead set up a stub method. Similarly, null arguments may simply be omitted such that fewer than 4 arguments may be required to set up a connection See the examples for details.
 
 The return value is a handle that is needed to remove this connection with `dojo.disconnect`.
 

dojo/connectPublisher.rst

@@ -9,7 +9,7 @@ dojo.connectPublisher
 .. contents::
    :depth: 2
 
-Ensure that everytime an event is called, a message is published on the topic.
+Ensure that every time an event is called, a message is published on the topic.
 
 
 ============

dojo/contentHandlers.rst

@@ -257,7 +257,7 @@ The other contentHandlers are all functions. If you like, you can define a new h
 Overwriting a handler
 ---------------------
 
-Standard AOP techniques apply. If you find yourself needing to *replace* a contentHandler but preserve the original beahvior, simply duck-punch around it:
+Standard AOP techniques apply. If you find yourself needing to *replace* a contentHandler but preserve the original behavior, simply duck-punch around it:
 
 [ Dojo 1.7 AMD ]
 
@@ -267,7 +267,7 @@ Standard AOP techniques apply. If you find yourself needing to *replace* a conte
         // a handler that always escapes html fragments. not exceptionally useful though:
         var oldtext = xhr.contentHandlers.text;
         xhr.contentHandles.text = function(req){
-            return oldtext.apply(this, arguments).reaplce("<", "&lt;");
+            return oldtext.apply(this, arguments).replace("<", "&lt;");
         };
     });
 
@@ -279,7 +279,7 @@ Standard AOP techniques apply. If you find yourself needing to *replace* a conte
     // a handler that always escapes html fragments. not exceptionally useful though:
     var oldtext = dojo.contentHandlers.text;
     dojo.contentHandles.text = function(xhr){
-        return oldtext.apply(this, arguments).reaplce("<", "&lt;");
+        return oldtext.apply(this, arguments).replace("<", "&lt;");
     };
 
 

dojo/cookie.rst

@@ -53,7 +53,7 @@ Set a cookie by clicking on the button, reload the page and click the "Get Cooki
     dojo.require("dojo.cookie");
 
     setCookie = function(){
-      dojo.cookie("favouriteDish", "Nudels", {expires: 5});
+      dojo.cookie("favouriteDish", "Noodles", {expires: 5});
     };
 
     getCookie = function(){

dojo/coords.rst

@@ -18,7 +18,7 @@ Getter for the complete coordinates of a dom node.
 Introduction
 ============
 
-The dojo coords function is used to obtain a plethora of coordinate information about a dom node.  The type of information it returns is relative positin to its parent in the form of 'left' and 'top' values, the width and height of the dom node, and absolute position in the form of page x and y coordinates.  Effectively, it is a combination of margin box values :ref:`dojo.marginBox <dojo/marginBox>` and :ref:`dojo.position <dojo/position>`.  Because of this redundancy and because the return attributes use differing box-types, this method is being deprecated beginning with Dojo 1.4 but is being kept active for backward compatibility.  The return object looks like:
+The dojo coords function is used to obtain a plethora of coordinate information about a dom node.  The type of information it returns is relative position to its parent in the form of 'left' and 'top' values, the width and height of the dom node, and absolute position in the form of page x and y coordinates.  Effectively, it is a combination of margin box values :ref:`dojo.marginBox <dojo/marginBox>` and :ref:`dojo.position <dojo/position>`.  Because of this redundancy and because the return attributes use differing box-types, this method is being deprecated beginning with Dojo 1.4 but is being kept active for backward compatibility.  The return object looks like:
 
 { l: 50, t: 200, w: 300: h: 150, x: 700, y: 900, }
 

dojo/data/ItemFileReadStore.rst

@@ -89,7 +89,7 @@ Constructor Parameters
 Input Data Format
 =================
 
-While the data exposed from a data store is agnostic and consumable by many sources in an usually interchangable way, the input data formats of a data store may vary. The ItemFileReadStore expects a specific structure to its data, as defined below:
+While the data exposed from a data store is agnostic and consumable by many sources in an usually interchangeable way, the input data formats of a data store may vary. The ItemFileReadStore expects a specific structure to its data, as defined below:
 
 General Structure
 -----------------
@@ -291,7 +291,7 @@ Items with Custom Types
 Custom Types
 ============
 
-As mentioned in the Item Structure section, custom types are possible to create and use as values of attributes with this store. The caveat is, you have to tell the store, through a typeMap object, how to deserialize the cutom type value back into its object form. This is not as difficult as it first may sound. Below is the general structure information for creating a custom type map. There is a general format for all cases, and a compact format when the value can be directly used as a constructor argument.
+As mentioned in the Item Structure section, custom types are possible to create and use as values of attributes with this store. The caveat is, you have to tell the store, through a typeMap object, how to deserialize the custom type value back into its object form. This is not as difficult as it first may sound. Below is the general structure information for creating a custom type map. There is a general format for all cases, and a compact format when the value can be directly used as a constructor argument.
 
 **Note:** You can mix simplified form type maps with general case type maps in the same type map object. Therefore, you can use whatever is the easiest representation required to handle the custom object construction.
 

dojo/data/ItemFileWriteStore.rst

@@ -70,7 +70,7 @@ The query syntax for ItemFileWriteStore is identical to the query syntax of Item
 The Write API
 =============
 
-The write API implementation conforms to the dojo.data specification for Write. Ultimately, the best way to think about it is that you use functions *newItem*, *deleteItem*, *setValue(s)*, and *unsetAttribute* to modify contents of the store. These changes can be undone all in one function call by calling the store *revert* function, or they can be committed and made unreversable by the *save* function. Think of it as semi-transactional.
+The write API implementation conforms to the dojo.data specification for Write. Ultimately, the best way to think about it is that you use functions *newItem*, *deleteItem*, *setValue(s)*, and *unsetAttribute* to modify contents of the store. These changes can be undone all in one function call by calling the store *revert* function, or they can be committed and made unreversible by the *save* function. Think of it as semi-transactional.
 
 newItem(), deleteItem, save() and identities
 --------------------------------------------

dojo/data/api.Read.rst

@@ -6,7 +6,7 @@ dojo.data.api.Read
 The most fundamental API of dojo.data is the Read API. All stores will implement this API because all stores need the ability to retrieve and process data items. The Read API is designed to be extremely flexible in how items are handled. The Read API provides the ability to:
 
 * Introspect any datastore to determine the APIs the datastore implements through the getFeatures() call.
-* Instrospect, On an item by item basis, what attributes each item has in a way that is agnostic to the data format.
+* Introspect, on an item by item basis, what attributes each item has in a way that is agnostic to the data format.
 * Get values of attributes in a way that is agnostic to the data format.
 * Test attributes of items to see if they contain a specific value.
 * Test any JavaScript object to see if it is an item from the store.
@@ -293,7 +293,7 @@ For convenience, the complete Read Feature is defined below.
     //        an attribute named attrFoo, with a value that starts with 'value'.
     //
     //    The *queryOptions* parameter
-    //        The queryOptions parameter is an optional parameter used to specify optiosn that may modify
+    //        The queryOptions parameter is an optional parameter used to specify options that may modify
     //        the query in some fashion, such as doing a case insensitive search, or doing a deep search
     //        where all items in a hierarchical representation of data are scanned instead of just the root
     //        items.  It currently defines two options that all datastores should attempt to honor if possible:
@@ -350,7 +350,7 @@ For convenience, the complete Read Feature is defined below.
     //    The *start* parameter.
     //        If a start parameter is specified, this is a indication to the datastore to
     //        only start returning items once the start number of items have been located and
-    //        skipped.  When this parameter is paired withh 'count', the store should be able
+    //        skipped.  When this parameter is paired with 'count', the store should be able
     //        to page across queries with millions of hits by only returning subsets of the
     //        hits for each query
     //
@@ -405,7 +405,7 @@ For convenience, the complete Read Feature is defined below.
     //    description:
     //        The close() method is intended for instructing the store to 'close' out
     //        any information associated with a particular request.  In general, this API
-    //        expects to recieve as a parameter a request object returned from a fetch.
+    //        expects to receive as a parameter a request object returned from a fetch.
     //        It will then close out anything associated with that request, such as
     //        clearing any internal datastore caches and closing any 'open' connections.
     //        For some store implementations, this call may be a no-op.
@@ -426,7 +426,7 @@ For convenience, the complete Read Feature is defined below.
     //        that provides a general/adequate description of what the item is.  In general
     //        most labels will be a specific attribute value or collection of the attribute
     //        values that combine to label the item in some manner.  For example for an item
-    //        that represents a person it may return the label as:  "firstname lastlame" where
+    //        that represents a person it may return the label as:  "firstname lastname" where
     //        the firstname and lastname are attributes on the item.  If the store is unable
     //        to determine an adequate human readable label, it should return undefined.  Users that wish
     //        to customize how a store instance labels items should replace the getLabel() function on
@@ -448,7 +448,7 @@ For convenience, the complete Read Feature is defined below.
     //        Method to inspect the item and return an array of what attributes of the item were used
     //        to generate its label, if any.  This function is to assist UI developers in knowing what
     //        attributes can be ignored out of the attributes an item has when displaying it, in cases
-    //        where the UI is using the label as an overall identifer should they wish to hide
+    //        where the UI is using the label as an overall identifier should they wish to hide
     //        redundant information.
     //
     //    item:

dojo/data/api.rst

@@ -7,7 +7,7 @@ dojo.data.api
   :depth: 3
 
 
-Before diving directly into the APIs of dojo.data, the basic concepts behind the APIs need to be explored because some design descisions that were made might seem odd without an explanation as to why they were chosen. Therefore, read this page in its entirety before moving onto the individual APIs.
+Before diving directly into the APIs of dojo.data, the basic concepts behind the APIs need to be explored because some design decisions that were made might seem odd without an explanation as to why they were chosen. Therefore, read this page in its entirety before moving onto the individual APIs.
 
 ========================================================
 Concept 1: Data access is broken down into separate APIs