Dojo is a very flexible toolkit; it doesn’t dictate how you organize your code or create your widgets. It simply provides tools, and it’s up to you to decide how you want to fit them together. Developing with AIR puts you squarely in the browser-based application model, but aside from that it mostly stays out of your way as well. As part of our series on the Queued development process, I’m going to take a look at the decisions we made and the philosophies we adopted for the project. It should provide some insight into our process.
Author Archive
Queued: Architectural Decisions
Monday, March 30th, 2009Simplifying Maintenance With Event Driven Design
Tuesday, March 3rd, 2009Dojo is big, but it’s not unwieldy. You don’t have to learn it all to be productive. There are probably large pieces of the toolkit that you’ll never even need, but Dojo is built so that if you don’t need something, it doesn’t weigh you down. Where it counts, Dojo is actually quite lean. In the most basic unit of the toolkit—dojo.js itself—you’ll find enough power to get real work done. It’s worth looking at what you buy when you spend 26KB (gzipped) on JavaScript code rather than a pretty PNG. I think you’ll like what you find.
Let’s start with event handling. I’ll cover the basic techniques first, then finish with a real-world implementation of the concept by looking at Queued, our AIR-based Netflix queue manager.
Announcing Queued, a Netflix Queue Manager Using Dojo and AIR
Tuesday, February 17th, 2009I’m excited to announce a new open source project created by SitePen and co-sponsored by Adobe: Queued. With Queued, you can manage your Netflix queue anytime, anywhere!
It’s no secret that we’re big fans of Dojo here. Since Adobe AIR provides a platform that integrates desktop features into the browser development model, it’s easy to see where our favorite JavaScript toolkit fits: it’s every bit the springboard in the AIR world as it is in the browser world. We designed Queued to show what the Dojo + AIR combo can do.
Dojo Sensei Reader, a Training Application
Tuesday, October 14th, 2008When conducting Dojo training courses, we’ve found it to be very valuable to go beyond simple code snippets to demonstrate APIs, patterns, and other key concepts. Snippets and demos are useful, but they often lack a very important quality: context. Nothing beats having a full application in front of you—with code available to read and modify as you learn the ropes—so we built the Dojo Sensei Reader, a rich, powerful RSS reader realized as a single-page web application.
Web Service to dojo.data Store in 4 Easy Steps
Wednesday, June 25th, 2008A very useful feature of Dojo is the dojox.data.ServiceStore data store. It allows you to layer a dojo.data API on top of any web service, opening up a world of uses from your own client-side components. Kris Zyp briefly mentioned the topic in his recent article on JsonRestStore, and the past couple of weeks have seen a bunch of refinements to the component to get it ready for next month’s Dojo 1.2 release. Let’s take a quick look at how to make it work with the web service of your choice.
Dojo Drag and Drop, Part 1: dojo.dnd
Tuesday, June 10th, 2008Most anyone who’s looked at the feature list knows that one of Dojo’s core features is a drag and drop framework. What’s not immediately obvious is that Dojo actually has two drag and drop APIs. The first, dojo.dnd, is designed to manage the process of dragging items between two or more containers, including multiple selection, item acceptance filtering on drop targets, and other behavioral tweaks. The second API, dojo.dnd.move, is a bit lower-level in scope; it’s designed to manage the process of moving single objects around, without the concept of attaching items to containers. Both of these are very useful features to have at your disposal. In this article, we’ll cover dojo.dnd.
Supercharge Your MAMP Environment
Friday, May 16th, 2008Be Careful With XML-RPC Dates
Tuesday, October 2nd, 2007A lot of my work involves 3rd party API integration. We have plenty of tools at our disposal: protocols like SOAP, XML-RPC, JSON-RPC, and conventions like RESTful URI schemes. You would think it’d be a no-brainer to hook services together. Not always.
I was recently writing some code that called an XML-RPC method to retrieve logging data for an external service. The method signature itself was simple (names changed to protect the, all right, for the heck of it):
Follow Us
Subscribe