Java is a few hours away from being open-sourced under an GPL2 license. I guess this was a long time in the coming but it is still a very significant change. It was never my favorite programming language but there is no denying that it is one of the most important, as in widely used, programming languages around.
Normally i wouldn’t post about yet another google aquisition but this time ’round it’s sorta interesting since Jotspot is totally based on the Dojo Javascript toolkit. So did they want the wiki or the killer JS team? And does this mean Google will become a Dojo contributor?
I guess RubyOSA sort of like what we should be able to do in Leopard when it ships, only available right now. If RubyCocoa is a bit much for your tastes this gives you a nice interface to some workflow enhancing programming.
I just migrated a reasonably large project over to the latest Dojo release 0.4, and since i ran into a few basic gotchas i thought i would share some of the stuff i ran into here for you to compute.
If you have no idea what Dojo is and do no not usually slap Javascript with a large stick for fun and profit feel free to not read this post at all.
If you have been dutifully adapting your Javascript/Dojo code to be compatible with the nightlies you probably won’t run into any of these issues, if you (like me) were still stuck in 0.3.1 on the other hand you will probably run into these issues yourself.
The new namespace system
There used to be a time when you simply set your paths and required everthing you needed. 0.4 features autoloading though, which seems to lighten the load on my server so it’s heartily recommended. When you are running custom widgets you might need to make some adjustments though.
You used to be able to get away with lot’s of these:
dojo.require("acme.widget.MyWidget");
No more! You need to delete those require statements and instead add a manifest.js to the directory where your custom widget lives. This make my new setup look like this:
First we add the good old HTML to load the Dojo library in the head of my page. The reference to dojo.js loading the library, the post_dojo.js containing the bootstrap code to get up and running. Nothing has really changed here.
<script type="text/javascript" src="/js/dojo/dojo.js"></script>
<script type="text/javascript" src="/js/post_dojo.js"></script>
But the contents of post_dojo.js has changed; acme are directories containing my custom code which live next to the dojo directory in my js directory. Since registerModulePath() needs paths relative to dojo this becomes; ‘../acme’.
// load widget handler code
dojo.require("dojo.widget.*");
// Load user custom widgets
dojo.widget.manager.registerWidgetPackage('acme.widget');
dojo.registerModulePath('acme', '../acme');
So the above code will work for this directory structure:
{webroot}/js/dojo/dojo.js
{webroot}/js/dojo/{more dojo code here}
{webroot}/js/acme/
{webroot}/js/acme/widget/{my custom widgets here}
As you can see i am not requiring all the widgets i need from my acme directory like i used to in Dojo 0.3.1. Instead 0.4 offers autoloading which loads the widgets when they are encountered in the page or requested from code.
The new manifest.js file
For this to work dojo still needs to know what is available though. To achieve this you place a manifest.js file in your custom widget directory. In my case manifest.js contains the following code:
dojo.provide("acme.manifest");
dojo.registerNamespaceResolver("acme",
function(name){
var map = {
"mywidget": "MyWidget",
"myotherwidget": "MyOtherWidget"
}
return "acme.widget."+map[name];
}
);
As you can see i have to translate the request for a lowercase named widget to the uppercase name by which it is known in your code, as well as tell dojo in which directory or javascript file they live. If you keep all your widgets in one big file you resolver function could simply return the name of that file.
Calling widgets from HTML
Although Dojo makes it possible to create widgets from code i like to use the built-in functionality to create widgets from HTML. This way i can make a non-javascript version first and then simply ‘overlay’ this version with my javascript widgets thus making sure that non-javascript enabled browsers also receive a usable page. In Dojo 0.4 i would create a widget from HTML using the following code:
<input name="search" value="" dojoType="acme:autoComplete" acme:locale="nl-NL" />
The above code will load a widget called autoComplete in our custom acme namespace. Furthermore it will set a local variable in this widget called locale to the value; “nl-NL”. In Dojo 0.3.1 there was no need to include the namespace in the dojoType and locale attributes, in 0.4 there is.
sidenote: in 0.3.1 it was possible to load a widget from a class attribute by typing something like class=”dojo-autoComplete”. Sadly class=”acme-autoComplete” does not work so there is no good way to make your pages totally W3C validated for now. This will probably be resolved in the near future though.
Other Changes
Besides the new namespace structure you are bound to run into some deprecated methods. In my project i had rename references to the dojo.style.* package to dojo.html.* and dojo.html.style.*.
After that i had to remove a few remaining calls to this.extraArgs. In the code above for instance i used to be able to read out the value of my custom locale attribute by saying:
localVar = this.extraArgs.locale;
extraArgs does not exist anyomre so this simply becomes:
localVar = this.locale;
And that was it. About an hours work all in all and my complete project is now running 0.4. A noticably faster version of Dojo that adds a whole slew of bugfixes and interesting new functionality.
* Ik kreeg bij pixmania de optie mijn bestelling via Kiala te laten bezorgen naar een sigarenwinkeltje om de hoek. Simpele doeltreffende oplossing voor het probleem van online bestellen * Ik ben apetrots op mijn vriendin Sylvia die onderzoekers en conservators blij als kinderen achterlaat na een staaltje photoshop goochelen. * Gisteravond de lokatie voor ons RoomWare project uitgecheckt en die is perfect, midden in de stad en zeeen van ruimte. Iemand nog tafels over? * Judging from this spiffy wiki RubyCocoa is finally getting some traction. Last time i looked most docs were in japanese. I wonder how this compares to the ruby system bindings in Leopard… *
At RoomWareDevHouse we intend to investigate possible applications, host discussion and do some hacking while enjoying a tasty beverage. The event is free and anyone interested can attend as long as you intend to participate.
Loosely styled after SuperHappyDevHouse we hope to talk about and even build some of the applications that we will display at a later RoomWare event. Furthermore we intend to start development on an open source RoomWare platform that anyone can build on to provide RoomWare applications at their own event or location.
The event is on Upcoming too…
update: meer op BlueAce en Katie’s vlog.
I made a simple widget that allows you to show the latest forum posts in widget enabled wordpress templates for our PussyCat Lounge blog. It might be useful to somebody else so download ahead if you use XD Forum:
xdforum.php.zip (version 1.0).
To use it follow the these steps:
Leopard Preview reportedly ships with Apache 2.0, Ruby on Rails and Subversion. It also adds support for script-to-framework programming, allowing Python and Ruby scripting to access Mac OS X specific programming interfaces.
Would be nice if this no longer was an issue: the solution to the tabs-versus-spaces issue
I was using the new defineWidget since i saw it in a presentation by Alex but Brian McCallister has taken the time to actually write down how it works. Good stuff.