Please grab all phones you have and navigate to http://jensarps.de/tests/storage-tests/.

There are four tiny tests there. Please do them all and report your results for each phone. If you like, include your twitter handle so I can say thank you!

Your help is greatly appreciated!! Thanks a ton!!

Among other tests, the main thing I wanted to know is how long does it take to read or write 1000 entries from/to localStorage. The keys were of the form “key000″, the values “val000″, with increasing numbers. So the tests were using minimal data – only 6  bytes – but the results are still useful to get an idea of how it goes – and how the browsers perform compared to each other.

Desktop

All test were run on a Mac Mini. Opera and IE were tested on a virtual machine, so there might be an additional performance penalty based on virtualization. However, here are the numbers (average time needed to run the respective method 1000 times):

Safari 4:
- getItem: 1.4ms
- setItem: 1.7ms
- key: 0.8ms

Chrome:
- getItem: 240ms
- setIem: 280ms
- key: 230ms

Firefox:
- getItem: 77ms
- setItem: 2100ms
- key: 25ms

Opera:
- getItem: 19ms
- setItem: 20ms
- key: 18ms

IE8:
- getItem: 5ms
- setItem: 72ms
- key: 3.6ms

Mobile

As we can see, Safari is lightening fast. That made me want to run the tests on a mobile phone that has a modern Safari browser. I took an HTC Desire, wich comes with Android 2.1, and thus has a Safari capable of localStorage. Here are the results:

HTC Desire:
- getItem: 16.4ms
- setItem: 19.5ms
- key: 8.7ms

This is pretty amazing, considering that it is a phone. It still beats most of the browseres on the desktop.

If I find that test page again (uh, yeah, it’s lost somehow), I’ll run the tests again with newer browser releases and publish the link here, so you can run the tests yourself.

So here you go: dojox.storage.encrypted, a Blowfish encrypted storage. It sits on top of dojox.storage, and you get all the dojo storage manager goodness, mainly the automatic selection of the best storage provider available. It exposes the complete API that dojox.storage does. If an attacker gains access to the storage area, he can still nuke the storage, but the data found within will be useless.

I’m not completely happy with it’s architecture, and I didn’t have the time yet to fully test it with all providers, but it works pretty well with localStorage and the performance is not too bad. If you have a spare minute and are interested, feel free to to test it yourself (ah I know, you don’t have the time yourself, but I’d be thankful!)…

Usage

Just use it as you would use dojox.storage, except that you need to set your passphrase before you start working with the storage:

dojo.require("dojox.storage.encrypted");
var sto = dojox.storage.encrypted;
sto.setPassphrase("my super secret passphrase");
sto.put('key','value');
var value = sto.get('key');

It uses/requires dojox.encoding.crypto.Blowfish but that’s been in dojo for ages, so no worries.

To use it, just put the encrypted.js file in your dojox/storage directory.

Files

the code (encrypted.js)
the test page

The common way to persist data on the client side – application state, offline data, whatever –  still is to use cookies. But times have changed, and so have browsers, and there are better ways to do it today.

But why are cookies that bad? Well, here are the top three reasons:

1. Of all client side storage mechanisms, cookies have the worst limitation in size (4k if you want to stay IE-safe)
2. Cookies are sent to the server on every requests that matches the cookie domain – inlcuding XHR calls (aka. How to slow down your AJAX app)
3. Cookies perform bad, can be easily disabled, and, oh well, they are sooo 1995…

What else to use? There are several options, let’s start with the best:

localStorage

This is the storage mechanism proposed by the HTML5 draft. It offers you a fast, reliable key-value store with a whopping 5M (!!) of storage space. And here’s the kicker: It’s implemented in all current major browser releases. That is, FF, Safari, Opera, IE and Chrome/Chromium. Yes, you name it, all of them, the full list. To read more about localStorage, check the HTML5 draft. But here’s all you need to know in short:

Storage Methods

To test if the user agent supports localStorage, just test for the existence of window.localStorage. Working with the storage object is trivial:

Setting a value:

