Friday, January 23, 2009

Using Dojo to implement the 12 standard screen patterns

I really enjoyed reading Theresa Neil's article just recently on the 12 standard screen layout types. She gave a lot of examples, but what I found lacking was some nice templates that could be used if you wanted to jump right in and implement one or two of the patterns. I've been meaning to write a post about Dojo's Layout containers for a while now, so my initial idea was to provide Dojo examples to each of the 12 screen patterns.

As it turns out, not all patterns exist today as plain off-the-shelf examples, I decided to skip some of the patterns, since my blogging time is a bit limited, and just bite the bullets that I can quickly show.

Since we've just concluded that I'm really lazy, It will come as no suprise that I'll just provide links (where possible) to existing Dojo unit tests, that can be copied straight off (possibly changing where the css and js loads from, but I assume you're familiar with such procedures)

1. Master/Detail

[Would be simple to do with StackContainer. I have a releated, flipped example here, which loads html page snippets using Ajax and flip them over 'hypercard'-like when menu selection changes]

2. Column Browse.

There's actually a faily new Dojo widget that provides this 'mac explorer' kind of cuntionality. Data source riven and all. Verry snappy :)

3. Search / Results

This pattern is of course the perfect fit for Dojo's DataGrid with filtering queries to the data store from where it draws its contents; Note that the example uses Google's cross-domain JS API to get the data which the grid is filled with;

4. Filter DataSet.

This is also a tricky one to find as-is. Several data stores in Dojo support complex queries, and creating a filtering panel that let the user apply filters to the tiems retrieved from the data store is not particlarly hard. Mail me or comment here if you really want an example, and I'll post one later.

5. Form

No worries here. There's forms galore;

6. Palette / Canvas

Due to Dojo's unique cross-browser native 2D api, which detect if it should use SVG, VML, Canvas or Silverlight, there are several other DOjo API's which utilizes this for charting and other things. There'sfor example an excellent Sketching API which support manipulations of SVG files, as well as a related example in the dojox.gfx section. I chose these tests because they both provide a palette / canvas like experience, involving actual graphics. You should also check out openJacob's draw2D if you are the least interested in that kind of stuff :)

7. Dashboard.

This patterns has me a bit confused. Except for the charting / graphing widgets it seems to me to be similar to a form or something. Perhaps an assymetric DataGrid. Let's focus on the charting then. There are several good dojox.charting examples available, all which build on the work of dojox.gfx.

8. Spreadsheet

This is again a prime candidate for DataGrid, depending on whether to implement a real spreadheet or just look a bit like one. No exmaple included.

9. Wizard

OK, there's no widget for this - exactly- though the pattern would be fairly simple to implement. Again, mail or comment if you really want an exact copy of the pattern in Dojo. Meanwhile, here _is_ a Wizard widget, but it only shows one 'scren' of the wizard at any one time;

10. Q:A

I'm not really sure I get this one exactly. It is just #1 but over-confident, or what?

11. Parallel Panels

These we've got. and in spades. There's the obvious AccordionContainer, the classical TabContainer, as well as the fully hackable StackContainer.

12. Interactive Model.

This one covers quite a wide area. The emphasis seem to be on graphical interaction, which I'll have to get back to you for, because now it's time for lunch :)


Tuesday, January 13, 2009

Upcoming talks

So, it is a new year which brings new conferences with it. Yesterday I sent out three proposals to three different conferences, and just one day after, one of them answered! Yay!

The conference in question is Web Tech Exchange 2009 in London, May 14-15, and my talk is on the second day, entitled "Leveraging to build scalable enterprise applications". It does sound very interesting, doesn't it? :) Now all I have to do is write the actual talk as well.

But first of all I will do a free Dojo workshop at Svenska Dataföreningen this Thursday (15/1). I'll be covering basic Dojo widgets and how you take a simple page and add some stylish Dojo magic to it, maybe some data integration or dojox.charting if there's time for it. You have to register for it and bring your own machine. Oh, and have a local web server of some sort and download the Dojo 1.2.3 source distro as well.

