Fly together Forever 比翼恒飞

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

In order to support IE, which does not run reliably under linux with ie4linux, I have to stick with M$ windows when working on dojo. However, the experience with windows svn client was not pleasant: as svn+ssh protocol is used to access dojo repository (among other svn repositories I use), I had to input my password each and every time when I update/commit to it. What’s more annoying, when doing some operation, such as svn log, I am asked three times for password (or maybe twice?).

I had hoped the svn client I use, TortoiseSVN, could support Public Key Authentication for svn+ssh, just as what the svn linux client can do.

Today, I had a look at the documentation of TortoiseSVN and found out that it IS INDEED possible to configure TortoiseSVN to use Public Key Authentication. It was just my assumption, it has not implemented this support, prevented me from digging into it.

The key point is to understand this: TortoiseSVN makes use of putty behind the scenes (more specifically, it uses a derivate work of plink, a windows ssh command client). You can tell putty to login ssh with Public Key Authentication: just go to Connection -> SSH -> Auth, select the a private key file for the authentication. Under Connection -> Data, you may also fill in Auto-login username, so that you don’t need to specify the username every time you login.

If you do not already have a pair of your own private/public keys, then you may want to check out PuTTYgen and Using public keys for SSH authentication.

If you come from linux world, like me, and already have your own private/public keys, just import it with PuTTYgen and save the private key to a format putty recognize, then select this saved private key in the place mentioned before. You have to save the session under a name, such as dojo, in order to make it accessible to other ssh dependent applications, such as TortoiseSVN.

Don’t forget to add your public key to file ~/.ssh/authorized_keys in your subversion server.

After that, you should be able to ssh to your remote server without input your password. Next step is to tell TortoiseSVN to make use this Public Key Authentication. You don’t need to explicitly teach TortoiseSVN to use putty for ssh connection. All you need to do is in the checkout dialog of TortoiseSVN, instead of the normal host of the svn repository server, you just specify the session name (in this case, it is dojo). So instead of checking out dojo from this address:

svn+ssh://liucougar@svn.dojotoolkit.org/var/src/dojo/trunk

just use this:

svn+ssh://dojo/var/src/dojo/trunk

That’s all. TortoiseSVN can make use all the information you saved in that session for ssh connection, and you don’t need to type in password any more. That’s neat.

(As how TortoiseSVN knows about session saved in putty, here is my guess: putty stores all information of sessions in windows register, so that’s can be accessed by TortoiseSVN.)

After Tom reviewed the patch, I went ahead and committed the enhanced widgetsInTemplates support (which used to be called enableSubWidgets).

In my previous blog post, I introduced what the support can achieve. Here I’d like to state some limitations of this patch:

• See the second test in the widgetsInTemplates test file: if a widget template file contains its own type of widget as a child widget (not matter directly or indirectly), it will lead to a infinite loop. It would be good to detect this, however I can not come up with a decent and fast way, so I just left it as it is.
• This kind of syntax for widgets in template file is not supported (if this syntax is used, the widget can be rendered, but attachPoint and attachEvent won’t work):

  <dojo:button .../>

  instead, please use this syntax:

  <input dojoType="dojo:Button" .../> 

  this limitation is also due to lack of decent ways of detecting the first syntax.

When I worked on dialog support for the new Editor2 (which is already committed to dojo svn), I wanted to use other dojo widgets in the template of the various dialogs: so instead of plain checkboxes/buttons, the more eyecandy widgets in dojo could be used.

Unfortunately, no widgets in widget template was supported by then. There indeed was a patch submitted for this very issue, but no official ways to achieve that.

After invesigating the code in the patch, I decided to write my own widget to support this. I took a slightly different approach. After asking Bill to review the first draft of the widget, we decided that merging the code into the DomWidget widget (the base widget for all HtmlWidgets) directly would be better. That was the origin of the enableSubWidgets patch.

Some days later, Morris pinged me and asked whether it would be possible to add more features to the subwidgets support. As I did not foresee the requirements Morris has for the more advanced usage, it tool several days for us to discuss/understand/implement new features. The final output is that we decided to rename enableSubWidgets to widgetsInTemplates, and a new patch.

A bit of doc about this patch is provided in the ticket, which I’d like to quote here as well:

1. It allows you to define widgets within your template markup. The feature must be enabled for the widget by defining widgetsInTemplate:true in your widget javascript (similar to how isContainer:true works)
2. It allows you to attach those subwidgets to your widget – just use dojoAttachPoint on the widget definition node and the code does the rest of the magic
3. It allows you to attach events from the subwidgets to your widget – just use dojoAttachEvents
4. It allows you to ‘wrap’ subwidgets that are containers, and have the subwidget act as the container within markup e.g. if you have a TabContainer widget in a template and set dojoAttachPoint="subContainerWidget" then any child widgets (in markup only) get attached to the subwidget rather than the defined widget