localStorage.setItem('key','value');

Though the draft says the user agent should write a “structured clone” of the value to store, don’t think that you can store objects – you can only store strings. To store objects, you need to convert them to JSON before.

To retrieve a value, there are two options. First, you can get a value by it’s key:

var value = localStorage.getItem('key');

The user agent will return the value for the key, or, if it doesn’t find a matching record, null. Also, you can retrieve a key by it’s index:

var value = localStorage.key(n);

The storage object has a length property, and n is a number between zero and length-1. You do not get the index of a value when inserting it, but you can use the key() method when iterating over all items in the store using the length attribute.

There is another method to retrieve a value, but as this not documented (at least I didn’t find anything about it), I do not recommend it:

var value = localStorage.key;

Deleting an item:

localStorage.removeItem('key');

Deleting the whole storage:

localStorage.clear();

This clears only the storage objects of the same storage area. That is, storage objects of the current domain.

So far, everything is pretty trivial, but let’s look at

Storage Exceptions

When accessing the storage object, a user agent may raise an SECURITY_ERR exception – but I have never managed to trigger one. When setting an item, a user agent may raise an QUOTA_EXCEEDED_ERR exception. This is not only for the case when storage space is at it’s limit, but may be raised for other reasons as well. Again, I have never managed to trigger it, but it may be wise to wrap a setItem call in a try/catch block.

Storage Event

Now things get tricky, and the different browsers have different (if any) implementations. Ok, first, the theory: methods that modify the storage object (setItem(),removeItem(),clear()) do not report if – or when – the changes are in effect. To get notified about this, you need to connect to the storage event:

window.addEventListener("storage", function(evt){
    // a change to the storage object has been attempted.
}, false);

The event should have the following attributes:

• key
• oldValue
• newValue
• url (the address of document object whose storage object was modified)
• storageArea (the affected storage object)

With this information, you can easily determine to what change the storage event belongs. But, alas, that event is not fully implemented everywhere. Here’s what I found out:

FF 3.6.3 lets you connect to the event, and fires it according to the draft. But it does not contain *any* of the fields mentioned above.

Safari 4.0.5 lets you connect to the event, and fires it according to the draft. It’s event contains all attributes except url.

on Chrome 5 & Chromium I couldn’t connect to the event at all or it wouldn’t let my execute code in my callback function – I have no idea if it’s even fired.

Latest WebKit nightly wouldn’t report anything to me, like Chrome.

Opera 10 lets you connect to the event, fires it accordingly, and the event contains all attributes (woot!)

IE 8 didn’t report anything back to me, too.

I used this simple test file to check for the event. Feel free to test other browsers and report what you found!

Other options

If the browser is too old to have localStorage, there are still other options to persist data: Firefox 2 had globalStorage, which behaves similar to localStorage. IE has userData beahvior since version 5.5. Safari has it’s built-in Sqlite database, but I don’t know since when. Plus, there’s also plugin-based storage via Flash or Gears. Only if they all fail, you should get back to cookies.

Of course, it would be a lot of work to write wrappers for all these storage mechanisms – but, hey, you don’t have to, others have already done it. There are several toolkits that do the work for you, and I will present three of them.

Dojo

The dojo toolkit has dojox.storage. It currently offers support for Flash, Gears and globalStorage. But with the files you can grab at my previous post on storage, you gain access to localStorage, userData behavior and cookies. Working with dojox.storage is pretty simple, and you don’t have to worry about anything: dojo’s storage manager will pick the best available provider. Here’s a simple example:

dojo.require("dojox.storage");
dojox.storage.put('key','value');
var value = dojox.storage.get('key');

That’s it. Simple as that. You do have more options, though; you can also specify a namespace for your keys – so you can simulate working with different “tables” in one store. You can also specify a callback function for the put() method, to get notified when the changes are in effect and if the change was successful.

Lawnchair

