Historical errata for Mastering Dojo

The second footnote ends in nothingness - maybe it’s just a cross reference missing, but who can be sure? So I’m reporting it none the less.

in the code for the first content pane, the form fields for last name and middle initial are missing. Also, the

First sentence has a typo. Instead of “Here, it looks like whetever…” it should say “here, it looks like whAtever…”

The code on page 32 contains a reference to a means of showing some kind of password change dialog:

this is not explained in the rest of the chapter. While I see that this would never fit into the scope of an introduction like this, why not either remove this part from the exapmple or notify the reader that it’ll be explained later on?

the first paragraph compares object literals to hashes in PHP and Perl. In PHP though, hashes are in face called associative array - mostly just array though. The term hash is very much Perl specific.

The second bullet point describing JSON states that

“The only items on the right-hand side of the “:” are quoted strings, numbers, the boolean constants true and false, and the constant null. No expressions beyond those are allowed."

this is not correct. Array- and Object literals both are permitted too, allowing to build nested structures of objects and arrays which is very useful.

is figure 3.2 well-placed right in the middle of the code sample? IMHO it would make more sense to show it at the end of the sample not to destroy the flow of the code.

See my comments under discussion. The code for Chapter 2 does not work.

Drop all the references to web servers. Most people will be doing this locally at first ans since the Javascript interpreter is in the browser there is no need for a web server. The only thing required is a reference to wherever you put Dojo.

You refer to Fred Brooks Mythical Man_Month as an “engineering tomb”, but should probably read “engineering tome”

In the Form Layout Example in this chapter the section of the form designated for the first tab is incomplete. There is only the label for the first name field. No other labels or fields and this section has no closing div tag. The last section has two closing div tags. Also as far as I can tell there is nothing in this sample to format the input fields and labels as they show up in the picture. They are all just left justified.

The variable resultUI is never declared, and presumably ought to be the argument oneResult.

A better argument/var name might be “list” or “listNode”, given the function name “createListItem”.

(A better function name than “createListItem” might be “appendNewListItem”: “create” is very ambiguous, it could mean “create but do not attach/insert/append” or “create and insert”, etc etc, when in fact the function only creates and appends.)

Describing JSON in the second of two bullet points, you say the right-hand side of a “:” can only contain quoted strings, numbers, booleans, and null.

Of course this isn’t true: you can have objects in {} and arrays in [] as well, as you do on the very next page’s snippet.

I think the book ought to be upfront about some of Dojo’s flaws in this section. Specifically, I think this statement is misleading: “It seems to surprise the least… to be natural.”

Here are some examples of how Dojo is anything but natural, and very surprising indeed.

1. All I want to do is assign one of Dojo’s hard-coded colors in stye attribute. In other words, in Javascript I want to know what to type on the right-hand side of the Javascript statement:

myNode.style.backgroundColor = …

Here’s what you have to do:

myNode.style.backgroundColor = dojo.colorFromArray(dojo.Color.named.orange).toCss(false);

It’s a stretch to describe that as natural or not a surprise; it’s unguessable.

2. Because of inconsistencies in naming, there’s no way to know how to reference events declaratively without wading deep into the source code, often through multiple hierarchies of inheritance. For a full description of the problem see this link:

www.dojotoolkit.org/forum/dijit-dijit-0-9/dijit-development-discussion/why-inconsistency-access-dijit-event-methods#comment-12200

Dojo has many virtues, but to be fair to the reader, I think these problems ought to be mentioned. Dojo isn’t perfect, and it would be best to let the readers know where some of these imperfections lie.

I think a picture is needed on this page to clarify all the different types of rows, especially for the following paragraph:

Working outwards in our code, the inner most array of cells is called
a subrow, or physical row. In Grid, you can wrap a record’s data over
more than one subrow. These subrows bind together in a row, also
called a logical row. Logical rows are selectable as a unit. This is a nice
way to fold data into a narrow vertical space, so the user doesn’t have
to scroll left and right.

The second sentence tells what Grid can do with a subrow, but we still haven’t been told what it is (or why it can be called physical). In the third sentence, we get a new concept, logical row — but we still don’t know what a subrow actually is. There’s too much information too fast.

A diagram showing a grid, with the various kinds of rows pointed out in it, could help a lot here.

The snippet on this page contains type=“dojo/connect”.

