Fly together Forever

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.

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)