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 :)

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/widget/tests/test_RollingList.html

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;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/data/demos/demo_GoogleSearchStore_Grid.html

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;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dijit/tests/form/Form.html

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;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.3/dojox/widget/tests/test_Wizard.html

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 :)

Cheers,
PS

Continue Reading...

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 dojo.data 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 dojo.data;

http://www.sitepen.com/blog/2008/06/13/restful-json-dojo-data/



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.

Cheers,
PS

Continue Reading...

The power of Dojo i18n

I had said at an early stage that I was going to use Dojos i18n system to translate snippets of text in World Change Network. Now that the time came to actually implement it, I realized I had some learning to do to get all bits and pieces right. As it turned out, using Dojos i18n system for you own purposes is really simple.

If you take a look at the unit test for i18n at http://download.dojotoolkit.org/current-stable/dojo-release-1.2.2/dojo/tests/i18n.js you see that it uses three major tricks;

1. Load the i18n strings bundle of your choice using dojo.requireLocalization("tests","salutations",locale);

2. Get a specific bundle using var salutaions = dojo.i18n.getLocalization("tests", "salutations", "en");

3. Get the specific string for a given key using salutations['hello'];

Let's check the arguments for number (1) and (2; Only the first two are needed, which describe the dojo package to look for bundles in and the name of the bundle. If you want to specify another locale than the one the browser declares, it can be added as third argument, "sv" for Swedish, when the browser would say "en-us", et.c.

All well and good, but where do we put our different version of strings? As it turns out, in the dojo/test directory a directory named 'nls' can be found. In the root of that is a file called 'salutations.js'. This is the default key-value translation that i18n falls back on if the locale cannot be found.

Then comes a host of subdirectories ; zh, nl, il, dk, de, et.c et.c., one for each locale (that you want or can define). In each of these is a separate 'salutations.js' containing locale-specific resources.

The file format look like this;

{

it: "Italian",

ja: "Japanese",

ko: "Korean",

......

hello: "Hello",

dojo: "Dojo",

hello_dojo: "${hello}, ${dojo}!",

file_not_found:"The file you requested, ${0}, is not found."

}

for the default file, and like this in the 'it' subdirectory;

{

it: "italiano",

hello: "Ciao"

}

And that's it.

I began creating a small naive custom widget, which subtituted the content of the element where it is declared with the localized string found for the content used as key. It's not very fast, but simple to understand and use.

dojo.provide("layout.translate");

dojo.require("dijit._Templated");

dojo.require("dijit._Widget");

dojo.require("dojo.i18n");

dojo.declare("layout.translate", [ dijit._Widget ],

{

widgetsInTemplate : false,

string : "",

postCreate: function()

{

if (!this.string)

{

this.string = this.domNode.innerHTML;

}

console.log("postCreate for layout.translate called. locale == '"+dojo.locale+"'");

dojo.requireLocalization("layout", "salutations");

var res = dojo.i18n.getLocalization("layout", "salutations");

console.log("Translation key was '"+this.string+"'");

var str = res[this.string];

this.domNode.innerHTML = str;

}

});

Note that I just copied the whole nls directory from dojo/test for my own uses, and edited the files, leaving the original filename intact, just in case :) A better way of utilizing i18n would be to have a base class for all custom widgets, which read in a i18n bundle, and injects all keys into each class, so that every subclass has a lot of this._i18n_command_delete (If we have a naming convention that let all i18n keys begin with '_i18n_' for example).

Then we could have all custom widget templates just sprinkle their markup with a lot of ${_i18n_command_delete} and so on, which would pull in the current value of that 'this' property of the widget when it is rendered in the page.

Hmm....

Come to think of it, it seems to be possible for this to be put inside dijit._Widget, or possibly _Templated, which would make it spread to all custom widgets automatically. The only thing needed would be to prepend '_i18n_' to all key names, so that 'command_delete' inside a bundle file would become this_i18n_command_delete in the widget.

One would also need to have a convention that this only worked if the developer put a 'nls' directory under the package directory where widgets of a certain package are declared, following the order declared earlier.

Actually, this would be a pretty neat idea. Just my fault for using a blog post instead of TRAC to add feature requests! Oh, you mean I could do it myself? OK, I'll add it to the queue :)

Cheers,
PS

Continue Reading...