Thursday, May 22, 2008

Going to San Francisco

So, this Saturday me and the rest of the family (sans cats) will blast off from Arlanda airport, Stockholm, bounce at O'Hare in Chicago and land 17 hours later in San Francisco.

The reason for this extravagance is Google I/O, which I'll be attending. I haven't made up my mind yet what sessions I'll be going to. All seems to be a hard option :)

Anyway. It was almost ten years since I last was in SF; so it'll be great to be back again. If you know of any really nice kid-friendly restaurants (apart from the Pier and McD!) and/or know of any geek-friendly activities in the neighborhood, please comment or mail me directly (see address in the sidebar).

The main problem is to find another Hotel where we can buy admission to use the pool, since ours don't have any. The reason for that is that it's hard to explain to a six-year old girl why there's no pool in the Hotel, that's why :) I've bought Naruto's for her brother, so he'll be OK.


Thursday, May 15, 2008

The elusive Dojo Treetable

I just got a mail from David Silvestre, who asked me about how to go about building a Dojo Treetable. You know, the sortable table thingy where you can expand and collapse each level just like a tree, but it still retain all columns for everything it shows?
Anyway, I had do one of those last winter, for a project, and spent a large amount of time trying make Dojo's existing Grid and/or Tree usable to do what I wanted, and ultimately failed.

Here's my short notes on how (to the best of my recollectionary faculties) I did it;

I found a couple existing treetables, especially one for jQuery, but in the end I had to make one myself to understand what I was doing. I recommend you to do the same.


1) Create a simple custom widget (see my ultra-light tutorial here;
2) Create a table (remember to use , et.c. otherwise IE will barf :) in the template for it
3) You have a hierarchy of data (an xml document, no doubt).
4) Use dojox.xml.DomParser to get a traversable object (still horrible but hey) of the XML. (I have some examples on how to use it if you need)
5) Create an array of object trees out of the xml object. I mad an array indexed on 'name', where I created an 'artist' object and stuck it there, and under that I stuck and 'album', followed by 'song' object. You get the picture.
6) When the array is done, you parse it (could possible by done in one step, I guess) and create an image and a subtable, and add that to the single td of the overall table
7) I recurse the object tree for each array object, and create a new image and table, which gets tucked inside the single td of the parent table, until there are no more object levels.
8) I now have a table with a table in in with a table in it, et.c.
9) The image (+ or -) beside the table has an onclick handler which shows or hides the table it is handling. Thus you can get smooth animations and hide/show all or some things that you already have open, according to which level you click the image on.

Now that I've written it out, it does sound a bit harder than it felt, but the hard part is realy to parse the xml data and create a usable structure. After that it's (just) a recursive table making function. Sort of :)

Actually, I think I'll post this to my blog, since it's at least a rough sketch for someone else in your position.

Hmm.. Maybe this could be a real Dojo component. Maybe.. err.. in autumn :)


Monday, May 12, 2008

Teaching === Learning

I spent most of the 90's teaching various networking technologies to people (Novell's NDS, Microsoft's passive directory, TPC/IP, et.c). And if there's one thing I learned from that experience(except what a challenge some students can be :) is that you just think you know something until you've tried to teach it.

And conversely, after having survived a dozen courses you can finally say that you've mastered the subject (for the level you're teaching, naturally). It's not enough to read the books over and over, and it's not even enough to work with it day in and out (though it's even better). If you're not forced to take one step back and actually formulate a personal theory about how things work, you'll never truly grasp a subject.

There's no magic here, only a specific level of effort and - maybe - will. One always strive to do the least in any given situation. I would classify this as a property tied not to Swedes in general or even humans in general, but to all life, period.

So the trick is to put oneself in a situation where above an beyond call of duty become the least possible effort. That way is to write a book :)

I thought I knew a bit or two about Dojo before i began, but that's nothing compared to what I know now. Unfortunately that's still meager catch compared to what I now see available. Well, I won't die bored, that's for sure.

This weekend I finished chapter three of "Learning Dojo", which would be an overview of how Dijits (Dojo's widgets) work. What struck me was that I found a lot of things that I've been looking for, but have had to hack brute force the last year.

For instance, if you're creating a custom widget (and, let's face it, that's the way you work) you often want to access the DOM nodes in the template for various reasons, from you widget class. I had resorted to misuse the basic template variable substitution in Dojo, which lets you use ${} syntax in the HTML template of a widget to directly insert 'this' level variables. My templates looked a bit like this;

div id="${id}_dialog" dojotype="dijit.Dialog"\>div id="${id}_dialog" dojoType="dijit.Dialog"\>...\/div

This will lead Dojo to automatically insert the id property of the widget into the variable, so that if the id we had given our custom widget was 'foo', this node now had an id of 'foo_dialog', which modularized stuff in a good manner, so as to not collide with other instances of the same custom widget in the page, et.c.

When I started writing about attach points, I realized I was very unsure about how they worked. I re-read the online documentation and couldn't really make heads or tails of it. Finally I started testing ideas of how attach points might work in a small test widget.

What I did was the following;

div dojoAttachPoint="dialog" dojoType="dijit.Dialog"\>...\/div

And then I suddenly had a new property in my widget class called 'dialog', or 'this.dialog'. Strange huh? :) As it turned out attach points was what I had been doing all along, only slicker and truly integrated. They work for ordinary DOM nodes in the templates as well, the property just is a reference to the DOM node instead of the widget.

