Dojo 1.6 introduces a new alternative declarative markup syntax using HTML5 data attributes, with the aim of allowing definition of object instances via HTML without forcing users to write invalid markup. The new syntax primarily revolves around the use of
data-dojo-type in lieu of
dojoType, and a
data-dojo-props attribute to hold any properties to be passed to the constructor’s first argument.
However, this new syntax brings with it some significant differences in behavior, which has caught many users off-guard. For instance, you might try something like this:
<input data-dojo-type="dijit.form.ValidationTextBox" id="tb_username" data-dojo-props="required: true" style="width: 300px;" name="username" value="bob"/>
You would be surprised, then, to observe that the widget appears to ignore your style, name, and value settings altogether. What gives? Let’s find out.
One of the most fundamental yet powerful features of the Dojo Toolkit is its module and dependency management system, harnessed via
dojo.require. I’ve seen one important detail elude countless developers, however: the distinction between when a module is
dojo.required, and when it is actually loaded and ready for use. It’s very easy to mishandle this, and the nature in which it tends to come back to bite leaves no indication of the actual problem to the unwary developer. This usually crops up in the form of the following question:
dojo.required widget X using cross-domain Dojo, but when I go to instantiate X, I get an exception saying that X is not a constructor!
Depending upon what module was requested, the exception might instead say SomeNamespaceAboveX is undefined.
Interestingly, both the API and Reference Guide pages for
dojo.require actually sort of answer this question (or rather, show how to avoid encountering it completely), but in this post I aim to clarify why this happens (and perhaps encourage a few wandering souls to read the docs more often).
I’m sure this one has been asked numerous times, but it came up most recently on IRC from
darkschneider (with an additional nod from
dijit.layout.TabContainer widget is tremendously useful, but it has a noticeable shortcoming that, while minor and innocuous, can still be irritating: if you’ve navigated between tabs and then close the current one, it always sends you back to the first tab in the container, rather than the previously active tab.
This is something I had noticed while working with Dojo on a mockup at my job over a year ago, and I developed a solution to it then. Now that I’ve got this blog here, I might as well share it for others’ benefit.
UPDATED on 6/28 to bring the example more in line with how TabContainer works in Dojo 1.4+
This post focuses on a question reincarnated most recently by
cbarrett1 in the Dojo IRC channel:
- How do I implement custom save logic on an ItemFileWriteStore?
This was always something I wanted to become familiar with, and upon initial inspection it seemed easy enough to implement an example. It’s also a prime opportunity to put across a few other general points as well. While the main intent of this post should be clear, it also briefly touches upon various other topics along the way, so hopefully there’s a little something for everybody who’s learning Dojo.
Continuing for the moment on the topic of Dijit, I turn my focus to two
dijit.form widgets which are easily confused: ComboBox and FilteringSelect. These widgets are very similar in appearance, but differ fundamentally in behavior and functionality, which can easily lead to confusion if one is not fully aware of what sets the two apart.
This post aims to give a synopsis of what sets these widgets apart from each other, and will also address a question that I’ve seen repeatedly in the #dojo IRC channel:
“How do I get the value of the selected option in a
This shall be the first of an unpredictable number of posts wherein I discuss recurring sources of confusion for newcomers to the Dojo Toolkit. I’ll be tagging such posts dojofaq, for future reference.
One of the main attractions to the Dojo Toolkit is Dijit, a library of skinnable widgets built upon the functionality available in dojo core (Dijit = Dojo + widget). However, diving head-first into Dijit without a primer can quickly lead to various common points of confusion, which I’ve seen come up repeatedly in the IRC channel. This article aims to cover a bit of the basics, demystifying and addressing questions such as the following:
- “Why doesn’t
dojo.attr('mywidgetid', 'value')do what I expect?”
dojo.destroyed my widget, but when I recreate it it tells me the id is already registered!”
- “I’m connecting to my widget’s
onclickbut it’s not firing!”
These questions all have a common source – the confusion between working with Dijit widgets, versus working simply with DOM nodes. Read more
Over the past 15 months, I’ve been fortunate enough to have the opportunity to become acquainted with Dojo. I read a decent chunk of Dojo: The Definitive Guide, which repeatedly impressed upon me how well-crafted parts of Dojo Core and Dijit are; it’s quite apparent a lot of thought went into this stuff.
After I spent some time getting my feet wet in actual code, I began hanging around the
#dojo channel on freenode (circa July ’09), and was rather surprised at how quickly I was able to start helping other aspiring Dojo users. As time passed, I noticed a few things…
Things have changed.
I’m just hoping that sharing some of my (and others’) experiences here might help you to fasten your grip as well.