Fly together Forever

As pointed out by Jon’s blog post, simply use the dojo/dijit objects on the top window within an iframe won’t work for dojo APIs in most cases, because “the top level dojo object has no Out of the Box knowledge of the iframes or their content”.

Actually, dojo has two APIs in the core to support running code in the context of an iframe: dojo.withGlobal and dojo.withDoc. However, they do not have much attention, as most of their usage is only seen in the dijit.Editor code. Actually, they were introduced for the sole purpose of dojo.widget.Editor (which is the dojo 0.4 Editor widget) for dojo 0.4 in the first place.

Both of them have identical signature:

dojo.withGlobal(/*Object*/globalObject, /*Function*/callback,/*Object?*/thisObject, /*Array?*/cbArguments)

In order to use them, you can wrap your code in a function first, like this:

function iframefunc(){
    dojo.byId(‘foo’);
    dijit.byId(‘foo’);
    dojo.query(‘a.foo’);
}

and call the function as this in an iframe:

dojo.withGlobal(window,iframefunc)

You can also call dojo APIs directly use dojo.withGlobal. Say you want to run dojo.byId(‘foo’) in an iframe, you can do:

dojo.withGlobal(window,'byId',dojo,['foo'])

Note that, the above code can also run correctly in the context of the top window.

The differences between dojo.withGlobal and dojo.withDoc is the first argument: if you want to only change document of a function call operates on, you can use dojo.withDoc instead and pass it with the document of an iframe.

As an open source editor, komodo editor is targeted at dynamic programming language editing, which supports javascript, php, python and perl, among others.

One of the features for those supported dynamic languages is auto-generation of a list of available functions defined in a script. However, when editing dojo based javascript files, komodo can not pick up any classes declared using dojo.declare and it does not support dojo.extend either.

Today saw a post from Steve on his blog about ” Fast String Multiplication with Regular Expressions, Exponential Concatenation, and Binary Interpolation“. Basically, it deals with how to fast multiplicate a string n times in javascript.

When I first saw the post, only 3 algorithms were presented. Looking at the 3rd algorithm, I think it can receive some improvement if exponential concatenation is used more efficiently. By the time I implement the improved version, Steve added a 4th one to his post, which is quite similar to what I have here:

function mul5(str, n) {
 	var r=[];
 	while(n){
 		if(n%2)
 			r.push(str);
 		str+=str;
 		n >>=1;
 	}
 	return r.join(”);
}

The main difference is that it is more compact. My tests show that, in Firefox and Safari 3.0.4, mul5 is as fast as mul4. However, similar to mul4, mul5 is about 30% slower than mul3 in IE (mult5 performs as good as mul4 in IE).

The reason of slowdown in IE compared to mul3 is this part: str+=str. IE does not handle that direct string concatenation well if the string is quite long. What if we use array.push there as well? After several fail-and-error, I found out one solution which will actually boost the performance for IE:

function mul5(str, n) {
 	var r=[],t=[str];
 	while(n){
 		if(n%2)
 			r.push.apply(r,t);
 		t.push.apply(t,t);
 		n >>=1;
 	}
 	return r.join(”);
}

As shown above, the trick is to use array.push.apply(array,anotherArray) to add all elements in anotherArray to array. This IE version is as good as mul3, or even slightly faster than it.

However, this modification will slow down other browsers. We can use conditional compilation support in IE to work around this. The merged version is like this:

function mul5(str, n) {
	var r=[];
	/*@cc_on //for IE
	var t=[str];
	while(n){
		if(n%2)
			r.push.apply(r,t);
		t.push.apply(t,t);
		n >>=1;
	}
	return r.join(”);
	@*/
	while(n){
		if(n%2)
			r.push(str);
		str+=str;
		n >>=1;
	}
	return r.join(”);
}

If using dojo, the conditional compilation should be changed to just test dojo.isIE. (conditional compilation is not supported by dojo builder, so it will be lost when building dojo)

Try it yourself here. Changes compared to the original one:

1. mul1 and mul2 are slow, so removed from the test
2. the number of repetition and the length of the input str are slightly different from the original one
3. A table is used to present the result, rather than a list

Dojo project contains a lot of facilities, however not all of them are useful for a given user. We provide a build system which removes inline comments and rename local variables with shorter names (3 characters), among other optimization.

Even after this building procedure, the resulting dojo.js can still be a bit big: for a normal widget build, the size is 170k (dojo trunk).

