Sat 29 Jul 2006
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:
- do not support none-activeX mode at all for IE
- 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.
RSS feed for comments on this post. TrackBack this post
July 2nd, 2007 at 6:16 pm
Hi licougar,
In my custom Editor (subclass of Editor2) I have commands that know how to undo themselves. I store them onto my javascript undo stack. I also have some editor2commands that call on the browser to perform operations, as well as to undo them. I’ve been pushing all commands onto my stack and everything seems to work fine. However, I am having trouble with events that don’t go through the Editor2 such as the user typing or deleting text in the editor. While i know i can capture key events, it is difficult to know which key events are grouped into a single undo transaction by the browser. So i was wondering if you had any ideas as to how i can figure out when a command gets pushed onto the undo stack of the browser…that way i can at least add some stub commands to my local undo stack and call on the browser to undo as i pop them off my stack. Or if not, any other ideas?
thanks a bunch,
-R
July 3rd, 2007 at 12:59 am
I have no idea how to detect when the native control generates an internal undo step.
The solution I have is to implement all things in javascript: just setup a timer, if in that period, no user typing, then that marks the end of a typing action.