However, the paragraph immediately following refers only to type=“dojo/method”.

(It also doesn’t seem like a good idea to mention the Parser at this point: it hasn’t been introduced or described, doesn’t seem essential to understand how to wire together the declarative code at this point, and so is likely to confuse the reader.)

At 3.4, a graphic showing what we are ultimately trying to build would be helpful.

As the text stands, the reader is left wondering:

- where is this link for cigar info to be displayed?

- where are the results to be displayed - on a new page, in a “subrow” (how is that different from a row?), what?
- is “hyperlinks relevant to the cigar name” just a long (and optimistic) way of saying "yahoo search on the cigar’s name?

All this questions could be answered by showing Fig 3.6 here (preferably showing a whole screen, not just a screen clip). Instead, that figure doesn’t appear until 6 pages later.

In the first paragraph of 3.5, it might be helpful to clarify how the reviews are displayed, rather than just state that they will be.

One solution is to change the last sentence:

“… in a list that will be displayed directly under the clicked cigar’s row. Clicking anywhere in the review list would hide it again.”

resultUl is undefined, and confusing again on this page.

A search of the pdf shows that the variable resultUl is never defined; it first makes an appearance on page 39 as a javascript var.

The name suggest that it is a “UL” node. If so, the code on this page is silent about how it magically appeared between two rows of a dijit grid, and which two rows. (I’m assuming from Fig. 3.7 that every list of reviews appears between two rows, under the cigar to be reviewed, even though the figure does not show any rows beneath the reviews.)

Needed:

- resultUl needs to be defined in code and explained in the text.
- how it gets displayed in the dijit grid needs to be explained in the text; all we see in the code is that its innerHTML is changed.

/r:b:

Possessive apostrophe missing at end of first paragraph: “other module’s objects”

I mean, “modules’” (not “module’s”).

(Is there no way to edit a comment here?)

I don’t think it will clear to many what you mean by saying “conseqent to a single resource request”.

Better perhaps: “Http requests are expensive, and their performance varies unpredictably with network conditions, so you want your browser to make as few of them as possible. Why not package several modules together so the browser can load all of them in one single http request, instead of loading them individually?”

IMHO the attempt to explain or define what a dojo module is on pages 69-70 is not successful. I’ll try to indicate some of the reasons, and offer a solution.

- To say that a module “manifests” something on p. 69 does not, I think, really explain anything. To “manifest” is not a general or javascript term, and if you look it up in the dictionary it has many meanings, none of which seem to fit. If anything, the word “is” might do just as well.

- To say that a file name “implies” an object name implies a module name also is a little to open-ended to be helpful. A definition should say what something is, so you can identify it or create one yourself. Saying it implies things isn’t specific.

- It’s never clear what the scope of js object of a module is: is it a global?

- Is the module’s path on p. 69 (first bullet) absolute or relative? If relative, relative to what?

I’m still not sure I know what a module is, but I’ll attempt the sort of paragraphs I’m looking for here:

At its simplest, the name of a dojo module is the name of a javascript (.js) file containing some or all of the methods and properties of a global js object with the same name. For example, if a file foo.js is used to create a global object window.foo (or document.foo) in this sense, then “foo” is the name of a dojo module. The term “module” is used somewhat loosely here to denote any or all of these components; the definition of the module name, however, is precise.

Thus there is a global object dojo and its javascript file dojo.js, all of which constitute the module dojo.

More generally, a module name also includes its path relative to either the dojo module or to a parent module (modules can contain other modules). [Insert one sentence example.] In this book we will call the module javascript files “primary script files,” since a module may use others not directly related to the script’s object. The names of primary script files follow some conventions too, one of which is that if it begins with a capital letter the corresponding object is a Dojo “class,” which we will define later.

I’m not claiming I’ve correctly defined a module here (although I hope I have). I’m just trying to show how it might be defined more precisely than on pp.69-70.

The five main ways of getting a widget reference is so useful, it might be worth making a “cheat sheet” appendix with this and similar tips.

It is unclear whether “property” is a string or a special dojo class/type in statements like:

result = myNodeList.attr(property);

It would be helpful to clarify that.

It’s not quite obvious enough that “position” is an integer. Yes it’s in the API, but that’s a dig. It would be best to add a clause or sentence explaining it.