Recently when searching for IE hover css selector support, I revisited Dean Edwards’s website. Packer project attracted my interest and I decided to give it a go with the built dojo to see whether further compression can be achieved.

The result is quite promising: after packing, the resulting widget build of dojo is almost 50% smaller. The compression ratio is 99893/170258= 58.7%.

Looking at the packed version, all the comments and source formating new lines are removed. Some other compression is happening as well, but as I did not investigate its source code, I do not know exactly what it does, but it seems to me that by storing the publich API name and all the strings in the source at the last, it achieves some extra compression ratio. (Don’t worry, the compression does not change the meaning of the javascript code it packs, and I tested that in one of the applications I am working on.)

As the source code is in javascript, it should be simple enough to incorporate this to the dojo builder. Probably this should be the last "filter", before writing the output file: for all the source js files, they should be passed through this packer, and then copied to the release dir, so does the resulting dojo.js.

If you are wondering how to add the fancy format dropdowns, fontsize dropdowns among others, to the default dojo look & feel toolbar template, look no further, here it is!

The installation of this is the same as for the FCKeditor style toolbar template. (You do need a full source tree/checkout of dojo svn)

An online demo is also available.

Thanks to Bruce Webster from Interact Learning Community Environment for contributing this full featured Editor2 toolbar template and corresponding stylesheets/images.

Sometime ago, someone asked about smoothscroll support in dojo. While working on index list of Editor2, I found myself in the position of requiring such a mechanism, so that rather than jumping to an element, scrolling smoothly to the element gives user a better feeling of context.

Rather than implementing a widget directly, as asked for in the linked post, a dojo.lfx animation shall be created first. Although the core of the smoothScroll is simple to figure out, I had little knowledge about the dojo.lfx code base. After inspecting dojo.lfx.html.propertyAnimation and resource dojo.lfx.Animation, I got the idea of what the animation framework dojo.lfx provides.

Here is the latest FCKeditor style toolbar package for dojo Editor2. Please follow the instructions to install it.

ChangeLog:

• Updated to latest dojo trunk format
• A new sample file which demonstrate how to use this style with Editor2 (it can be found at src/widget/templates/Editor2/test_FCKstyle.html after you unzip the package in the current dir)
• In the sample file, several plugins are enabled by default.

Some improvements are just committed to dojo Editor2 in trunk. Although dojo 0.4.1 release (which is the trunk will be) generally should not break API compatibilities, as these changes only affect the new part of the Editor2 API (compared to 0.3.1 Editor2), and which is just released with dojo 0.4.0 one week ago, so we decided that an exception can be made for the Editor2 in this case.

As dicussed in my previous blog, some significant modification are merged in with the patch. I will briefly go through the steps required to port an Editor2 plugin written for 0.4 to the latest trunk format, then state other improvements introduced with this commit.

After dicussion with Alex, we agreed that the commands implementation in Editor2 is not ideal. Currently, commands are global, which means all instances of Editor2 share the same command objects. As a result, for each command, it can not hold any properties which is specific to an Editor2 instance, if it wants to save such kind of information, it has to attach that it to the Editor2 itself, which is no good.

In addition to that, bug #1505 will be fixed along the way when I migrate commands to be per instance objects.

This modification will not be API compatible with previous version (0.4.0 Editor2) with regards to how external commands are handled (including registration and retrieval). This is against rules to be merged into a point release, so it can be argued that this should not be merged into 0.4.1. However, as the new Editor2 is just released with 0.4.0 (which happened one week ago), and 0.4.1 will be soon (in 2 weeks time), so I’d like to push it into trunk for it to be included in 0.4.1, but we’ll see what the consensus is.

I will probably document how to migrate Editor2 plugins from 0.4.0 format to the new one later in another post.

For reference about how to make use of the fontsize/fontname menus in the new dojo Editor2, the FCKeditor style toolbar template is attached here.

In order to make use of this, you need to:

1. unzip the file under src/widget/templates/Editor2
2. pass these two parameters when creating an Editor2 instance:

   toolbarTemplatePath: dojo.uri.dojoUri("src/widget/templates/Editor2/EditorToolbarFCKStyle.html"),
   toolbarTemplateCssPath: dojo.uri.dojoUri("src/widget/templates/Editor2/FCKDefault/EditorToolbarFCKStyle.css")