Lawnchair has been created by Brian Leroux from Nitobi. Working with it is dead simple, too. It supports localStorage, userData behavior, Gears, Webkit’s Sqlite and Cookies. It works more like a document store (you can save an object w/o specifying a key, for example), but you can also use it like a straight key/value store. In opposition to dojo’s storage system, Lawnchair works completely asnc, so you have to pass a callback function to a get() method to retrieve a value (being async is not a drawback, and it is neccessary to work with WebKit’s Sqlite). You can find some docs here and get it over at Github.

Persist.js

Persist.js has support for localStorage, globalStorage, Gears, Flash, userData behavior and Cookies. It also works completely async. You can get it at Github.

Update II: Ben Hockey proposed to do the whole thing without using the pub/sub system. I for one think its a good idea, but in case you want the topic version, I’ll leave the test page and add another one with the topic-less version. Thanks Ben!

Update III: Dojo 1.5 introduces robust Promises with dojo.deferred as Krys Zyp explains in this SitePen post.

—

One of the things/ideas/concepts that I really like about CommonJS is Promises.

Promises? A brief explanation from the CommonJS API:

Promises provide a well-defined interface for interacting with an object that represents the result of an action that is performed asynchronously, and may or may not be finished at any given point in time.

To hear more about Promises, I highly recommend these two posts.

That concept is not entirely new. The dojo toolkit has dojo.Deferred, which does a similar job. You create a Deferred, add (multiple) callbacks and error handlers to it, and when it fires off, all your handlers get called. But dojo.Deferred is pretty heavyweight. It’s loads of code. And it works with .addCallback() and .addErrback() methods – not with .then() methods, which provide maximum readability.

The goal

What I want to have is the follwing code running (with dojo):

asyncComputeTheAnswerToEverything().
    then(addTwo).
    then(printResult, onError);

(This is the example code from the proposed CommonJS Promise API)

And I want the execution to continue right after doSomethingAsnyc() – the async call should still be non-blocking. The .then() methods should recieve the results of the previous part of the chain, but still be non-blocking. Luckily, dojo provides a tool that allows us to achieve this: the publish/subscribe system.

Let’s do it

When we have unique topics for each promise made, we can subscribe the .then() method to the current topic in the chain, and publish the next topic when the data handlers are done computing. Within the then() method we need to check if the data we recieve is an error or not, to determine wich handler we need to call. The spec also demands a progress handler – if we wanted to implement that, we needed to add another topic, but I left that out.

We only need to kick off  the whole thing when we create the first promise, then the rest takes care for itself. Including the changes proposed by Micheil, what you have to do is pretty trivial and you don’t have to care about unique topics or the pub/sub system at all. The asyncComputeTheAnswerToEverything() function mentioned above would look like the following:

var asyncComputeTheAnswerToEverything = function(){
	var promise = new dojox.Promise();
	window.setTimeout(function(){ // some async operation
		var data = 42;
		promise.emit(data);
	},2000);
	return promise;
};

You create a Promise and store a reference to it. You return the promise and use the reference to it to kick off the chain when the data is there. Everything else runs on it’s own now.
Go to the test page or theand check the source – it contains the Promise code and the example functions. Open the console and run testSpec(); to start off the example code from the CommonJS API proposal.

Usage

As a namespace to put the Promise into I chose dojox – but choose whatever floats your boat. You can just drop the promise code somewhere into your code, or, if want to dojo.require("dojox.Promise") it, create a file named Promise.js that contains the code and place a dojo.provide("dojox.Promise"); as the first line in it. Save the file in the dojox directory and you’re done. (Well, to be honest, this violates the dojox naming convention, but if its just in your project, it’s ok and it will work.)

Any questions left? Feel free to leave a comment, @ me at twitter or drop me a line.

References / Files / More

• CommonJS Promise API Proposal
• Post by Kris Zyp @ SitePen blog about CommonJS
• Post on www.michaelharrison.ws about promises and more
• the test page (using topics and pub/sub)
• the test page (w/o topics, recommended)

The Curve

