Fly together Forever

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.

Some sample of how to use this, besides the test file, includes Editor2DialogContent widget defined in Editor2.js.

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

The patch will be reviewed soon and hopefully it can be included into the upcoming 0.4 release of dojo.

Finally, as no one expressed concerns in the mailing list, I just had my work of the enhanced editor2 widget merged into svn. You should be able to use it without any effort: just a svn up should bring you up-to-speed with the latest extensible version of Editor2. And you should be able to test it in the nightly build of dojo as well (of course you have to wait until tomorrow for that).

I admit the committed version has a very limitted toolbar, which lacks a lot compared to the FCKeditor one I ported for testing purpose. I think I can add more buttons to the standard toolbar as a reference of how to use all the available features.

Along the way, I also fixed more than 5 bugs filed on Editor2 (including the old Editor).

Although committed, I still feel not so comfortable with the dialog loading system. I will try to come up with a better approach and migrate the existing dialogs to that. On the other hand, some usability issues will be sorted out: such as warnings for the cut/copy/paste command issue in Mozilla/Firefox.

More document about how to use/customize and extend the editor is required as well. I already started a page in the dojo wiki, but for now it is only meant to be a placeholder

If you are interested in extending the new editor2, you can look at the built-in plugins. Currently we already have 5 of them, which should cover all the possible ways of extending the editor2: add new commands, add new toolbar items, add new context menu items and change behaviors of the toolbar. They also demonstrate how to write a popup dialog for the editor2. However, as I mentioned in this post, the integration of the dialog support will likely to be change in near future to a better/more dojo-ish way.

Not all the 5 plugins are loaded by default: only the contextmenu plugin is loaded. You can make a simple "dojo.require" to include additional plugins (before you initialize an editor2).

As this is the last week of the SoC, I feel the urgent of pushing my modification into svn trunk.

The latest patch is attached to ticket #1046. This patch is meant for merging into svn directly. Due to license incompatibility, the FCKeditor look & feel toolbar is not included in this patch: instead the original look & feel is retained and the template file is updated to work with the new editor. (So you can not see in the online demo as many functionality as before, but the code is there, just not shown in the toolbar)

The notable differences in the online demo from the svn trunk, is that the createlink and insertimage are working now. Context menu support was also added, which itself resides in its own plugin and this context menu implementation can handle plugable menu items, so that other plugins can add items to the context menu.

Unlike the previous patches, this latest patch should contain all the changes and you can apply it to the latest svn check out to try it yourself. However, due to a latest bug in the svn trunk, you may experience some errors when loading the test page. I already proposed a patch for it but still I am waiting for reviewing. Before I can commit it, please try the online demo.

As my primary mentor for the SoC task is moving house and has no time so far to review my patch, we have to wait longer before this can be merged into svn trunk. Meanwhile, implementing the remaining functionalities kept my busy.

This time, all the buttons (except the anchor button) in the online demo toolbar should actually do something. Most notably, the insertimage and inserttable buttons are working with full undo support in FF and activeX mode IE. In addition, the find dialog works in IE as well (FF is already supported).

Other changes are already merged into the RichText widget in dojo svn:

• More activex mode IE support was added: strikethrough and inserthorizontalrule commands are implemented
• Pre content filter support is added
• Pre/Post DOM filter support isadded, which take a dom node as the parameter instead of a string
• External style sheets loading is implemented: now it is possible to customize the editing area appearance with external css files

This week the first patch intended to be merged into svn was released for review. The patch has already implemented all the necessary infrastructures needed to make editor2 widget in dojo an extensible WYSIWYG editor.

The plan for next week is to have the first patch merged into svn and try to implement context menu support (which could be done in a plugin). In addition, I would also look into improve current available commands.

The patch for enhanced editor2 for dojo with all the infrastructures finished is just merged to the online demo (The patch does not contain all the files to run the online demo, as it only contains text modifications). By infrastructural, it is meant that all the basic frameworks to make an extensible/flexible Editor2 (along with Editor2Toolbar) are in place, but not all the features are implemented, although the current feature set is already a super-set of the original Editor2.

The infrastructures include:

• Extensible command
• Flexible/Extensible toolbar item
• Plugins support for Editors, in which Command/Toolbar Item can be defined

For each of the above mentioned items, several implementation is in place:

• Browser built-in commands are almost covered
• Complex toolbar items, such as dropdown menu (like the one in FCKeditor) are realized. In addition, popup windows (dialogs, in fact, they are FloatingPanes) are introduced as well: the createlink button is an instance of this. (yes, insert/edit link should work ok now)
• Three plugins are written to demonstrate how to hook additional commands/toolbar items to the editor, which include:
• AlwaysShowToolbar: fully implemented, replace the original built-in feature of Editor2
• ToolbarDndSupport: demonstrating plugin, lack some features, but DnD is working as expected (in the online demo, this plugin is disabled)
• FindReplace: this plugin implements the Find and Replace commands and toolbar items. Find has a primitive implemented FF, while IE Find support and Replace haven’t been achieved yet. This plugin also demonstrate how to popup a none-modal dialog to ask users for more information.

