Fly together Forever 比翼恒飞

Another week is concluded today. The ComboBox widget was migrated to make use of the new PopupContainer and several related bugs were fixed. PopupContainer also received some improvement which makes it more customizable in regards to zIndex values.

The main effort in this week is to continue the enhancement of the Editor2/Editor2Toolbar to be extensible and get rid of hardcoded functions which are not related to the core part.

The issue mentioned in the last weekly report was solved by using another syntax of attaching event to a node.

In my current local copy, all but one (formatSelect) buttons present in tests/widget/test_Editor2.html have been implemented. The approach taken is modeled after FCKeditor (refined version of the proposal in last weekly report):

The principle of EditorCommand is introduced. An EditorCommandis an operation on the editing area. It also provides APIs to retrieve state of the command (Disabled/On/Off). Three items are introduced in Editor2.js:

Name	Type	Description
Editor2Command	Class	Base interface for all command in Editor2
Editor2BrowserCommand	Class	Browser builtin command
Editor2Manager	Object	Global object to register new Editor2Command and retrieve command based on name

In order to represent buttons and other more complex elements in the toolbar, ToolbarItem principle is introduced. Normally, every ToolbarItem has an associated EditorCommand. A ToolbarItem can create and/or initialize/modify a DOM node (such as connect onClick to another function to execute the related EditorCommand). In addition, it also encapsulate the code for refreshing the state of the button (such as highlight/unhighlight). One global object and 3 classes are added to Editor2Toolbar.js:

Name	Type	Description
Editor2ToolbarButton	Class	Button to wrap a simple Editor2BrowserCommand command, such as bold, italic
Editor2ToolbarDropDownButton	Class	Button which provides a dropdown (PopupContainer)
Editor2ToolbarColorPaletteButton	Class	Button to popup a ColorPalette to set front/back ground color of text
Editor2ToolbarItemManager	Object	Global object to register new Editor2ToolbarItem and retrieve toolbar item based on name

There are several outstanding issues I need to sort out before preparing a patch for peer review:

1. In none-activeX mode under IE, it does not work yet;
2. No matter which toolbar it always operates on the focused editor, this should be prevented when each editor has its own toolbar;
3. selectFormat is not implemented yet;
4. In IE activeX mode, inserthorizentalrule and strikethrough are not supported, need to find a workaround;

Besides fixing bugs related to the code I am working on (mostly widget related), I implemented the initial NamedCommand class in Editor2.js and added several public APIs to dojo.widget.Editor2 for handling commands, such as registering new command (plugins can use it to register new commands) and query which commands are available.

A command class was introduced which has following APIs:

execute() //execute the command
getState() //get the state of the command: Disabled/On/Off

A new class dojo.widget.Editor2.NamedCommand was introduced to wrap the built-in commands in browsers.

The _CurrentInstance was also migrated to getter/setter API, rather than accessing the _CurrentInstance variable directly.

However, when trying to migrate the Editor2Toolbar to make use of the new "Command Principle", I encountered an issue:

In order to eliminate the hard coded command handling functions in Editor2Toolbar, the command name has to be available in the onClick event handler for the buttons (including other controllers, such as a select) in the toolbar. It is possible to add another attribute to the span element which contains the button, such as dojoEditorCmd="bold", and retrieve it from the element e.currentTarget, however this only works in FF, not in IE.

I admit the above approach is not so decent, but I can not come up with another one.

The plan for next week is to propose a way to work around the issue and migrate Editor2/Editor2Toolbar to use it.

This week improving Menu2 related stuffs was my main focus. A new base widget, PopupContainer is introduced in Menu2.js which encapsulates opening in a given position in the screen or around an element, toggle animation integration, sub popup handling and IE bleed through issue workaround. PopupContainer now serves as the base class of PopupMenu2, ToolTip and DropDownContainer. Menu2Manager defined in Menu2.js was renamed to PopupManager.

Two issues in DomWidget were also fixed: #1029 and templateCssString handling bug when no template file/string is specified.