Every dojo.Animation needs a curve. If you call animateProperty or it’s shorthand anim, you don’t have to provide the curve for yourself, dojo will do it for you – if you build an animation using new dojo.Animation(), you have to provide your own curve. You can think of the curve as of a line that the animation walks on. The line is already present before the animation starts to walk it, and it can always take a break and pause in the middle and eventually continue walking where it had stopped. To create a curve, you need to call new dojo._Line(start, end). In return, you get an object with three properties: end, start and a getValue() method.

var anim = new dojo.Animation({
	curve: new dojo._Line(0,100)
});

Easing

The curve will then be modified by a easing function. By default, this is the linear dojo._defaultEasing. Easing breathes a bit of life into the curve, you can say. Other properties of dojo.Animation that affect the curve are rate and duration. rate is the timespan between two frames. To calculate the targeted fps, use (1000/rate). By default, dojo aims at 50 fps.

var anim = new dojo.Animation({
	curve: new dojo._Line(0,100),
	easing: dojo.fx.easing.quadInOut
});

Waking Life

To get some numbers out of dojo.Animation, let’s let it go wild and play(). When using animateProperty or the likes, you just fire and forget. In our case, we need to get the numbers. To achieve this, we connect to our animation’s onAnimate event. This is fired on every frame of the animation. When your connected function is called, you get – who would have guessed – the current value of the curve. Now you have a function called at a given rate, for a given period of time and you get get a numeric value that is already calculated for you. Decent!

dojo.connect(anim,'onAnimate',function(curveValue){
	// do something
});

To see some curves in action, go to this test page, open the console and type play(1); and play(2); and check the source code to see what’s happening.

Multidimensional Curves

dojo._Line generates only one-dimensional curves. But, there is dojox.fx._core, which contains an (old) version of dojox.fx._Line, which is capable of creating multi-dimensional curves. To use it, you have to explicitely dojo.require("dojox.fx._core"). It’s a bit odd, but the _core file contains only the _Line, and it is not loaded when requiring “dojox.fx”. Well, whatever, you can pass arrays of numbers into dojox.fx._Line:

new dojox.fx._Line([0,2],[100,6]);

Now you have a multi-dimensional curve. Or, if you could say, you have two curves in one. You can (technically) pass an unlimited amount of numbers into dojox.fx._Line. When you hand this curve to a dojo.Animation, it will animate all dimensions of the curve. And it will modify all dimensions of the curve according to easing, rate and duration. If you connect a function to onAnimate, it will now recieve an array of numbers.

var anim = new dojo.Animation({
	curve: new dojox.fx._Line([0,2],[100,6]),
	easing: dojo.fx.easing.quadInOut
});

Head over to the test page again, and type play(3); into the console. Now, the width of the bars is also animated – by the same animation function that calculates the height of the bars.

What now?

If your mind is still not blown away with ideas about how to use this, let me give you a start:

• animate position, width and height of a browser window and use it as a screensaver for some unknowing, yet thankful visitor…
• take some CSS 2D and 3D transisitions/transforms and animate away…
• canvas! No need to say another word…
• Still too banal? Go WebGL! Grab some 3DContext and animate an evil ball of jelly jumping around!

In short: dojo’s animation system allows you to not only animate CSS properties, but gives you a good tool for  animations in general. You get the curves on the one hand, but you also get the “player” for these curves, including play/pause/stop/gotoPercent methods. And dojo.fx.easing has a lot of easing functions in stock.

Uh, persistant local storage?

Ahm, yeah, in case you don’t know, that means a client-side storage, be it in a browser, or in an Air app. It’s not very popular, but that concept has been around for a long time. So why local? There are two major reasons for it: First, we need this for apps and tools that work offline – and apps and tools that work online but need an offline backup and sync later. Kris Zyp wrote a post about the JsonRestStore and OfflineRest back in 2008, he goes a little into detail there. Secondly, we need it for apps and tools that rely on persistence for other reasons, no matter if online or offline – like it happended to me. When I ran into Lawnchair, I had the idea to build a tool that was monitoring CSS selector usage on websites and apps (you know how you sometimes lose control about CSS selectors in webapps…). To achieve this, I needed to store data locally, and persistent.

