Ask anyone who has ever contemplated using the Dojo Toolkit and they’ll tell you that its Achilles’ heel is documentation. Articles online are generally outdated and the Dojo Reference Guide and API docs, while helpful for existing Dojo developers, are anything but comprehensive if you’re new to Dojo and don’t know exactly where to start when building Dojo-based web and mobile apps.
While there are books that have been published and a smattering of resources scattered about online, there has never been a cohesive, up-to-date resource for learning how to use the greatness that is the Dojo Toolkit. Until now.
Announcing Dojo Tutorials
With the release of Dojo 1.6, SitePen has written a starter set of Dojo tutorials for your learning pleasure! These tutorials don’t just show you the code and expect you to figure out the rest, they explain how and why to use the various parts of the Dojo Toolkit — the right way. All you have to say is Hello Dojo, and you’ll be placed on the path to coding success.
The first set of tutorials are authored by SitePen engineers (many of whom are core Dojo committers) and are easy to find within the Dojo Toolkit Documentation section. The Dojo Reference Guide has also been updated making the Dojo Toolkit website the definitive place to go for Dojo documentation.
Want to see a specific Tutorial? Want to Learn More?
Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you.
Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.
It turns out that consuming WCF-based services with Dojo is quite easy to do, and in this post we’ll show you how to do it. For reference, we’ll be using this article from Sridhar Subramanian at C# Corner which shows how to write your WCF-based services, so we won’t be going into the details of the C# component here. Instead, we’ll focus on the client-side code.
Dojo 1.4 sports a fantastic tree widget, complete with ARIA compliance, keyboard accessibility, and internationalization (including right-to-left layout for appropriate countries and languages). For large tree data sets, we want to be able to only load the necessary data for the visible nodes of the tree. As a user expands a node, we then want to load the children of that node. Ideally, we only want to make one HTTP request per expansion for optimal performance. Historically, effective lazy loading has been a challenge, but some recent additions will make it much easier to utilize efficient lazy loading mechanisms in the tree.
The Dojo-based Bespin project has added collaboration and social features so developers can more easily share code in real-time! Finally, a truly productive use of social networking for developers!
By combining the benefits of SubEthaEdit and many of the social features you find on networking sites, the project is headed in a very useful direction that should significantly improve the way software is developed.
Google recently released a new feature for their Google Docs writing application; the ability to draw a vector graphic and insert it in your document. This drawing module uses SVG and VML, much like DojoX GFX. I was curious about their code and explored with Firebug. To my surprise, I found that most of their code uses variables in the global scope. The code is compressed, but when observing with Firebug’s DOM tab, there are several pages and a few hundred lines of global variables.
As part of our series on how we built Queued, today we’re going to talk about theming the Queued application, and touch on a few examples of what made putting the skin on Queued so much fun.
The foundation for the beautiful theme for Queued was laid down by colleagues Damon Dimmick and Torrey Rice, and their amazing wireframe and mockup work (respectively) provided the building blocks for laying down Queued’s skin.
SitePen is excited to announce Stocker, which demonstrates some of the more advanced capabilities of Dojo, including the newly released DataChart, the DataGrid, Data Store, Comet, Persevere, and BorderContainer. SitePen is also offering a one-day workshop where you will learn how to create Stocker yourself, but I’m here to give you a sneak peak of what Stocker is and how it works.
Stocker uses these technologies to emulate a stock monitoring application. We’re using made up data, but that’s actually more interesting. The Persevere server generates new stock items at certain intervals, and then pushes them to the browser with Comet. Then the Data Store updates its items and triggers an
onSet notification. The DataGrid and DataChart are both connected to the same store, and are listening to that event. They then update their displays and show the stock items and their latest data.
At SitePen, we work very hard to to provide our customers and fellow developers with useful web app development services. We’re currently deconstructing the development of Queued, our Netflix Queue management application built with Dojo and Adobe AIR. Having presented on dojo.deferred and related topics at the Ajax Experience, and having heard that the Queued team ran into a few problems with them, I thought it would be interesting to review problems that are sometimes encountered when using Deferreds. What is the source of these problems, are these problems related to bugs or because there are misunderstandings, and how should we address this going forward?
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.