While working on animation integration, two bugs in lfx package were found (thanks to Bill for noticing the issues). I fixed one of them while the other is waiting for Bryan ( #1102).

PopupContainer and PopupManager will eventually be moved into a new file because ToolTip and DropDownContainer only depend on PopupContainer, so no need to include PopupMenu2 and other widgets defined in the Menu2.js file.

I also migrated ComboBox widget to make use PopupMenu2 widget as the popup in my local copy. You can try it here (a profile is dumped at the end of the page). However, Bill was not happy with the performance, so it needs more work to be merged.

The focus manager section in the wiki page GlobalHotkeyAndFocusManager was also updated.

I also started to work on ticket # 1046 (Remove hardcoded event handlers in the Editor2 and Editor2Toolbar to make them extensible).

Next week, I will try to improve the proposal GlobalHotkeyAndFocusManager further given more feedback are received and try to finish ticket # 1046. Of course, bug fixing for the code I am working on is always on my list.

As I moved house unexpected this week, I haven’t put as much effort in dojo development as I would have hoped.

I submitted a patch for ticket #1058 to add keyboard navigation support to popupmenu2 and add other necessary features for it to be used in combo widget. Bill and Becky reviewed it and gave several suggestions. I will modify the patch according to Bill’s suggestion and commit to svn. After that, I will try to modify it to comply with Becky’s accessibility suggestions.

I also prepared a patch for ticket #931, however as Alex did not feel good with the approach, he said he would look for a better way.

In addition, I fixed several other minor issues in the svn.

A draft proposal for centric shortcuts support and focus management is created in the wiki.

Next week, besides finishing the popupmenu2/combobox widgets, I will start to implement ticket #1046 (Remove hardcoded event handlers in the Editor2 and Editor2Toolbar to make them extensible) and fix ticket #1042 (FormatBlock of Editor2 in ActiveX mode does not work)

The highligh point of this weekly report is that I became a dojo committer: several bug fixes and enhancement to the dojo code base which are useful for the Enhanced Editor have been merged into the svn, which include:

• fixed ticket #1018: Multiple Editor2 instances do not work properly in Firefox (svn r4498)
• Added additional utility functions for manipulating selections: dojo.html.selection (svn r4499)
• Added support for using the functions in dojo.dom and dojo.html with different window and document objects, allowing the functions to work in frames, etc. (svn r4522)
• fixed ticket #956: make dojo.body(): document.body doesn’t work for XHTML, and dojo.html.body causes circular dependencies (svn r4525, r4526 and r4543)
• fixed ticket #1034: move iframeContentWindow/ContentDocument out of dojo.io and 2 more APIs for dojo.html (svn r4531)
• fixed ticket #1035: Support for Embedded iframes in PopupMenu2 (svn r4536, r4538, r4540 and r4538)

In addition, one other related ticket was fixed:

• fixed ticket #1017: Make ComboBox autocompletion work for asian languages (svn r4508 and r4510)

My plan for the following week includes:

• fix ticket #931: Editor2: undo doesn’t work (IE), and related ActiveX issue in IE
• fix ticket #1037: combobox open outside of pane
• start to implement ticket #1046: Remove hardcoded event handlers in the Editor2 and Editor2Toolbar to make them extensible
• fix ticket #1042: FormatBlock of Editor2 in ActiveX mode does not work (may be delayed for later consideration)

After discussion with Alex and Paul separately, and taking account of other feedbacks, the new toolbar in the enhanced editor will be template based for speed concerns. In addition, more native dojo widget will be used in the new toolbar.

After about 10 patches I submitted merged into dojo svn trunk by other dojo developers, yesterday I successfully obtained my committer privilege. Alex and Bill both reminded me that when committing a patch from others, I shall make sure that the author has already filed a CLA with dojo foundation

I have to check out dojo svn from a different address to have write access:

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

Finally, I can commit to dojo svn myself . As suggested, I will consult the first two or so Editor2 related modifications with Paul before committing. I am also going to solve ticket #1037 and Bill would review it.

When planning for how to improve the Editor2 widget, I noted several concerns about the current implementation:

• Editor2Toolbar hard-codes all the available command buttons and the event handlers for them. This is particularly an issue if we want to make it extensible. In addition, context menu is also planned, so the event handlers should not be incorporated in the Editor2Toolbar widget.
• Another Editor2Toolbar widget related concerns is that, the layout is given in a template file, which again hard codes the event handlers.
• Widget Editor2 also suffers from the same issue. In addition, it checks all available command states in updateToolbar() which is not necessary when only a portion of them is actually used in a toolbar.

The following is my plan to tackle them:

• In Editor2, introduce a new variable to hold the current focused instance of Editor2 (such as dojo.widget.html._CurrentEditor2Instance) which is set when focuses in a Editor and unset when blurs
• Introduce a command class (EditorCommand), which capsulates the information about a command: state (disabled/highlight on/highlight off), how to execute the command. The class for the built-in commands is something like this: (this principle is borrowed from FCKeditor)

  var dojo.widget.html.Editor2NamedCommand = function( commandName )
  {
          this.Name = commandName ;
  }
  
  dojo.widget.html.Editor2NamedCommand.prototype.Execute = function()
  {
          dojo.widget.html._CurrentEditor2Instance.execCommand( this.Name ) ;
  }
  
  dojo.widget.html.Editor2NamedCommand.prototype.GetState = function()
  {
          return dojo.widget.html._CurrentEditor2Instance.queryCommandState( this.Name ) ;
  }

• Rewrite Editor2 to make use of EditorCommand
• Rewrite Editor2Toolbar so that it makes use of EditorCommand as well. There are two possibilities to do this:
• use template support as it is, so if the users want to customize the toolbar he have to modify the html template
• generate the toolbar pragmatically (as in FCKeditor): toolbar can be configed in an option of an array of strings specifying which buttons to use and the layout, rather then in the html template. This is not as flexible as template files, however I do not think most users are interested to modify the more complex template file instead of an simple option in the editor. As it is done in FCKeditor, theme is also possible in this manner: the theme has to comply with a specified format.

Further plan includes introducing an Action command which wraps the apperance and shortcuts for a command.

I have been really busy lately, so I hadn’t noticed that FCKeditor 2.3 finaly was released a week ago until yesterday.

It seems it is now the time for a new release of SJSD which supports the latest FCKeditor: The svn trunk of SJSD supports 2.3 already, but no public release yet. I will try to make a release if I can find some time to sort it out.

In addition, a new patched EditMonkey would be nice as well, but as I haven’t ported the FCKeditor plugin for wordpress to FCKeditor 2.3 yet, it requires much more time, which I probably won’t do until some time later when I am not so occupied.

I promised someone in IRC one month ago to release a new version of skim soon. However I only managed to release it yesterday. Sorry for the delay. Please find the
news in SCIM website.

In order to implement advanced features/missing features of the proposed enhanced Editor widget, the core of the dojo packages need to be extended. One of the most fundamental one is the impossibility of using dojo from another window/document except the window which loads it.

In MochiKit the concept of " context " is introduced. It provides 4 APIs to handle context (see the table below).

Signature	Description
withWindow(win, func)	Execute function func in the context of window win (and with document win.document)
withDocument(doc, …)	Execute function func in the context of document doc
currentWindow()	Retrieve the current window in use
currentDocument()	Retrieve the current document in use

For example, creating DOM nodes in a child window in MochiKit is like this:

withWindow(child, function () {
    var doc = currentDocument();
    appendChildNodes(doc.body, H1(null, "This is in the child!"));
});

Paul suggested to borrow this API to dojo, so we can do something like this:

dojo.html.withWindow(child, function () {
    var doc = dojo.html.currentDocument();
    var h1 = doc.createElement('H1');
    h1.appendChild(doc.createTextElement('This is in the child!'));
    dojo.html.body().appendChild(h1);
}); 

Alex consider this would lead to "error- prone usage". I agree with that. However, as I need this functionality for the Editor, so we have to come up a better idea or stick with this syntax.