What dojo offers

As I was using dojo’s excellent CSSRuleStore to find out what selectors where used, I wanted to switch from Lawnchair to a dojo solution. Dojo has dojox.storage (the above mentioned OfflineRest uses dojox.storage), which provides wrappers for the following backends: Gears, Flash, globalStorage and Adobe Air (globalStorage is Firefox’s early implementation of the early WhatWG storage draft). Hm. Not that much. Gears and Flash are 3rd party solutions, globalStorage is a Firefox-only-thingy (and old, though it’s still supported in current Versions) and Air is non-browser. That means: No IE without plugins. No Safari when Flash is not available.

What dojo does not offer (but should)

Guaranteed, reliable support for *any* browser. Without depending on 3rd party plugins. As of now, to have this, you’d need to use Lawnchair or persist,js, which is pretty complete. Speaking of it, let me quote from it’s readme (it’s a good read on local persistent storage in general):

The most notable attempt at addressing this problem [storing client-side persistent data] is probably Dojo Storage. Unfortunately, Dojo Storage does not support Internet Explorer without Flash, and it does not support Safari or other WebKit-based
browsers at all (at least, not without Flash). Also, Dojo Storage is
not standalone; it requires a several other Dojo components in order to
operate.

Whoa, even other JS tools mention the lack of support in dojo…

New providers

Attached to this post are wrappers for the following mechanisms:

• localStorage: this is the current spec, and it is supported by IE8, Firefox 3, Safari 4, Opera 10, Chrome 5.
• userData behavior: this is Microsofts client-side storage for IE < 8.
• cookie: worst case fallback solution…

With these three, there’s an almost 100% coverage of browser situations (see storage overview). There are still no-go scenarios, of course, such as IE7 with userData disabled and cookies disabled, but there’s no way to address them all.

Notes on BehaviorStorageProvider

This one uses the userData behavior, present in IE from version 5 up. It works with DOM elements that have a special behavior assigned. You can then use  set/get/removeAttribute() methods to store data. It has some limitations though – of course…

• Maximum size varies from 64k to 1M – depending on the zone the site is in. So, you can’t rely on more than 64k.
• UserData can be switched off in security settings.
• I couldn’t find a way to read out stored keys if you don’t know them. Maybe this is some security thingy or just a bug – but it means that some methods in the provider don’t work. (that is, getNamespaces, getKeys and clear). To work around this, we have to take some of the precious storage space and store the keys and namespaces seperately.

Usage

Copy the the providers into your /dojox/storage directory and add the needed dojo.requires to /dojox/storage/_common.js:

dojo.require("dojox.storage.LocalStorageProvider");
dojo.require("dojox.storage.GearsStorageProvider");
dojo.require("dojox.storage.BehaviorStorageProvider");
//>>excludeStart("offlineProfileExclude", kwArgs.dojoxStorageBuildOption == "offline");
dojo.require("dojox.storage.WhatWGStorageProvider");
dojo.require("dojox.storage.FlashStorageProvider");
//>>excludeEnd("offlineProfileExclude");
dojo.require("dojox.storage.CookieStorageProvider");

What’s left?

Well, it would be pretty cool to have a dojo.data API compliant store that uses dojox.storage as backend, so that you could write your apps using dojo.data calls and have a reliable offline backup. I started working on that, but then came Christmas, parents, vacation, new year and a lot of beer. But hey, it’s 2010 now, and there’s plenty of time left!

Storage Overview

Files

LocalStorageProvider.js
BehaviorStorageProvider.js
CookieStorageProvider.js
Storage Test Page

Besides indexOf(), there are some other ways to achieve this, so – let’s have a competition and find out who’s the fastest!

The Contestants

replace and length

One possibility is to replace the searched string with an empty string, read the length property of the modified string and compare it to the length of the haystack. If it’s different, the haystack contains the needle. Reading the length property is extra work, but comparing two integers is faster than comparing two strings, so maybe it’s faster in general.

replace

