Many Dojo widgets make use of client-side templating for generating the UI. Template HTML files are brought in to the page with dojo/text, parsed and converted to DOM nodes, and placed on the page, allowing our code to make substitutions, instantiate widgets within the template, and hook up events and attach points.

In web browsers that support Cross-Origin Resource Sharing (CORS) via XMLHttpRequest objects, Dojo’s XHR mechanism can make cross-domain requests out of the box. Because of the same-origin policy of XMLHttpRequest, Dojo has long supported various methods of loading resources across domains – dojo/io/script and dojo/io/frame; dojo/request/script and dojo/request/iframe in recent versions (1.8+).

Many object-oriented programming (OOP) languages provide a way to define private properties and methods. This allows objects to encapsulate functionality and state information.

It is becoming increasingly popular to deploy Node.js-based applications to Node-friendly hosting services to take advantage of the pre-built, reliable, robust architecture and infrastructure these services provide. Persevere, a JavaScript server framework for developing RESTful applications on Node.js, is an excellent fit for these types of hosting services.

What a great year 2013 has been! We’re feeling (collectively) like Ebenezer Scrooge in the final chapters of Charles Dickens’ A Christmas Carol – except we haven’t been jerks up ’til now and we think working at SitePen is a year-round Christmas vacation, unlike the earlier chapters wherein Scrooge forces poor Mr. Cratchit to work by the heat of a candle.

A common error when using Dijits is “Tried to register widget with id==XXX but that id is already registered”. That is the dijit/registry telling us that we’ve made a mistake instantiating a widget.

Dijit widgets provide the ability to write custom setters and getters, whose logic is executed when calling the set and get methods. dijit/_WidgetBase also provides a _set method, which is very important when writing widgets, but can cause a bit of confusion due to its name.

A concept that is often confusing to new JavaScript developers is the idea of function context, specifically as it relates to the value of this. For example, methods in Java are bound to classes at compile time, and this in a method call will always refer to an instance of the method’s class.

One pretty common issue we get in the dojo-interest mailing list asks why RoundRectStoreList.set(“store”, store); doesn’t actually appear to be setting the store properly? That is, the data in the RoundRectStoreList doesn’t actually render the data in the new store, but instead keeps old data rendered. An example of this error: HTML: [code language=”html”] Swap ‘Em! [/code] JavaScript: [code language=”javascript”] require([ “dojo/store/Memory”, “dijit/form/Button”, “dojox/mobile/RoundRectStoreList” ], function (Memory, Button, RoundRectStoreList) { var sampleStore1 = new Memory({data:[ { “label”: “Wi-Fi”, “rightText”: “Off”, “moveTo”: “bar” }, { “label”: “VPN”, “rightText”: “VPN”, “moveTo”: “bar” } ], idProperty:”label”}), sampleStore2 = new Memory({data:[ { “label”: “Ice Cream”, “rightText”: “Ice Cream”, “moveTo”: “bar” }, { “label”: “Shortcake”, “rightText”: “Shortcake”, “moveTo”: “bar” } ], idProperty:”label”}), storeList = new RoundRectStoreList({store:sampleStore1}, “storeList”), wrongSwap = new Button({}, “wrongSwap”), isStore1 = true; storeList.startup(); wrongSwap.on(“click”, function () { storeList.set(“store”, isStore1 ? sampleStore2 : sampleStore1); isStore1 = !isStore1; }); }); [/code] Here, you will see that the data in the list never actually changes, even though we’re attempting to set the store using the .set() function.