You write: “Note how the nodes are not destroyed.” Note this how? I assume it is because .orphan returns a NodeList of them, but the text doesn’t say that.

“It they
weren’t there, someone could type…” should start with “If”

You use labels for form fields, but the corresponding form fields don’t have IDs (the label’s for attribute references an ID)

You’ve got an object called yourOjbect at pdf page 92 and 93. I guess you wanted to write yourObject?!

It is never explained why we should do e.g.

…
dataDeferred.addCallback(continueWithData);
…
load: function(data) { deferred.callback(data); }
…

instead of just:

…
load: function(data) { continueWithCallback(data); }
…

What I think is needed is a short explanation of why, in the above code, using dojo.Deferred is preferable. I can’t suggest any such reasons, because I can’t see any, even after reading pages 125 to the end of the chapter.

I’m sure there are good reasons, but I don’t see them (perhaps I missed them).

For example, the short paragraph just above “Registering Callbacks with dojo.Deferred” describes needs that can be addressed without dojo.Deferred, just by using the counter in finishDisplay. The order in which continueWithData() and continueWithMetadata() fire is not important, all that matters is that populatePanelWithData() not fire until they do: and finishDisplay() ensures this will happen just with the displayInfo.processCompleteCount. dojo.Deferred just doesn’t seem to be doing any work in this example: it isn’t needed to synchronize the two “continue” functions.

A stronger justification for using dojo.Deferred is needed.

/r:b:

Footer for Errata does not point to the Errata section for Dojo.

“sinking swap” might oughta be “sinking swamp”

“recommend” instead of “recommending” on ln 2

ln 4 awkward “for using serving it from”

“to different URL” -> “to a different URL”

Problem

This sentence can be simplified to eliminate a confusing, undefined term: “The driver ItemFileReadStore
implements the methods specified by the features dojo.data.Read and
dojo.data.Identification.”

What is a “feature”? This term is not defined anywhere; also, the word “of” is missing. This all confuses the reader. AFAIK, “feature” is just a way to avoid saying “method” twice here.

Solution:
=
Change the sentence to:

“The driver ItemFileReadStore
implements dojo.data.Read and
dojo.data.Identification.”

The explanation of a label is (to me) confusing because it never explicitly states that a label is just another attribute. Perhaps it would be better her to give a very simple example, instead of trying to just describe.

Suggested alternative expanation:

An identity is an attribute, and its unique value is often numbers or symbols.
To make identity output easier to read, another attribute can be specified
as the identity’s label. For example, in this array of two items the customerNumber
can be set to be the identity, and the easier to read customerName as its label.:

[{ customerNumber: “XH39”, customerName: “Jane Doe”, status:“current”}, { customerNumber: “CR99W”, customerName: “Jane Doe”, status: “current”}]

Note that the label does not have to be unique, even though the identity does.

/rb

The code sample works fine for me on a Mac/FF with this code block:

The text however mysteriously wraps all of that code into a function declaration (see below). If that is actually necessary, that really ought to be explained:

Also, it might be useful to add a reference to the discussion of why dojo.addOnLoad is better than document.onLoad.

The explanation of the ‘orphan’ method seems unclear to me. For example, the sentence reads as if Node.removeChild does the catching of nodes in a filter (“by” should probably be “with”).

Suggested alternative:

“orphan: takes a single-expression CSS query an argument (like ”.foo“, ”#bar“, ”H1“, etc); all elements in the NodeList which match are removed from it (by Node.removeChild), and are returned in a new NodeList. The single-expression CSS query is called a ”filter."

Fig 7.9 on page 162 ought to be moved up to page 143/4. That’s twenty+ pages of complicated box diagrams, arrows, and code until the reader finally finds out (by looking at Fig 7.9) what we set out to do on page 143, and that’s too long.

Re suggestion #31150: I meant page 154, not page 143. (It really would be helpful if errata comments could be edited!)

Why is dojo.xhr always written as dojo.xhr^{/sup>? This starts on page 35. If this is shorthand for dojo.xhrGet, .xhrPut, .xhrPost, why is the a superscript? If this shorthand is meant, it might be better to explain this the first time it is used, and to echo regex by not making it a superscript.}

“Since our handler does require any particular context, we omitted the context argument.”

Change:
“does” -> “does not”

It is confusing that on the one hand we have dojo.require(“dojox.grid._data.model” ); together with <div dojoType=“dojox.grid.data.DojoData”…>

Ditto with dojo.require(“dojox.grid.Grid”) versus <div dojoType=“dojox.Grid”…>

For Java programmers this is especially confusing, because the relationship between a package name and one of its classes is always simple. Here, there seems to be no rhyme or reason, no clear relationship between what is required/imported and what is used. Could you add at least a footnote explaining this a bit? Thanks!

Re comment #31148: I see that the code is written to avoid polluting the namespace, as in Fla06, section 8.8.3. Because the reader is already absorbing so much new information, I suggest perhaps writing the code in the more straight-forward way (as I did in #31148), and just adding a footnote to Fla06 saying: “We’re keeping things simple here, but there is in fact a better way to write this javascript code that avoids polluting the javascript namespace; for more details see [Fla06], section 8.8.3.”

The code sample uses remote-scripting.css, but that file’s contents are never shown. Perhaps best to just remove the css file import?

For people coding along who don’t have or don’t want to get dumpObject, perhaps at least a footnote on how to view ioArgs with Firebug using console.log(ioArgs).

Really good explanation of events and event propagation here!

You wrote: “It is also possible to skip the capturing phase without affecting the last two steps and this is exactly how the Dojo event framework works.”

Suggestion:

add “: it does not process capturing at all.” to the end of the sentence. Otherwise the reader may be left wondering (since you previously showed how to stop propagation): ok, but how does Dojo stop capturing without affecting 2 and 3?

While this is clearly implied, you don’t explicitly advise readers to use “event.currentTarget” instead of “this” inside their handler functions.

(1) It would be helpful to explicit about this — about where to use event.currentTarget — instead of just implying it.

(2) Is there no way to pass event.currentTarget as the context argument instead?

it would be helpful to add a reminder reference to page 81, where calling dojo.hitch with one argument is discussed.

You make clear that dojo.hitch(“fn”) will execute dojo.global[“fn”] instead of calling fn from a non-global context. Perhaps add more explicitly: “Thus, any variable this in the function fn will be Javascript’s global context.”

You write: “All of this is unnecessary with dojo.connect. Just connect the command handler directly to the command object and you’re done.”

But isn’t there also a significant drawback, that because there is no centralization it is difficult to keep the handlers from stepping on each other and of keeping them organized in code?

This sentence is very difficult to parse: “The context parameter is syntactic sugar for designating a handler that requires binding a function to a context (for example, a method to an object) without calling dojo.hitch explicitly.”

Here’s why:

“A handler that requires binding to a function to a context” sounds as if there’s something special about being a handler that can require binding some other function
to its context. Once my brain has finished figuring out that the handler is that function, “without calling dojo.hitch explicitly” and the stuff about syntactic sugar then makes it really seize up. :)

Suggested lternative:

“The two last parameters context and handler actually end up being hitched to each other with dojo.hitch(), which is also why the context parameter is optional (see p. 81).”

“For example, in a tradition application system,”: “tradition” -> “traditional”

Perhaps be explicit by adding a sentence like: “The new property ‘name’ is added to the new instance of newObj, not to its prototype.”

It would be helpful to state this explicitly, so learning readers don’t have to chase down mixin to figure this out; or speculate on the nasty side-effect of foo changing, then wondering whether maybe foo is cloned to avoid that, then go looking in the source code, etc etc etc.

It’s just easier to on the reader to tell him/her explicitly

As I said in comment #31187, the strange discrepancies between module and class namespaces, as revealed on this page for the dojo grid, are bewildering, especially to Java programmers.

Suggestion: add something like my post (at tinyurl 2foycy) in the dojo book under “Creating Your Own Modules”, and on page 50 add a reference to it.

To me, this sidebar on .byId is very confusing. The first paragraph never seems to say what dijit.byId() returns, it only tells me what dojo.byId() returns.

Perhaps an alternative paragraph like this might be clearer:

“You might ask, ”Why do I need to call dijit.byId(‘id’)? Can’t I just call
dojo.byId(‘id’)?" Well, that depends on what you want. With dojo.byId(‘id’), you’ll just get a plain
old DOM node. With dijit.byId(‘id’), you’ll get a full-blown widget object whose parent node
happens to be dojo.byId(‘id’)."