Again, replace the searched string with an empty string. Then compare the the modified string with the haystack. If they are different, the haystack contains the needle.

split

Take the haystack and try to split it using the needle as the seperator. If the result’s length is greater than one, the haystack contains the needle.

indexOf

Find the first occurance of needle in haystack; if the result is something else than -1, the haystack contains the needle.

Results

For testing, I did 10,000 iterations and retrieved the execution time in ms. The methods were tested in the order presented above.

On Chromium (Mac build, Version 4.0.203.0 here), replace + length is slightly faster than replace, and both are faster than split. indexOf is by far the fastest.

1) true: 7 / false: 3.5
2) true: 7.5 / false: 3.5
3) true: 10 / false: 8
4) true: 2.5 / false: 3

Safari 4 has nearly the same results as Chromium, but the numbers tend to differ a lot from test to test.

1) true: 4-18, avg 10 / false: 2.5
2) true: 4-19, avg 10 / false: 3
3) true: 6-22. avg 13 / false: 6-23 avg. 16
4) true: 2 / false: 3

On Firefox 3.5, split a bit faster than the two replace methods, but indexOf is again by far the fastest.

1) true: 13 / false 10
2) true: 13 / false 10
3) true: 10 / false 9
4) true: 1.5 / false: 2

On IE 8 (run in a VM), both replace versions perform almost the same, and faster than split. Again, indexOf is fastest. Only 2 – 3 times faster than the replace methods, but still the fastest.

1) true: 35 / false: 25
2) true: 30 / false: 25
3) true: 60 / false: 50
4) true: 15 / false: 15

You can run the tests yourself, if you are interested, the test page is here.

Summary

The results are pretty obvious: indexOf() outperforms the other contestants. Which is not really a surprise, considering that whatever Javascript does during indexOf() –  it has also to do the same before being able to do a split() or replace(). So, the proposed way for a contains() method is the following:

dojo.string.contains = function(/* string */ needle, /* string */ haystack, /* bool */ caseInsensitive) {
    if(caseInsensitive) {
        needle = needle.toLowerCase();
        haystack = haystack.toLowerCase();
    }
    return haystack.indexOf(needle) !== -1;
}

If you want to use contains() in your code, just copy the above lines somewhere in your code. Again, don’t forget to dojo.require(”dojo.string”) before.

Or, if you want to have beginsWith(), endsWith() and contains() all-in-one, use this: dojo.string.addons.js

One of its major drawbacks – and the one that keeps it pretty far from becoming a joyful member of the dijit namespace – is the lack of keyboard accessibility. It has plenty of other issues and could use some refactoring, but this one is outstanding. Hm, adding keyboard access shouldn’t be too hard I thought and went for it…

1. Moving and resizing

To enable keybord movement, there are some prequesites: First, the pane needs to be able to recieve focus and move itself to front via the keyboard. Second, the pane needs a lot of visual markers. And it needs a certain state in which the keybord movement can actually be activated.

So, the idea is the following: If you tab through the panes, the focus is set to the pane’s title node. If you click into a pane or into its child widgets, you need to shift-tab upwards until the title node recieves focus. In my minimal styling, the title node text is in italics when it has focus. You can then press space to “activate” keyboard movement. An overlay is shown to indicate that the “moveMode” is active. Then you can use the arrow keys to move, and shift-arrow to resize the pane. To exit this mode, press space or escape or take the focus off the title node by clicking somewhere else or tab away.

In short, the first step included:

• Adding visual hints to indicate which FloatingPane is on top (via box-shadow and a bold title node text)
• Adding a visual hint to indicate when the focus is on the title node and “moveMode” can be activated
• Enabling the pane to get on top of other panes by tabbing to it
• Adding key handlers to start and end “moveMode”
• Adding typematic key listerners to realize movement

Oh, did I mention that dojo’s typematic is awesome? Nope? Well, it’s awesome! Go try it out for yourself!

2. Minimize, maximize, restore and the dock

