In the forthcoming Dojo Toolkit 1.8, the dojo/request package, written by Bryan Forbes, has some really “cool” features in my opinion.  While the package “modernises” the Dojo IO/Request API, it also has some features that will really help end developers.

First, it is designed to Just Work™.  It works in a browser environment or a node.js environment seamlessly.  For example, if I wanted to load some JSON and do something with it, in a browser, I would do this:

But let’s say you were doing it on node.js. What would you need to do then? You wouldn’t do a thing. You would simply run your code with something like this node ./dojo/dojo.js load=example at a command line.  dojo/request will automatically figure out what platform you are on and load the appropriate request provider for you.

The second “cool” feature in my opinion is the ability to use the dojo/request/registry to “transparently” manage multiple request providers without having to worry about which one you are specifically using.  Just set it up and fire your requests away.  For example, take the situation that I would like to use JSONP some of the time and JSON the rest of the time (maybe I have a x-domain service where I have to use JSONP instead of just plain JSON).  Well, in order to do that, I would need to use dojo/request/script to get the JSONP, but I couldn’t use it to just fetch plain JSON and want to use dojo/request/xhr (which is the default provider for browsers).  In order to do that, I would do something like this:

Lastly, maybe I have some strange, bizarre encoding (or maybe I need to do some pre-transforms on my JSON or XML to properly convert them into objects).  Using dojo/request/handlers, I can add to the pre-existing handlers with my own, and then can use the handleAs property to to utilise my custom handler:

So while, Dojo Toolkit 1.8 will be a “stepping stone” to Dojo Toolkit 2.0, there are some really cool features that you can use now.

One thought on “dojo/request

Comments are closed.