The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
|
2.5.2
Chapter 2 Section 5.2, Eamples 2-4 and 2-5 |
Both examples say:
<title>Fun With Fibonacci!title>
(missing closing 'less than' character)
should be:
<title>Fun With Fibonacci!<title>
ALSO
Both examples say:
dojo.body( ).innerHTML = "guess what? fibonacci(5) = ",
dtdg.foo.fibonacci(5);
(but this doesn't seem to work, because the ',' probably was meant to be a '+')
This worked for me:
dojo.body( ).innerHTML = "guess what? fibonacci(5) = " + dtdg.foo.fibonacci(5);
Both in the Safari Books Online and the example source code.
Note from the Author or Editor:
On pages 43 and 45, the title tag is indeed missing an opening angle bracket on the closing tag.
Also, it is true that the command should be a plus sign in the two code examples on pages 43 and 45 as the reader points out. One of these was reported in a previous errata submission, but |
Anonymous |
Oct 02, 2008 |
Oct 01, 2008 |
| Printed |
Page 22
last paragraph on the page |
The last paragraph is repeated. "When you execute the bookmark ... for some helpful details." is printed twice.
|
Anonymous |
|
|
| Printed |
Page 22
last paragraph |
Text of paragraph is repeated, so the entire paragraph appears twice.
|
Anonymous |
Jun 27, 2008 |
Oct 01, 2008 |
| Printed |
Page 22
last paragraph on the page |
The last paragraph is repeated. "When you execute the bookmark ... for some helpful details." is printed twice.
|
Anonymous |
Jul 02, 2008 |
Oct 01, 2008 |
| Printed |
Page 23
Example 1.3, near the end, div Id="foo" |
Missing closing bracket for div id="foo"
|
Anonymous |
|
|
| Printed |
Page 23
Example 1-3 |
HTML syntax errors and other errors:
<div id="d4"> A div with id=d3 (should it be "with id=d4"?)
"This sentence is in a span that's contained in d1."
(The span is actually in d4, not d1.)
<div id="foo"
A div with id=foo
</div>
(Needs > after id="foo")
Note from the Author or Editor:
I've fixed the last errata by adding in a closing bracket, but am waiting author's response to the other errata in this submission.
Scott De Lugan
U.S. Reprints and Digital Content Coordinator
O'Reilly Media, Inc.
The issues pointed out are all valid. There is a missing closing angle bracket on the div tag and the innerHTML values provided in the div tags in the body of the page are mislabeled. |
Anonymous |
Jun 27, 2008 |
Oct 01, 2008 |
| Printed |
Page 23
Example 1.3, near the end, div Id="foo" |
Missing closing bracket for div id="foo"
|
Anonymous |
Jul 02, 2008 |
Oct 01, 2008 |
| Printed |
Page 28
Example 1-4 |
Second <head> tag should be closing tag: </head>
|
Anonymous |
|
|
| Printed |
Page 28
Example 1-4 |
Second <head> tag should be closing tag: </head>
Same for example 1-5 on page 30, nine lines in: <head> should be </head>
|
Anonymous |
Jul 03, 2008 |
Oct 01, 2008 |
| Printed |
Page 30
Example 1-5 on page 30, nine lines in: <head> should be </head> |
|
Anonymous |
|
|
| Printed |
Page 35
first code sample |
Of the three dojo.string.substitute() calls, the comment on the second one should actually be moved to the third one (which doesn't have a comment) and be replaced by a copy of the comment on the first one.
Note from the Author or Editor:
Correct. Details provided in a duplicate that I just confirmed. |
Anonymous |
Aug 21, 2008 |
Oct 01, 2008 |
| Printed |
Page 35
1 line |
The comment "// *Jack* ..." applies to the third substitute example,
but is printed before the second one ( which prints "// Jack ..." like the first example
Note from the Author or Editor:
The second comment '"//*Jack* and *Jill* went up a hill."' should be moved down to the last example. The hole left by moving this comment should simply be a cut/paste of the first comment '"Jack and Jill went up a hill."' so that the first comment appears twice.
In the end, there should be three examples. The first two of them show the same output but via different techniques. The third example shows different output in which the proper nouns in the sentence are surrounded by asterisks. |
Anonymous |
Aug 29, 2008 |
Oct 01, 2008 |
| Printed |
Page 37
First paragraph of "Iterating Over Elements" |
Should read "The forEach function passes each element of an array into a function that takes one, two or three parameters...".
Last example on page illustrates function taking 2 parameters.
Should explain that first parameter is the element of the array, second (optional) parameter is the index within the array of that element, and third (optional) parameter is the array itself.
Note from the Author or Editor:
Let's fix this thusly:
* Change the first paragraph of the "Iterating Over Elements" section to read:
"The forEach function passes each element of the array into a function that takes up to three parameters and does not return any value at all. The first parameter is the current element of the array being iterated over, the second (optional) parameter is the index of the current element within the array, and the third (optional) parameter is the entire array itself. The forEach function is generally used to iterate over each element of an array as an ordinary for loop. Here's the signature:"
And that should do it. |
Anonymous |
Jun 27, 2008 |
Oct 01, 2008 |
| Printed |
Page 43
Example 2-4 |
Concatenation operator in
dojo.body().innerHTML = "guess what? fibonnacci(5) = ", dtdg.foo.fibonacci(5);
should be "+" not ","
|
Anonymous |
Jul 30, 2008 |
Oct 01, 2008 |
| Printed |
Page 44
last paragraph on the page |
"... so that no reference to baseUrl or or a call to registerModulePath ..."
should be
"... so that no reference to baseURL or call to registerModulePath ..."
|
Anonymous |
Jul 03, 2008 |
Oct 01, 2008 |
| Printed |
Page 60
3rd para, starting with Dojo attempts to normalize |
by exposing the dojo.marginBox attribute, which can take on a value of 'content-box' or 'margin-box' ...
should be
by exposing the dojo.boxModel attribute, which can take on a value
Note from the Author or Editor:
Correct the value "dojo.marginBox" in the first sentence of the second full paragraph should be "dojo.boxModel" |
Anonymous |
Jul 11, 2008 |
Oct 01, 2008 |
| Printed |
Page 77
last line on the page |
foot.talk() should be foo.greet()
|
Anonymous |
Jul 03, 2008 |
Oct 01, 2008 |
| Printed |
Page 77
first code sample |
Change "/*String*/topic, *Object|null*/context," to "/*String*/topic, /*Object|null*/context," (missing forward slash in second comment).
|
Anonymous |
Aug 22, 2008 |
Oct 01, 2008 |
| Printed |
Page 86
1st line |
Code example does not work in dojo 1.1.1
Book has:
handleAs : "json",
Should be:
handleAs : "json-comment-filtered",
The funny part is that on the very same page the author states "Do note that not specifying a proper value for handleAs can produce frustrating bugs that may not immediately be apparent", and this is just what happened... a frustrating bug caused by the wrong value specified for handleAs.
Note from the Author or Editor:
So, what happened is that the Ajax community decided that json-comment-filtered was a bad idea after all and at the last minute, I hastily updated this section (but only partially as it turns out.)
Here's what we do to fix this up on page 86:
* handleAs: "json" -- should stay the same
* Change the line below the handleAs (the second line on the page) that has the comment "//Strip the comments and eval to a JavaScript object" to read "//Deserialize into a JavaScript object"
* Back on page 85 in the bottommost code example, change the last line to read: "//Returns something like: {'bar':'baz'}" -- where we remove the /* and */ tokens from that line.
The point is that the example doesn't use json-comment-filtered anymore since json-comment-filtered isn't a good practice. Intead it just uses plain old JSON. |
Anonymous |
Jul 07, 2008 |
Oct 01, 2008 |
| Printed |
Page 133
2/3 down after dojo.style... #eee" } |
Missing right paren after dojo.style function call. Also missing in the zip file of examples from the book. Should be background:"#eee"})},
(with right parenthesis between right braces)
Note from the Author or Editor:
Toward the middle of the code example, the dojo.style statement should read like this:
...
dojo.style(node, {
border : "solid 1px",
background : "#eee"
});
},
...
In other words there is a missing ");" after that lone curly brace. |
Anonymous |
Jul 11, 2008 |
Oct 01, 2008 |
| Printed |
Page 150
lines 23 and 27 (counting "Example 7-3..." as line 1 |
<div id="note1" dojoType="dojo.dnd.Moveable"> should be
<div id="note1" dojoType="dojo.dnd.Moveable" handle="dragHandle1"> so that you can click on the textarea without initiating a drag. Likewise for note2. See bottom of page 148.
Note from the Author or Editor:
Actually, the issue is different from what's being described. The change should be that the two DIV tags in the BODY tag of page 150 should be changed thusly:
<div id="note1" dojoType="dojo.dnd.Moveable"> -> <div id="note1">
<div id="note2" dojoType="dojo.dnd.Moveable"> -> <div id="note2">
In other words, the dojoType attribute in these tags is unnecessary since there is programmatic creation. The reader's initial comment about needing "dragHandle" provided actually happens in the programmatic creation step back on page 149, so that issue is actually fine. All that was really wrong here is that there was an extraneous dojoType tag that was confusing the reader. |
Anonymous |
Jul 14, 2008 |
|
| Printed |
Page 150
lines 23 and 27 (counting "Example 7-3..." as line 1 |
<div id="note1" dojoType="dojo.dnd.Moveable"> should be
<div id="note1" dojoType="dojo.dnd.Moveable" handle="dragHandle1"> so that you can click on the textarea without initiating a drag. Likewise for note2. See bottom of page 148.
Note from the Author or Editor:
Actually, the issue is different from what's being described. The change should be that the two DIV tags in the BODY tag of page 150 should be changed thusly:
< div id="note1" dojoType="dojo.dnd.Moveable" >
should be
< div id="note1" >
< div id="note2" dojoType="dojo.dnd.Moveable" >
should be
< div id="note2" >
In other words, the dojoType attribute in these tags is unnecessary since there is programmatic creation. The reader's initial comment about needing "dragHandle" provided actually happens in the programmatic creation step back on page 149, so that issue is actually fine. All that was really wrong here is that there was an extraneous dojoType tag that was confusing the reader. |
Anonymous |
Oct 06, 2008 |
Oct 01, 2008 |
| Printed |
Page 156
example code |
When running the code as it is written (copying from the book as well as downloaded from the samples on Safari), the CSS doesn't show up properly (i.e. as it is show in Figure 7-1). From looking at the code on p.161, it appears as if the <link> is missing that references "dojo/tests/dnd/dndDefault.css". When I added that to the code on p156, it looks fine.
Note from the Author or Editor:
Ok, I'm not sure I'd call this a *serious* technical mistake, but it is something that we need to fix. The problem is that it's a messy fix. The issue is that the dndDefault.css file that the reader references isn't available over AOL's CDN, so we can't just insert a new script tag and be done with it. What I suggest we do is two-fold:
* Add another link tag to the head of the page that is in bold (so that it stands out) and simply has an href="dndDefault.css".
* Add a warning below the code listing (doesn't look like it would necessarily affect more than this page and the next page's layout) that says "As of Dojo 1.1, The dndDefault.css file is not available over AOL's CDN, but is readily accessible in the dojo/tests/dnd folder of a source checkout. You'll need to reference it to get the nice style you see in Figure 7-1"
That should do it. |
Anonymous |
Aug 24, 2008 |
|
| Printed |
Page 197
gray box 1/2 of the way down |
repsonse should be response
|
Anonymous |
|
|
| Printed |
Page 197
gray box 1/2 of the way down |
repsonse should be response
|
Anonymous |
Jul 11, 2008 |
Oct 01, 2008 |
| Printed |
Page 199
right column of table, row for isItem |
"stable" should be "stale"
|
Anonymous |
Aug 22, 2008 |
Oct 01, 2008 |
| Printed |
Page 217
example 9-15 |
ItemFileReadStore should be ItemFileWriteStore in example of _saveCustom. (2 places)
|
Anonymous |
Jul 12, 2008 |
Oct 01, 2008 |
| Printed |
Page 227-228
example 10-5 |
"constructor(centerX, centerY, color)"
should be
constructor: function(centerX, centerY, color)
and again later in the same example.
This seems little but I spent some time trying to grok what this meant since it didn't fit into my JavaScript understanding at all, so I thought it was something new I hadn't seen.
Fortunately, later constructors (pp.230-231 etc) are correct.
Note from the Author or Editor:
On pages 227-228, the line "constructor(centerX, centerY, color)" should indeed be "constructor : function(centerX, centerY, color)".
However, this certainly isn't a "serious" technical mistake. I would personally consider it quite minor since an assumption is that the reader does have a JavaScript background and would (IMHO) pick up on the error somewhat quickly. |
Anonymous |
Jul 14, 2008 |
Oct 01, 2008 |
| Printed |
Page 230, 231
A Single Inheritance Example (code) |
(1) At bottom of page 230:
is: dojo.addOnLoad(function()
should be: dojo.addOnLoad(function() {
(2) In upper-half of page 231:
is:
//A common convention is to use a leading underscore to denote
"private" members
should be:
//A common convention is to use a leading underscore to denote
//"private" members
(3) In bottom-half of page 231:
is (on line by itself): this._owners);
should be (delete line):
The same error exists in on-line Safari edition.
Note from the Author or Editor:
All correct. |
Anonymous |
Aug 04, 2008 |
Oct 01, 2008 |
| Printed |
Page 246
3 bullet item, 3rd line |
'... and users who need cannot use a mouse', the word 'need' should be removed
|
Anonymous |
Sep 01, 2008 |
Oct 01, 2008 |
|
257
Example 11.2 code |
<button> declaration is:
<buttondojoType="blah blah"...
<button> declaration should be:
<button dojoType="blah blah"...
Note from the Author or Editor:
I can't read what the reported typo is supposed to be. It's not showing up. But I do notice that the closing HEAD tag is missing a forward slash, so I'll assume that was the reported errata, which is actually minor, not major. |
Anonymous |
Aug 05, 2008 |
|
| Printed |
Page 257
(Safari) Example 11.2 code |
<button> declaration is:
<buttondojoType="blah blah"...
<button> declaration should be:
<button dojoType="blah blah"...
|
Anonymous |
|
|
| Printed |
Page 279
last paragraph |
The text reads, "here's a simple code snippet with the corresponding Firebug console output". On the following page is the code snippet but no Firebug console output.
Note from the Author or Editor:
Ok, so in debugging this, there are a few issues that have come up between 1.1 and the imminent 1.2 release that need resolving:
* Let's change the text identified in this errata submission to just read "here's a simple code snippet that you could run to inspect these properties in the Firebug console"
* Change the sentence under the domNode section on page 279 from "you'll probably want to avoid direct manipulation of this property" to "you'll probably want to avoid direct manipulation of this property if using the _Templated mixin"
* Change last sentence under the "domNode" list item on page 279 from "If a dijit doesn't appear on screen, this value resolves to undefined" to "_Widget's default implementation of buildRendering sets domNode to either the value of srcNodeRef (if provided) or an empty DIV element"
* Add a list item above the domNode section that is called "srcNodeRef" that reads:
srcNodeRef - If provided, this value populates the widget's domNode with the contents of the srcNodeRef and sets the domNode's id value to the id of the srcNodeRef
* Dojo 1.2 introduce a new method called placeAt that would ideally be introduced in the previous section. If we can also include it in the update, then I'd really like to do so. It would take up roughly the same area on the page as the other items in that list. |
Anonymous |
Sep 08, 2008 |
Oct 01, 2008 |
| Printed |
Page 289
2nd paragraph |
given the tag in the html-page
<div foo="bar" baz="quux" dojoType="dtdg.HelloWorld"></div>
and declaring the variables in the js file
foo : "",
baz : ""
the console.log()-message called in the constructor reveals that the values vor foo and baz stay empty strings and are not received as parameters set in the <div/>-tag.
have there any changes been made from dojo 1.1 to the current version that change the way parameters can be used in dijit?
Note from the Author or Editor:
For the code listing you point out (Example 12-5), change the overloaded constructor function to postMixInProperties and you should see that "foo" is properly populated. What you should be seeing if you run the code with constructor left in place to do the console logging is that "foo" and "baz" stay as empty strings (as opposed to being undefined) because when constructor fires, no mixing in has happened yet. |
Anonymous |
May 02, 2009 |
|
| Printed |
Page 294
example |
the Declaration-version of the HelloWorld-sample doesn't quite work as its counterpart, because the scope of
dojo.addClass(this.domNode, 'hello_class');
dojo.removeClass(this.domNode, 'hello_class');
is the containing div-element and not the template's span. is there a way to set the scope for this, so that you don't have to rewrite those values when refactoring the custom dijit?
Note from the Author or Editor:
You are right. Try using this as the markup instead. It just provides a hook to the span with a dojoAttachPoint and then references the span directly via the dojoAttachPoint:
<div
dojoType="dijit.Declaration"
widgetClass="dtdg.HelloWorld"
defaults="{greeting:'Hello World'}">
<span dojoAttachPoint="greetingMsg"
dojoAttachEvent='onmouseover:onMouseOver, onmouseout:onMouseOut'>
${greeting}
</span>
<script type="dojo/method" event="onMouseOver" args="evt">
dojo.addClass(this.greetingMsg, 'hello_class');
console.log("applied hello_class...");
console.log(evt);
</script>
<script type="dojo/method" event="onMouseOut" args="evt">
dojo.removeClass(this.greetingMsg, 'hello_class');
console.log("removed hello_class...");
console.log(evt);
</script>
</div>
|
Anonymous |
May 02, 2009 |
|
| Printed |
Page 300
3rd bullet point |
The sentence
"If no action attribute is provided, custom JavaScript or DHTML actions could be taken by attaching scripts to DOM events such as *onlick*"
should read:
"If no action attribute is provided, custom JavaScript or DHTML actions could be taken by attaching scripts to DOM events such as *onclick*"
|
Anonymous |
|
|
| Printed |
Page 300
3rd bullet point |
The sentence
"If no action attribute is provided, custom JavaScript or DHTML actions could be taken by attaching scripts to DOM events such as *onlick*"
should read:
"If no action attribute is provided, custom JavaScript or DHTML actions could be taken by attaching scripts to DOM events such as *onclick*"
|
Anonymous |
Jul 17, 2008 |
Oct 01, 2008 |
| Printed |
Page 356
bottom half |
In the example there are two elements created for each accordion pane, a div with the title, and a p with the content. When we go to wire up the accordion into the DOM, I see how they work the content items in to the dijit with addChild, but the title divs are just hanging out there and don't get hooked into anything. I experimented by just commenting all the
var childn = dojo.doc.createElement("div");
childn.innerHTML="whatever";
and the accordion worked just the same as the one that I made in markup.
Note from the Author or Editor:
I believe this is a minor mistake, personally, but the reader is correct in identifying that there are 4 lines of code that are frivilous, and thus, possibly confusing. Please strike the following 4 lines (which appear in two groups of two lines each) from Example 14-9 entirely. The code works the very same without them.
var child1 = dojo.doc.createElement("div");
child1.innerHTML = "pane 1";
var child2 = dojo.doc.createElement("div");
child2.innerHTML = "pane 2";
I won't open up another ticket for it, but just above this code listing, there is also a very minor grammar issue: "difference to creation pattern" should be "difference to the creation pattern" |
Anonymous |
Sep 30, 2008 |
Oct 01, 2008 |
| Printed |
Page 362
Table 15-2. Dialog API.. |
In the Dialog API there is a method "diration()" mentioned to hide the dialog. But it seems to be that the method ist called "hide()" instead.
Note from the Author or Editor:
Correct. The third row, first column of table 15-2 should be hide() instead of duration() |
Anonymous |
Oct 04, 2008 |
Oct 01, 2008 |
| Printed |
Page 365
trap box near bottom |
setInterval "executes a function according to a set interval" isn't too helpful.
Instead, perhaps, "executes a function repeatedly every time interval, while setTimeout executes a function just once, after a specified amount of time."
Note from the Author or Editor:
Fair enough. |
Anonymous |
Jul 14, 2008 |
Oct 01, 2008 |
| Printed |
Page 373
Table 15-6 "Menu-API", 5th to 7th row |
The word "Toolbar" should be replaced by the word "Menu" because this table refers to the "Menu-API".
|
Anonymous |
Oct 03, 2008 |
Oct 01, 2008 |
| Printed |
Page 382
bold section of code block |
console.log("onClick:",dataStore.getLabel(item);
should be
console.log("onClick:",dataStore.getLabel(item));
Note from the Author or Editor:
Correct. There is a missing parenthesis at the end of the statement. |
Anonymous |
Oct 01, 2008 |
Oct 01, 2008 |