Middle of the page:
“…every object created by an object literal has it’s prototype reference…” -> “it’s” should be “its”

Also:

function ctor(){}
ctor.prototype= p1;

should be:

function ctor(){
ctor.prototype= p1;
}

Problems with the GRID example. I used Aptana 1.1.5.009212… I had to manually import DOJO 1.1 into my project. After I did this I could get Aptana’s preview tabs for Safari and Firefox to work. Yet if I tried to open the grid_html page directly in Firefox (2.0.0.13) or Safari (3.0.4) running on Leapord 10.5.2, the web page would not work correctly. It would just give me the headers centered in th page (firefox) or at the bottom of the page (Safari). Again the preview panes in Aptana worked for Firefox, Safari, and the iPhone. But not actually in the browsers themselves after I launched them.

342 “Working our way up from cell-level extension points like grid( ) to..” grid() should be get( )

“dojox.grid.editors.ComboBox (Dijit): like Select, but ignores the values array and can accept entires not in the options array.” “entires” should be “entries”

Is there a sort other than alphabetical? Many times, spreadsheets contain numbers. How does one create a numerical sort instead of alphabetical. I don’t see a way to do this without leading zeros on numerical columns. How can I solve this problem in Grid efficiently?

More explanation of the filtering would be helpful. I don’t understand the purpose of much of what you have in code. Can you explain each line of code a bit more? I’m a bit lost on what much of it is really doing. Wish I could apply this right now, but I’m lost here.

‘for=“first_name”’ should be ‘for=“date_move”’ for date picker.

Example shows function “appendNewListItem”, but text at bottom of page shows “createListItem”.

Pages 49-50. The example shows the table dojoType attribute as dojox.Grid with the following text specifying dojox.grid.Grid.

Disregard my previous comment for #31641. Explanation follows several paragraphs later, but confusing initially.

‘an hash’ should be ‘a hash’ in last line.

“… that searchTerms variable” is referred to as though it was already mentioned. I assume you mean from the API page, but perhaps you could change to “… that searchTerms variable from the Yahoo search API…”

“Grid provides hooks for you called events.” you to your

Would be helpful to the reader to give an example result hash from Yahoo ResultSet.Result, so they have some idea of what is being returned so it is clearer what substitute is doing. I get the picture, but concrete examples make it crystal.

For #31646, maybe reference this result example (for the impatient like me ;-) ) so that the reader knows the context for substitute.

“but for now all we need is know is to use the” Awkward.

Why does load: and error: have deferred.x() when the object was dataDeferred? This is not explained anywhere and I don’t follow where it comes from. Confusing.

This example seems too abstract. I think I follow it, but I can bet a lot of users will have trouble with it. you might want to find a simpler, “more concrete” example. Hope this helps.

Can you provide a diagram? The callback/errorback queue thing is confusing as hell. (Or, maybe its just the end of the day. ;-) )

Missing ‘c1’ from example line 23

“sans the x and y scroll offsets.” What is ‘sans’?

“this kind is small optimization” to “this kind of small optimization”

“4. Initialize the the height” extra “the”.

Reference where dojo.partial is discussed. I simply can’t remember what or where it is.

This filtering example seems to work if I page down, but the first page continues to posses unfiltered data.
And, I changed query under the model for 1.0.2. (Grid.model.query)

TextBox’s regular expression option:
-Email
+Email
Here you have the full power of JavaScript regular expressions. In our

The regExp=“" property of the ValidationTextBox makes user entries be flagged as errors unless the entry is a single "” only. I changed it to regExp=“[^]+[@]+” and found that it accepts regular email addresses.

In section 3.5 the Grid structure is changed from being configured in HTML to being configured in JavaScript.

I found this transition hard to follow.

provile must be profile in the first list item element

“dojox.data.CsvStore for comma-separated variables”
should read
“dojox.data.CsvStore for comma-separated values”

The links in the PDF to download the BAF and ODE applications do not work. Additionally, the baf/ode applications are missing from the downloaded .zip & .tgz files. There is a /code/baf directory, but with only a license.txt & a demo.js.

In the code at the top of the page iterating over ‘urls’ hash….the line using dojo.string.substitution function should actually take ‘url[i]’ instead of ‘result’.

I would prefer if code samples always sourced dojo.js from /dojoroot/dojo/dojo.js as they do in the earlier examples.