The only missing feature planned for this enhanced editor2 is context menu support. I’d like to have this patch reviewed and committed into svn before trying to implement that.

Other changes include migrating selection manipulation in RichText to dojo.html.selection and improved the latter one. These code has already been committed into svn.

Currently, the plugins are located at src/widget/Editor2Plugin dir and template files for Editor2 are placed in src/widget/template/Editor2.

As the theme shown in the demo was ported from FCKeditor, which has no chance to be merged in to dojo svn due to license incompatibility, I will have to write a new one instead, or rather porting the original template file/css file. (This is only meant for review purpose, and the theme I will commit would be our own.)

Feedback and suggestions are welcome.

This week, I advanced in the enhanced editor direction further (see latest online live demo):

• A new look and feel of the toolbar is ported from FCKeditor.
• Fontsize/Fontname and blockformat can be set/displayed correctly now.
• A new feature, DND support in the toolbar was also introduced (meanwhile I improved the dnd code in dojo as well): now you can drag the handler in the toolbar to move it. It would be good to be able to drag individual buttons/items in the toolbar as well, but this will be delayed until I implement storing the order of the toolbar and restoring the order from saved information.
• Plugin framework is largely done, but need more testing and more plugins.
• Implemented first plugin for the Editor: AlwaysVisibleToolbar which contains the code originally in the editor source code.

Next, I plan to do the following things (ordered based on priority):

1. Migrate all the selection manipluation code in editor2/richtext to use dojo.html.selection
2. Make use of Dialog widget for commands which require more options, such as inserting links/tables.
3. Move DND support into separate plugin and support DND of individual toolbar items. Figure out a way to store/restore the order of toolbars/items. Implement a button to enable/disable DND support in the toolbar. Figure out a way to clean up the DND code when not required.

The IE undo issue under none-activeX mode and the htmltoggle issue need to be sorted out as well.

As plugins for Editor2 will be committed into svn, each of which is a separate file, I’d like to propose a directory rearrangement: like the case in treev3, I’d like to create src/widget/Editor2 to hold all the Editor2 related stuffs, such as Editor2.js, Editor2Toolbar.js, and a sub dir Plugins to hold all the built-in plugin files. The same goes for a new dir tests/widget/Editor2.

Finally I think it’s time for a public review of the work I have done for the extensible Editor2/Editor2Toolbar task. The patch can be viewed/downloaded in the trac page. A live online demo is also available.

The changelog against last weekly report includes:

• Implemented blockformat select (also fixed bug #1042)
• The toolbar items which are not available (disabled) are made obvious (greyed via css style)
• Fixed to work in IE none-activeX mode
• Other minor bug fixes

In FF, it works as good as the original implementation. However, in IE, it does have several issues and I’d like to hear other developer opinions/feedbacks.

In activeX mode, the htmltoggle functionality is not working properly when the editor is focused: when toggle back to WYSIWYG mode, the content is not visible (see also the FIXME in the patch). I tried several workarounds, but to no avail. Another issue is that the activeX editor does not provide support for command inserthorizentalrule and strikethrough and I can not come up with a decend replacement.

In none-activeX mode, the editor in IE has a more serious issue: undo/redo is completely unavailable! I do not know what it used to be like, but it seems to me that there is no way around except implementing redo/undo stack in javascript, which is not such a easy task (FCKeditor does do this for IE as it does not use activeX object for editors).

In order to meet the requirements for the Editor, undo/redo is compulsory, so that leaves us two options:

1. do not support none-activeX mode at all for IE
2. or implement our own undo/redo stack (as FCKeditor does).

However, the second option is one of the things that the original design intended to avoid, IIRC.

In addition, with the current patch, no matter which toolbar you use (in IE, two toolbars are shown), the (last) focused editor in the page actually executes the command the button triggers. This provides the possibility of more complex toolbar sharing: The current toolbar sharing is only able to share the first instance in the page, while with this patch, it is easy to add support to define toolbar groups: you can have 4 instance in the page, and specify the first two share the same toolbar while the last two share another one. I don’t know how useful this would sound to people. If no one is interested in this possibility, I won’t bother to implement it.

I’d also like to hear opinions/feedback about the approach this patch took.

This patch is only meant for a technique preview, and all the stuffs introduced are packed into Editor2.js or Editor2Toolbar.js. IMO, they should finally be moved to some other dedicated files.