I learned a lot more things during the course of writing the chapter, but I'll get to them in another post. The attach point conundrum has been bugging me or quite a while, so I just wanted to blog about it for some for chap who like me, really needs it but doesn't grok the online dox :)

Tuesday, May 6, 2008

Cutting my Karma some slack

It seems like everybody goes into crunch-mode this time of year, almost like migratory birds or something. Naturally, so did my client.

This led to a lot of positive things, most of all the smart timeseries hack which I hope to build something out of as soon as I've gone through the latest changes the Eugene has made to Dojo's stellar charting engine. But also a deeper understanding of Dojo in general. Every week I'm able to crank out one or two Dijit's for some custom need, that make the client happy without disturbing the server guys (since we're using TSA/SOFEA architecture here, hello?)

On the down side, my work with getting the Bunkai architecture finished all but stalled. Let's see why this happened:

1. The first Bunkai verison was a (very) quick hack with no respect for extendability whatsoever. I did maybe a dozen things large and small, that I've never done before.
2. The revamp was fairly ambitious, using a pluggable message bus for both editors and resource loaders, so that you can have any amount of loaders (Sling, GData Google documents, static examples, et.c.) open at any one time, which lets you browse the resources as trees. You can have the same resource open more than once and you can close and open it again, et.c. This works now. (although only Sling and static).
3. The editors are also (as said) pluggable, which in theory can let you have the same resource up in two different (or same) editors, which communicate changes between each other (the message bus again, natch! :) This only works partiall at the moment., due to..
4. Some weird Dojo behavior, when adding Tabs dynamically. I've tried this with a number of components, and they all react the same way; When I create a tab and add (and editor) to it, the editor component gets rendered inside the upper part of the tab where you click to switch between tabs. When I add another tab, both gets rendered correctly. Yes, I've tried refresh, Yes I've tried doing it backwards, using containers and calling layout, what have you. This is odd.

Anyway, what I did have did work inside the Sling repository, so now I've mailed it to Lars (Trieloff) to pick apart and throw it back at me hard, but for the moment I feel I've at least moved the boulder forward.

Then there's the book, which should have had a finished chapter 3 (Introduction to Dojo Widgets) done weeks ago. My only defence here is that I haven't been procrastinating any more, I've been dead busy! But still.. I managed to find a couple of hours last night and push it up to ten pages (out of an estimated 32), so at least it's moving forward.

Also, my game-writing depravities has luckily been put on hold while some of the fruits of that effort have been used in writing a tentative Google Application Engine db.Model object -> JSON converter. Actually I began to write it as a SMD file exporter for db.Model objects, so that it created a full SMD (simple Method Description) json file, to be consumer by Dojo rpc objects, and create client function endpoints to call server-side objects directly.

But then I realized that it was silly, and that each object would only have four calls anyway (CRUD- Create, Read Update, Delete). So now I'm just exporting object properties.

The upside of this is that I'm able to continue doing the dojo Grid integration for the World Change Network. I'm nearly there, so expect some news this week. What's nice is that I now have a model for GAE which let you have any db.Model object inside GAE and get a Dojo tree and/or Grid together with a create/update Dialog. That means that you can just create some mobjects and get an admin-interface in a can - using two pages of python code and just Dojo. Schweet :) Roberto Saccon is working on something similar, so we're going to integrate our stuff soon.

And speaking of ROverto, I remember promising him that I'd port Christophe Dolivet's exellent EditArea source code editor as a Dojo Widget. I've actually started on that, as I'd like to streamline the loading process for Bunkai, anyway, but as always, everything takes time. Just my good fortune I don't try to do any of this in Java huh? :)

And speaking of source code editor widgets, I've *still* not checked out Marijn Haverbeke's _also_ truly excellent JavaScript source code editor (which as well as EditArea support html, php, js, and a lot of other syntax). But since Christophe made me co-developer for EditArea I suppose I have to go through with that first.

And I'm looking forward to coming to SF in just under three weeks, for the Google I/O event. This will totally rock, I'm telling you!

So, back to client coding..