The code asynchronous-programming/event.htm sources dojo.js from ../../dojo/dojo.js which makes the example fail to work in the environment I set up for the earlier examples without altering it.

dysfunctional is misspelled as disfunctional

Context:
download. If the page contains many and/or large external
resources and/or the connection is slow, the user is presented
with a >>disfunctional<< page (since the initialization code hasn’t
run)—perhaps for a significant period of time. We want our

In the line of code demonstrating string substitution at the top of the page, the hash is called “result” instead of “oneResult,” as it is elsewhere in the example.

Currently:

listItem.innerHTML = dojo.string.substitute(“${title}”, result);

Should be:

listItem.innerHTML = dojo.string.substitute(“${title}”, oneResult);

The last sentence of the page refers to a figure “on the following page,” but the words “following page” themselves are on the same page as the figure…

First line reads “We going to spend an entire…”

Should be “We are going…”

Last paragraph, first sentence “…that we can used to experiment…”

Should be “…that we can use to experiment…”

Second full paragraph: “Before we go any further, let’s set up a example…”

Should be “…set up an example…”

In the “Alex Says:” box, it seems a bit redundant to end the last two paragraphs with nearly identical sentences. I think the reader would get the point if it were only mentioned once.

First sentence: “Grid has a large assortment of extensions points…”

Should be: “Grid has a large assortment of extension points…”

In line

remove the redundant end tag.

eventobj.stopPropagation(); should be eventObj.stopPropagation();
in all examples.
.

Both versions of genetox_def.html on this page seem identical but the text would indicate that the second version should have something additional compared to the first

The filtering select example can’t work as shown. With the searchAttr=“docno”, it recognizes only the document numbers as input (and only autocompletes based on numbers not substance names). This example is badly in need of proofreading and testing. As presented, if you select a substance name, it fills in the docno in the text box. If you type in a substance name from the select list, it doesn’t recognize it.

top p. 38 ‘oneResult’ does not seem to match up with preceding bottom page 37:
dojo.string.substitute(“${title}”, result);

At the end of the section 18.2 (Step 1), the instructions say to start the local HTTP server and navigate to obe.htm, but it should say main.htm instead.

At the end of the page (5 lines from the end) it mentions the “obe.man” module and should be “obe.main”

The web address for Vista Information Technologies in the footnote should be www.vista-info-tech.com.

Last code snippet on the page: variable ‘result’ is not defined, and then the subsequent paragraph (p38) refers to oneResult, which is also not defined. (also noted in erratum #32561).

The paragraph beginning ‘When this code is evaluated…’ does not match what the code in function example15() (on p195) actually does. There is no call to dojo.setObject, and object exercise15.myObject isn’t defined anywhere.

In the code snippet, the parameter ‘synch: true’ is given. According to all the text preceding, this should be ‘sync: true’.

In the code for function example21(), the key ‘synch’ in the args for dojo.xhrPut() should be ‘sync’.

“dojo.isString(test) … either a string literal or a string variable.” But variables don’t have types, so there is no such thing as a string variable. And whether the argument expression contains just a variable is irrelevant to the value that dojo.isString sees. I believe what is intended instead of “string variable” is “string object”, as in the result of new String().

When the email input is introduced, it makes it seem as if it is an old friend that was already there. But none of the html code mentions it and it isn’t shown in Figure 2.1. Make sure it shows up in the figure and in the first div block on page 21.

This isn’t really a typo — it’s a production error that should have been caught by the Q/A process.

In figure 6.2 there are several incomplete See references. Example class Event target says:
“See Event.target; see xxx for a discussion of bubbling.”

The last name input field erroneously assumes that words in someones last name should be propercased. However that is not true for many names (e.g. with the last names between —: Werner von Braun, Marquise de Sade). The propercasing might be ok for some countries, but the form has a country field so things should be globally useable.

4th line from bottom: remove ’

’ as the previous script tag closes with />

2nd bullet item on the page: ‘pattern specifies …’ should be
‘datePattern specifies …’. In the example on page 415 this is correct.

In the description of figure 8.3: ‘comma-filtered’ should read ‘comment-filtered’

The 14 line of HTML code in this page says:“Events that can bubble always bubble; events never propagate.”
I think the “events never never propagate” is not correct because bubble is propagation.

in the code sample, there’s a closing tag (

)
without an opening