Later this month I'll be holding an intense but character-building talk on Thin Server Architecture at the Swedish jFokus event, Januari 28-29.

Outstanding are stil my proposals for O'reillys OSCON2009 in San José and the NextWeb Conference in Hamburg. And do know that I need help with funding to get across the water, just so yo know. Thx! ^_^

If you want me to speak at your event, or need a workshop/course in Dojo for your company or organization, feel free to mail me at the address in the left column, or twit me at



Apparently, I will not be speaking at the jFokus event in Stockholm as I initially thought. I was urged to submit a proposal last fall by the organizers, which apparently didn't look as urgent when it came down to it :)

It might have something to do with me having broken up with Java and the event is _about_ Java. Maybe. Anyway, if you still want me to talk about thing server and all that jazz in Stockholm, please let me know and I'll arrange another venue if there's enough interest. The mail address is as always on the right side of the blog.


Saturday, January 10, 2009

What makes Dojo diferent?

Dojo (and also Ext, IIRC) have a couple of semi-unique features, being proper data abstractions in the client layer and extendable, hierarchical widgets systems.

I know Dojo best, so I'll use that as an example;

Data abstraction means a separate API layer between widgets (or other classes) and the actual data. All datastores (as they are called) have the same kind of API, but manages access to data differently. For example theres one store called ItemFileReadStore, which just read in a JSON object from an url and provide it as a bag of items to widgets.

Let's say that you use this data store to provide data to a combobox which implements type-ahead (which the Dojo one does). After testing you want to have a more advance data store which only fetches some items at a time (because the amount of data on the server is too large to load at once) and caches it. That means switching to the JsonRestStore, which uses the same API as the first one, et.c.

Here are some good articles that give more meat on;

The widget system in Dojo let you define custom widgets and place them on the page, using a single element with special properties. Dojo scans for these elements and look up the widget definition (in a JavaScript file and the HTML template for the widget (pointed out by the JavaScript file).

Dojo then calls special functions in the widget class according to lifecycle events, and also manage unique id creation for html template elements, instantiation of subwidgets, et.c.

Dojo uses this system for all its own widgets internally, and many custom widget projects I do for customers start out with subclassing an existing widget (using Dojo's pseudo- OO). The reason this work so well is that Dojo have proper namespacing, which also correspond (but can be overridden) to directory hierarchies, so class/widget lookup is both straightforward and understandable.

At the moment jQuery have no data abstraction or widget subsystem (unless I've misunderstood jQuery UI completely, in which case I would very much like to be corrected :), and neither have YUI.

Now I've done it again. :) This is my next blog post, apparently.


Thursday, January 8, 2009

A possible solution for siteful user authentication in friend connect

I just posted this to the gfc mailing list, but since it relates to my earlier post on google friend connect authentication, I'll recap here;

At the moment it's not possible to use a makreRequest call back to your server with the id and general data for the current vieweing gfc user, through Google's servers using SIGNED authentication. What that would mean is that googles servers guarantees that the data is correct and stamps it in a way, since they recently authenticated the user themselves.

Google _is_ prioritizing this, so we'll probably see a new release of the GFC API's that allows for this quite soon.

But what if you want to get the friend connect user id of the viewer anyway?

Although, having thought about this a bit, a weaker kind of security can be had if you just decide to trust the scripts running in the page.

1) You store your own custom xml file describing your own opensocial gadget on your server
2) You store the page containing the gadget on your own server.
3) When the page is loaded, it first load GFC from google's servers
4) The it tells GFC to load your custom opensocial gadget _through_ googles servers, acting as a proxy.
5) You could in essence generate the xml file containing the widget in a server-side template (ugh!) which contains a unique session cookie you keep track of on the server
6) When the widget snarfs viewer info et,c, and send it back to your server again, through googles server, using makeRequest, it also passes on the magic cookie
7) Then you might be reasonably certain that you haven't been fooled around with.

However, anything coming from the client should be treated with great scepticism, even if cookie is correct, the data collected might have been tempered with, resulting that you associate an action with the wrong user id. Still, I think this is a reasonably safe solution.