The FloatingPane also has docking abilities – so the dock and it’s items had be accessible, too. The dock items have their own widget class, so this had to be modified. The changes are minor: adding a tabIndex and a keyhandler. And, of course, adding a visual hint to indicate that the dock item has focus (that is, the label is bold). When the dock item has focus, press space to restore the corresponding pane.

Next, the pane needed extra key handling: I chose “+” to maximize, “-” to minimize (or restore, if pane is maximized) and “x” to close the pane.

3. Baking it all together

As it isn’t that desireable to have two widgets doing the same in the dojox namespace, I merged the changes with FloatingPane. But, then again, as I did some other minor changes to FloatingPane (but including changes to the CSS classNames to have a consistent use of baseClass, and inheriting from dijit.layout.ContentPane instead of dojox.layout.ContentPane), I named the new widget “WindowPane”.

What’s left?

Short: A ton. The widget needs to be refactored, it has a couple of bugs. The code I added is undocumented, the CSS incomplete. Well, I’ll be short on time for a week or two, but I’ll surely get back to this. Consider this a work in progress. But, hey, maybe having keybord accessibility will give further develepmont of this widget a little push.

You want to use it?

Cool, there are two options:

- You can use dojox.layout.Window to gain just movement/resize abilities. Then bake Window.js and the extra CSS from the test page into your build, replace calls to FloatingPane with calls to Window, and you’re done.
- Or, if you don’t use FloatingPane yet or want the complete functionality, grab the WindowPane.js file, the WindowPane.css file and the WindowPane.html template and add them to your dojox. This is probably the best way to do.

See below for files.

Keybord summary

Use Tab to navigate from pane to pane, and press space when the title node has focus (title text is itailc) to activate keyboard interaction.

Arrow keys: move pane around
Shift + arrow keys: resize pane
plus: maximize pane
minus: minimize pane or restore pane (if maximized)
x: close pane

Press space again or escape to deactivate keyboard interaction. Or just tab or click away.

Files:

Step one (moving and resizing):

• /dojox/layout/Window.js
• test page

Or: Step three (full)

• /dojox/layout/WindowPane.js
• /dojox/layout/resources/WindowPane.html
• /dojox/layout/resources/WindowPane.css
• test page

Consider the following code:

var nearbyZipcodes = dojo.filter(givenZipcodes,function(zipcode){
    return dojo.string.beginsWith(zipcode,'12');
});

No need to tell you what this does, right? So, let’s do this then! The only thing left is to think about performance: Is there a difference between String.substr() and String.substring()? And can we get faster than the two?

If we have very short needles to look for in our haystack, one could consider the following approach:

dojo.string.beginsWith = function(/* string */ needle, /* string */ haystack) {
    var i,
        len = needle.length;
    if(needle.length > haystack.length) {
        return false;
    }
    for(i = 0; i < len; i++) {
        if(needle.charAt(i) !== haystack.charAt(i)) {
            return false;
        }
    }
    return true;
}

For very short needles, or when we expect close to no hits, this might be faster. So I set up a test page and let the different methods run against each other. The results clearly spoke against the char iteration method: On Firefox, iteration was always slower, even when the iteration method could return false after the first character. And when it had to iterate more often, times went up (I somehow had in mind Tracemonkey was perfect for simple iterations – but in this case it won’t help). Only on Safari the iteration method could compete with native substr() / substring() – but was never significantly faster. So, we’ll stick to the native methods (there was no real difference between the two).

More convenience?

Depending on your datasource, you might want to trim the input. No problem, as we use dojo, we can use it’s super fast trim and end up with the following:

dojo.string.beginsWith = function(/* string */ needle, /* string */ haystack, /* bool */ trimBefore) {
    if(trimBefore) {
        needle = dojo.string.trim(needle)
    }
    if(needle.length > haystack.length) {
        return false;
    }
    return haystack.substr(0,needle.length) === needle;
}

So simple, so sweet.

You can run the tests for yourself, the page is located here: test_beginsWith.html

If you want to use beginsWith in your code, just put the lines above it anywhere in your code – but don’t forget to dojo.require(’dojo.string’) before.