The Dojo Ajax Toolkit is kindly hosted by AOL for the consumption of anyone at all. This has the advantage of
Additionally, since release 0.9 onwards, the main Dojo JavaScript file, dojo.js, is always exactly the same, whereas in previous released it changed for every developer who built it.
However, the problem comes in where you want to use your own custom code with the hosted Dojo code. This is because the hosted code uses Dojo’s loading system to dynamically load the resources needed on the page, and this will read the files from AOL, not your server (as you would expect - it knows nothing about your server). If you want to build custom layers to improve performance, the remotely hosted Dojo will not be able to find them.
So, the solution I generally tend to use is to put the AOL dojo.js on every page, and tell Dojo to load any other required files from my own server. To do this, set the baseUrl parameter on the djConfig attribute for the JavaScript file to the folder where Dojo is stored on your server. E.g.
<script type=”text/javascript” src=”http://o.aolcdn.com/dojo/1.0.2/dojo/dojo.js” djConfig=”{baseUrl:’/js/dojo/’}”></script>
Notice here that the file I load is dojo.js, the normal version, not dojo.xd.js, which is the cross domain version capable of loading files from AOL.
After doing this, you can then include whatever custom built layers you like onto an particular page. For example, if you have a layer built for the dojox.image.Gallery widget called /js/dojo/dojox/image/Gallery-layer.js, you can load it either dynamically:
<script type=”text/javascript”>dojo.require(”dojox.image.Gallery-layer.js”);</script>
or include it via a script tag:
<script type=”text/javascript” src=”js/dojo/dojox/image/Gallery-layer.js”></script>
and it should work just as if you were using Dojo from your own server. Only of course you are not - AOL is serving up that file, and in many cases users will already have cached that file, speeding up your site quite nicely.
Another approach is to create a custom namespace, register it with Dojo, and put all your layers in there…. but that’s for another post
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
A short while ago I posted about the demo engine I’m writing for the Dojo Ajax Toolkit. Click here to read that post or go to http://www.skynet.ie/~sos/js/demo/dojo/dojoc/demos/featureexplorer.html to see it in action.
Features
Since that post, quite a lot of work has gone into both the features and the content of the demo engine, and the development process has solidified nicely. Some of the features include:
Content
To date, a lot of content has been added. Many, many widgets in Dijit and DojoX
have have been added, including the majority of the Form Controls.
The latest, pretty cool additions have been the IO and dojo.query demos. These cover things such as:
File Naming Scheme
A simple file naming scheme is used to add content to the demo framework. Each folder beneath the root folder represents a demo. Each file in a folder must be named the same as the folder, with five possible extensions. For example, given a folder with the name ‘Button‘, the possible files are:
All of these files are optional. If a file in a folder does not match this naming scheme, it is assumed to be some kind of resource that the demo needs, such as an image or a JSON data file. In this case, the file can be named whatever you like.
The tree structure in the demo engine mirrors the folder layout.
Still To Do
There remains quite a lot of work ahead. There are a few bugs remaining, some more cross browser testing is needed, and of course more content is required, particularly the base Dojo package.
In the relatively near future this should be opened up to the public for development. The Dojo folks are setting up a source control server for community additions, and this demo engine should be part of that. Once that is done, people can start adding all sorts of cool stuff!
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
Internet Explorer has a nice feature where a new window can be opened modally using the window.showModalDialog function, meaning that the page that opened it cannot be accessed until the new window is closed. This can be useful in many situations.
However, the main limitation of IE Modal Dialogs (other than being non-standard), is that any hyperlink clicked in a modal dialog causes another, non modal, dialog to be opened, rather than opening the page linked to in the same window, as would happen in a normal pop up window.
The key to solving this problem is to note that a modal dialog only opens another window when a GET request is made, not when a POST request is made. However, an anchor tag automatically causes a GET request, so the solution is to:
While it is possible to put a listener on each anchor tag to achieve this, such an approach will not scale well. Instead, place a listener on the body tag. The example below is done using methods from the Dojo Ajax Toolkit, since that the toolkit I use the most, but you can of course use whatever methods you like to achieve the same result:
<script type="text/javascript">
dojo.addOnLoad(function(){
dojo.connect(dojo.body(), “onclick”, function(evt) {
if(evt.target.tagName != “A”) {return true;}
dojo.stopEvent(evt);
var form = document.createElement(”form”);
form.setAttribute(”target”, window.name ? window.name : “SrPopUp”);
form.setAttribute(”action”, url);
form.setAttribute(”method”,”POST”);
document.appendChild(form);
form.submit();
return false;
});
});
</script>
This method assumes that you have control over the content of the page being shown in the modal dialog. It would also make sense to add a similar listener to the body tag for key events, as a user can trigger an anchor tag by tabbing to it and hitting enter.
Thanks to Danny Goodman and Steiner Overbeck Cook for coming up with this solution.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
A couple of weeks ago I saw a cool demo framework for an Ajax toolkit just released as open source. It’s a very slick implementation, with a tree listing all the various demos, and a tabbed area showing the implementation, and the widget in practice.
So, I think to myself, this is exactly what the Dojo Ajax Toolkit is missing! Cut to today, and I’ve put the first rough cut at the demo framework on the web for people’s perusal. Check it out at http://www.skynet.ie/~sos/js/demo/dojo/dojoc/demos/featureexplorer.html .
Note: I have written a follow up post here.
Some of the features include:
This is still very much beta code, and there are a couple of errors floating around, but those will of course be hunted down. There are also some Internet Explorer issues that I’ll get to soon, so try this in Firefox for now (update Dec 05 2007 - most of these have been solved, with one or two small bugs remaining). I’m in discussions to get this into the Dojo toolkit, so that the community at large can start adding in demos. I’ve put in quite a few already, but it’s so easy to do that this could become a huge resource for the Dojo community.
If you have any suggestions, please let me know.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
Today I’ve begun the process of upgrading my Ubuntu installation of version 7.04 to version 7.10. To see my previous tutorial of getting Ubuntu installed on my IBM Thinkpad X41, see http://shaneosullivan.wordpress.com/2007/02/16/installing-ubuntu-edgy-on-a-thinkpad-x41-tablet/.
This post lists whatever issues I found when upgrading, and my solutions to them. For the official instructions, see https://help.ubuntu.com/community/GutsyUpgrades.
Third Party software sources cause problems
My first problem was caused by having links to third party software distribution sites. When running the “update-manager -d” command, I received an error, saying the dbus couldn’t run.
This was caused by having third party software sources enabled that no longer existed, for whatever reason.
To fix this:
Modifying the software channels gets stuck
When the second step in the “Distribution Upgrade” application is running, that is, the “Modifying the software channels” step, it got stuck downloading files. It would say
Downloading file 36 of 97
and stay at that number for a long time. This was not a bandwidth issue, it simply stopped. To fix this
Dual monitors didn’t work correctly
When booted up with an external monitor plugged in, the desktop was fixed at 640 * 480 pixels resolution. I found someone else with a similar issue at http://ubuntuforums.org/showthread.php?t=566947 , but their solution didn’t work for me. I solved this by:
Compiz has problems with dual monitors
Compiz (the 3D graphics stuff) causes problems and refuses to work at all if I am using dual monitors. Still working on this one.
Some Eclipse plug-ins no longer work
As a Java developer, I often use the Eclipse development platform. I include some non-standard plugins in the application, like plugins for Subversion support. However, when Ubuntu is upgraded to 7.10, the base Eclipse platform in upgraded, but not the non-standard plugins, which stops some of them from working.
Update: actually, this didn’t fix my Eclipse problems, please ignore
The solution is to upgrade the plugins in the usual Eclipse manner:
Running low on disk space after upgrade
My laptop was running out of disk space after the install, as it downloaded quite a few packages. I found a very good blog post on how to clean up your Ubuntu install at http://www.ubuntugeek.com/cleaning-up-all-unnecessary-junk-files-in-ubuntu.html.
Make sure to read comment #7 also, that alone saved me 1GB.
Some Thinkpad features no longer work
I found that some things didn’t work that did work before, for example the stylus pen and the middle ’scroller’ button of the mouse. If this happens, just reapply the settings I describe here, as the upgrade removed them. This solved the problems for me.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>In previous posts (here for the Dojo 0.4.3 version, here and here), I wrote how I wrote an image gallery for version 0.4.3 of the Dojo Ajax Toolkit, and how I was translating it for the latest version of the toolkit, version 1.0.
Well, that work is now, finally, complete, and I have to say, I’m pretty damn happy with the results. The code is now part of the dojox.image project (dojox is the Dojo extensions project, for cool new code that may in the future make it into the core code base if enough people like/want it).
If you’d like to just see the gallery in action, have a look at the Photos page on my personal website, or see the links at the bottom of the post, otherwise, read on!
Update: changes have been made to the widgets since this post was written, resulting in some badly aligned images. This will be fixed in the next few days. (Oct 25th 2007)
Update: issue above has been fixed (Oct 29th 2007)
The gallery is composed of three widgets:
Both the ThumbnailPicker and Slideshow widgets can also be used on their own, and have no dependencies on each other.
One of the coolest features of all of these widgets is that they all feed off image data provided by the dojo.data API. What this basically means is that each widget can display images from any source, with no modification whatsoever. You simply pass it a Dojo data store, and is shows the pictures. Some of the data stores currently in the Dojo toolkit include:
and many more….. You can also write your own data store if you so desire, but the ones included in the toolkit should cover almost everything you might need.
So, how can I get this, you ask! Well, you can:
Update: Dojo 1.0 is now released. Get it at http://www.dojotoolkit.org/downloads
As always, any and all feedback is welcome. Also, a big thanks to Peter Higgins, owner of the dojox.image project, and Jared Jurkiewicz, owner of the dojo.data project, for all their helpful ideas, and for reviewing/committing my code to the Dojo project.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
The previously announced Dojo Grid has landed in source control, and is in the nightly builds. It has all sorts of fancy functionality, like support for lazy loading huge data sets, individual styling of rows and columns, inline editing etc.
Check it out at http://archive.dojotoolkit.org/nightly/checkout/dojox/grid/tests/
Very cool stuff!
Update: The Sitepen guys have recently blogged about the grid at http://www.sitepen.com/blog/2007/10/13/dojo-grid-update/
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>I work on a number of open source projects, and many of them use the Subversion version control system to manage their code. Before my switch from Windows XP to Ubuntu Linux (which I am still ecstatically happy with btw), I became a big fan of TortoiseSVN, an extremely useful Subversion client that integrates itself directly into Windows Explorer.
TortoiseSVN is simple to use, very intuitive, and does everything I need from it. You simply right click on a folder you want to store your checked out files in, give it the URL of the Subversion server, and it checks out the code, updates it, checks it back in (if you have permission), performs file diffs ….. basically everything you need to do is integrated right in with your file browser.
So, I miss this in Ubuntu, as TortoiseSVN is Windows only. However, I recently found a replacement, which integrates nicely with Nautilus, the Ubuntu file browser. While it is not as slick as TortoiseSVN, it works in a very similar way. You right click on a folder, and have a selection of SVN operations you can perform.
See http://marius.scurtescu.com/2005/08/24/nautilus_scripts_for_subversion for details.
One thing that is missing from this is the display of icons in the file browser (Nautilus) to inform you of the state of a file - checked out, modified, not added to source control etc. Another person has developed a solution to this, which unfortunately I have not, yet, been able to get working, but perhaps you will have more luck.
See http://www.kryogenix.org/days/2006/09/12/extremely-noddy-tortoisesvn-for-the-gnome-desktop for details on this.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
I’ve recently submitted a new data store for the Dojo Ajax Toolkit that makes it very simple to query Flickr for your and other peoples images. For those not familiar with Flickr, it is a photo sharing website, one of the most popular on the net. However, what makes it quite special is the comprehensive public APIs that it exposes.
While these APIs are extremely useful, however, they are also very complex, with a steep learning curve before you can even get started. In steps Dojo and their new Data API specification, whose stated aim is to have a single unified interface to all data sources, so that users of a data store won’t have to care if they’re reading from a database, from a XML or JSON file, or from some remote service like Flickr.
So, long story short, I’ve written an implementation of the Dojo Data APIs to query data from Flickr. It is part of the DojoX project, and is called dojox.data.FlickrRestStore. It provides quite a few methods of querying for photos:
FlickrRestStore also performs caching of image data, so if you request the data twice it won’t make a second remote request.
The store is also designed to be accessed by multiple clients simultaneously. If two clients request the same data, only one request is made, with both clients being notified of the identical results.
Examples
I’ve put a fairly comprehensive set of examples in the Dojo book at http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo
/using-dojo-data/available-stores/flickr-rest-s#examples .
You can see a Demo of it running at http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/data/demos/demo_FlickrRestStore.html .
The unit tests cover quite a few cases also, and you can see them at http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/data/tests/stores/FlickrRestStore.js
To get the code, you can:
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>Flickr is a photo sharing website that has a very flexible set of APIs that other applications and websites can use to access the photos it stores. This post shows you how to specify a callback function that Flickr can call to pass your web application information on photos it stores.
Quite a while ago I looked into the Flickr APIs for a website I was writing. Looking at the service that returns photo data in JSON (Javascript Object Notation), I noticed that it did so by calling a predefined function, jsonFlickrApi, passing in the data to that function. This seemed to be an obvious weak spot, since if more than one widget on a page were accessing the Flickr REST services, they would clash with each other, possibly receiving each others data. Obviously not a good thing.
Cut to today. I’ve been working on a JavaScript data store that operates against the Flickr REST services for the Dojo Ajax Toolkit, and had another look at the Flickr APIs. Now, whether I missed it before (doubtful, as I looked specifically for it), or the fine Flickr folk have listened to complaints (very likely), but there is now a parameter that can be passed to the Flickr API that specifies the callback function to use when the data is retrieved from Flickr.
All you have to do is pass a parameter jsoncallback to Flickr, with the name of the function you want to be called with the data, and thats it.
E.g. if I had a function:
function myCallbackFunction(data) {
alert(”I received ” + data.photos.photo.length +” photos”);
}
I could then specify a <script> element in my HTML page to retrieve the data in a cross site manner (since you can’t make cross site XmlHttpRequest calls), like so:
<SCRIPT type=”text/javascript” src=”http://www.flickr.com/services/rest/?format=json&jsoncallback=myCallbackFunction
&method=flickr.people.getPublicPhotos
&api_key=8c6803164dbc395fb7131c9d54843627
&user_id=44153025%40N00&per_page=1″>
</SCRIPT>
Note the jsoncallback parameter in the src attribute. This results in JavaScript similar to:
myCallbackFunction({”photos”:{”page”:1, “pages”:489, “perpage”:1, “total”:”489″, “photo”:[{”id”:”1352049918″, “owner”:”44153025@N00″, “secret”:”5636009306″, “server”:”1111″, “farm”:2, “title”:”The Liffey Panorama”, “ispublic”:1, “isfriend”:0, “isfamily”:0}]}, “stat”:”ok”});
being called.
Thanks Flickr! Nice to see them listening, and continually improving. This will make web applications built on Flickr much more robust, without the need of ridiculous hackery to get around unnecessarily difficult APIs. See http://www.flickr.com/services/api/response.json.html for the offical info on JSON responses.
Keep an eye out for my dojox.data.FlickrRestStore being release some day soon!!
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
In a previous post (see here) I spoke about how I’d written an Image Gallery widget that worked with Dojo Ajax Toolkit version 0.4.2 and 0.4.3. I contacted the good folks at Dojo about updating it for the latest release, 0.9, and adding it to the toolkit.
They were very receptive to the idea, with a few suggestions. Firstly, rather than having its own method of storing information, it should run off the dojo.data API, and secondly, it should go into the newly created dojox.image project.
Both of these suggestions were perfectly reasonable, so, cut to a few weeks later and I’ve finished my first pass at converting over the code from 0.4.3 to 0.9. As the Dojo APIs have changed drastically recently, this was no simple matter, but thats the subject of another blog post.
The code is not finished (or even checked in) yet, but you can see some examples of it running from test pages. There are two separate widgets:
Finally, I’ve implemented a dojo.data store that reads from the Flickr REST APIs, to pull down lists of photos. This store is more complex than the existing Flickr store, as it does caching of results, as well as going against a much more flexible API, meaning that expanding its capabilities later is possible.
Whether or not this goes into dojox or not is still undecided. However, you can see the widgets running using this data store.
See the test files at http://www.skynet.ie/~sos/js2/dojox/image/tests for examples of this working.
Note that this is NOT the final code. It may still be buggy, may look different in the future (it’s pretty basic now), and the code will be cleaned up. However, if you have any suggestions, please feel free to leave comments on this post.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>When working with the Dojo Ajax Toolkit and using it’s dojo.event package to listen to DOM and custom events, the two most common approaches are:
This basically says that when the “onShow” function is called on some widget, called myWidget, run a function that does a simple alert. Of course you can do whatever you like inside this function.
This is saying that I have an object called “myObj“, which has a function called “alertFn“, and when the “onShow” method on “myWidget” is called, call the “alertFn” function on “myObj“.
I’ve found that when working with Dojo version 0.4.2 and 0.4.3, using the second approach is far far quicker. It turns out that internally, if you simply pass an anonymous function to Dojo, it will add that function to an internal structure and do a brute force search on that internal structure to make sure that this function is unique. This can result in a very significant performance hit - I’ve seen it take up over 50% of the startup time of a page on one of our more JavaScript heavy applications.
So, the conclusion is that if you are dojo.event.connect, which is one of the most useful functions in the toolkit, make sure to use four arguments to the function (approach #2 above), rather than just three (approach #1 above). If necessary, place a simple wrapper around the function as I have shown.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
The latest version of the Dojo Ajax Toolkit has just been released into the wild. Version 0.9 is a very streamlined progression of the toolkit, with many of the less essential features pushed out to another project, DojoX, and the Dojo widgets given their own project, Dijit.
Another big change is the the main JavaScript file in Dojo, dojo.js, is no longer customisable. It now contains the most common features required by most web developers, and nothing more. As a result, it is far smaller than previous incarnations, down to ~24k when gzipped.
Some resources:
James Burke has written up a very informative post about what exactly is baked into the default build of dojo.js, which you can find at http://dojotoolkit.org/2007/08/22/dissecting-0-9s-dojo-js . Well worth a read.
Bill Keese wrote up a guided tour of 0.9 at http://dojotoolkit.org/2007/08/20/dijit-0-9-guided-tour.
The Dojo book for version 0.9 can be found at http://dojotoolkit.org/book/dojo-book-0-9-0. It’s almost finished (almost!) as of today, Aug 22 2007.
The Ajaxian post on Dojo 0.9 can be read at http://ajaxian.com/archives/dojo-09-final-version-released.
Download the toolkit from http://build.dojotoolkit.org/0.9.0. This page gives some information on how you can use Dojo from AOL’s hosting servers, so you never have to download it at all.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
The Dojo/Dijit (Dojo’s widget project) toolkit has created a page where you can view many of their widgets using the four CSS themes written so far for Dojo. This is cool for a couple of reasons.
Firstly, it showcases the excellent work the Dijit developers have put into new themeing skins. There are four themes completed so far, and changing the look of Dojo is now as simple as including a different CSS file on your web page. All Dijit widgets now run off a single CSS file, rather than each having their own CSS file.
Secondly, it shows the usage of many of Dijit’s widgets (say that five times in a row! ). Many of the demos from the 0.4.* days are gone now, and this is about as comprehensive a demo of Dojo’s widgets as you’re likely to see for a while. And yes, they are very nice indeed.
Go to http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html to see the default theme (tundra) in use. Click on the “Alternate Themes” tab at the bottom of the page to switch themes to one of the alternate themes.
Enjoy!
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>Yahoo have released a very useful extension for Firebug, which is itself an extension for Firefox, which can be used to analyze a web page’s performance. The extension, called YSlow, appears as a separate pane in Firebug, and gives you a whole load of statistics about your page.
However, in addition to the bare numbers, it also gives your page a ranking, from zero to a hundred, and offers tips in plain English on you can improve the performance of your page.
All in all, a very handy little addition to a web developer’s toolkit.
One caveat is that it is of course not perfect - I tried to use it on Gmail, and it gave the site a 98% mark (practically impossible to achieve in reality), as the initial page of the Gmail application simply loads a single JavaScript page and not much else. Therefore, YSlow seems to only analyze content sent down the wire to browser upon page load, and ignores generated content. However, this does not take away from the fact that it is perfectly suitable for the vast majority of websites out there.
More information available here, or read Ajaxian’s post here.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
I have created an Image Gallery widget built on Dojo 0.4.3 that integrates nicely with Flickr. The widget it written entirely using JavaScript and CSS as a standalone Dojo widget, and is released under the same open source license as Dojo, the Academic Free License.
For more information, including the code and examples, see http://www.skynet.ie/~sos/ajax/imagegallery.php.
Some of the features of the widget include:
The widget can be instantiated from both HTML markup and programmatically in JavaScript.
To view your own Flickr pictures on the widget, without installing it on your own site, go to http://www.skynet.ie/~sos/ajax/yourpics.php .
There is a discussion thread in the Flickr API group at http://www.flickr.com/groups/api/discuss/72157600624623643.
So, why create this widget? Well, firstly I wanted a JavaScript image gallery that would list thumbnails and allow me to page through Flickr photos. Also, a slide show would have been nice. I was surprised to discover that I couldn’t find one that I liked in the twenty or so minutes I spent looking for one. I found a handy Flash based one, but I wanted a HTML and JavaScript only widget. So I grabbed Dojo 0.4.3 (my JavaScript library of choice right now) and wrote one.
Here is a screen shot:
The widget has all the features that I personally require at the moment, but will probably evolve as I think of new things to add. If you have any suggestions/bug reports, please comment on this post.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
]]>The two main areas of interest for me over the last year or two, blog-wise that is, have been the Dojo Ajax toolkit, one of the more popular open source JavaScript toolkits, and Ubuntu Linux, the very popular operating system that is seen by many as the best chance Linux has of succeeding on the desktop.
Due to the fact that my blog is hosted on Wordpress.com, I am provided with very detailed statistics on which blog posts are more popular, what days they are accessed on etc. Looking at these, a very definite trend has become apparent
While the number of hits received by the Ubuntu blogs remains more or less steady, hits on Dojo blog posts falls dramatically on the weekend.
While this is not an exact measurement by any means, it points to a worrying possibility. People are obviously working with Ubuntu on their spare time, installing it, upgrading, adding applications and window managers etc, and need help doing this. They are personally interested in Ubuntu, not just professionally. This is one of the main reasons for Ubuntu’s success - people are excited and motivated by it. They want to work and play with it on their own time.
This does not seem to be the case for Dojo.
Dojo has the backing of many large and small companies, including two I have worked for, my previous employer IBM, and my current employer Curam. Both of these are attracted to Dojo for a number of reasons, chief among them being it’s good design and wide range of features. The very large size of the toolkit is not a problem for them (and corporations in general) because it will be included in websites that employees will use to do their everyday work tasks (e.g. using a corporate installation of IBM WebSphere Portal), so the JavaScript is cached and the performance hit is avoided.
However, for hobbyists, this is not the case. A person might only visit a single page on their website, and a ~200KB overhead for perhaps something simple like a collapsible menu and some fading effects is simply not feasible. I’ve experienced this recently when writing a simple website for myself - all I wanted was some fading/sliding effects, but the huge overhead just wasn’t worth it. And I am a very big supporter of Dojo (I’ve contributed code even - here and here), and use it every day at work.
The Dojo team are working hard on the 0.9 release, which is addressing many of these issues, bringing the base size down to a more manageable size (at time of writing dojo.js is down to 68KB). I look forward to the day when my site statistics change, when Dojo can stand on the shoulders of many thousands of enthusiastic hackers rather than being held up by a few big corporations. I really do.
However, this does not seem to be the case today. Version 0.9 has a lot of work to do.
Share this post: digg it|kick it|Email it|bookmark it|reddit|liveIt
I’ve created an example usage of the Dojo Charting engine, which you can find at http://www.skynet.ie/~sos/pageStats.php. View the source to see how it works.
It’s a modified version of the unit test available with the Dojo toolkit, but used in a specific scenario - in this case, to graph the page impressions for my personal website . The JSON data on the page is dynamically generated by PHP, however all other processing is done in JavaScript.
You can filter the data to show info on any combination of pages, and also use a number of different chart types.
The code is well documented, so should be easy to follow.
Some other good examples of using the Dojo Charting engine can be found here and here.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
I decided today that I wanted to put links at the bottom of each of my blog posts that would allow people to perform actions on the post, e.g:
My blog is on Wordpress.com which doesn’t seem to have a plugin that will allow me to do this. So, I got off my ass and wrote a GreaseMonkey Firefox script that’ll do it for me. You can download this script by going to http://userscripts.org/scripts/show/9421 and clicking the “Install This Script” button.
The links that are inserted are at the bottom of this post. The script is open source (GPL license), so take it, play with it, whatever. If you find any bugs, please let me know by commenting on this post.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt
Bill Higgins of IBM has written a very well thought out article of why web applications should look and act like web applications, and not the desktop variety. Well worth a read - http://billhiggins.us/weblog/2007/05/17/the-uncanny-valley-of-user-interface-design
]]>