A few weeks ago, some of the guys at SitePen were commenting that I was using Flash on my personal web site for a Flickr Badge. I responded that if Dojo had similar functionality, I would easily replace the badge. A couple of weeks later, Peter Higgins and Bryan Forbes of SitePen rose to the task and created dojox.image.FlickrBadge.
This weekend I had a chance to put their work to the test, and I’m impressed. Using the new Flickr badge is quite easy:
...
...
...
...
. There are a number of configurable parameters, most of which are optional:
- apikey: your Flickr API key
- columns: # of columns of images to display
- rows: # of rows of images to display
- searchText: free text search of title, description, and tags
- setid: id of a Flickr set to use in displaying images
- tags: a comma separated list of tags or an array of tags to grab from Flickr
- userid: your flickr userid (saves a lookup request)
- username: your flickr username
Give them a try and create a badge that’s just right for your site.
Performance Optimizations
The badge included to this point is a great start, but it requires a number of JavaScript files to be loaded prior to the completion of page rendering, so I started making tweaks to improve performance. The next logical step is to create a Dojo build to layer all of the non-core Dojo code required for this module into a single file. First, I’ll create a very simple profile file for my build:
dependencies = {
layers: [
{
name: "badge.js",
resourceName: "dojo.badge",
layerDependencies: [
"dojo.js"
],
dependencies: [
"dojox.image.FlickrBadge"
]
}
],
prefixes: [
[ "dijit", "../dijit" ],
[ "dojox", "../dojox" ]
]
}
And then I ran the build with the following configuration options:
./build.sh action=release optimize=shrinksafe profile=dylan
cssOptimize=comments.keepLines cssImportIgnore=../dijit.css
version=1.2.pre
This reduced the number of requests by compressing a number of JavaScript files into badge.js. However, it still required a decent amount of additional JavaScript to load before the page renders. Fortunately, I’m using the latest Dojo trunk, and Dojo 1.2 has a new mechanism for lazy-loading a built layer! That’s right, just point to a layer as you would any Dojo module, and defer loading until later. All with a simple, single line of JavaScript:
dojo.addOnLoad(function(){ dojo.require("dojo.badge");
dojo.addOnLoad(function(){ initBadge(); })});
A couple of notes:
- the nested dojo.addOnLoad is the new way to add a load callback for a lazy-loaded layer
- my use of dojo.badge as the resourceName is not a coincidence… it follows Dojo’s standard naming conventions, looking for the file badge.js as dojo/badge.js automatically
Finally, inside initBadge, I decided to turn off Dojo’s parser, and instead make an explicit widget instantiation on the node to replace, in order to reduce code execution time:
function initBadge(){
console.log("init");
new dojox.image.FlickrBadge({rows: 8, cols: 3, username: "dylans",
tags:"italy,dojotoolkit"},"flickrSidebox").startup();
}
That leaves us with this performance-optimized code fragment:
...
...
...
...
In a future release, I’d like to see us add an option to randomize which images get selected from the set, rather than the first X results from a query. This is a complaint I have with the official Flickr Badge as well, and the API itself which generally returns the first X entries. dojox.image now has a number of great features: Lightbox, Badge, Gallery, Magnifer, and SlideShow. dojox.image.FlickrBadge uses the new dojox.data.FlickrRestStore, a Dojo Data store implementation that makes it extremely easy and flexible to work between Flickr data sources and Dijits.