8 Jun
2011
8 Jun
'11
8:01 a.m.
Hi James,
On 06/08/2011 05:14 AM, 许凌志(Jamesxu) wrote:
Hi, This days I am doing some research related to
auto-suggestion for
both wiki editor(based on textarea) and wysiwyg editor(based on iframe
designMode="on"), and I came across a problem which I think it is critical.
When suggestion list are triggered by "[["
or "{{", the "up" and "down"
keys should be forbidden in editor, instead, it should navigate the
autosuggestion list to select suggestion item user want.
The question is why should I do this, because if the insert position is
changed by "up" and "down" key when using them navigate the
suggestion
list, the insertion will not be executed properly. so when the
suggestion list is triggered, the cursor should stay where it is when
navigate the suggestion list so that when user select one item, it can
be added to the right place.
You can keep the caret in place by stopping the keyboard event for the
up/down arrow keys.
In wiki editor, because it is based on textarea, so I can listen the
keydown event, and if up and down keys are typed when suggestion list is
triggered, return false for keydown callback
functions. for example:
Where did you read that you can stop the event by returning false in the
Event.observe callback? I can't find any mention of this in
http://api.prototypejs.org/dom/Event/observe/ . What I can find is
http://api.prototypejs.org/dom/Event/stop/ . But even if you're new to
Prototype.js, you should know that the standard way to stop a DOM event
is with
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-preventDef…
(in combination with stopPropagation if needed).
I see that jQuery allows you to stop the event by returning false in the
event handler, but this should not stop you from reading the
Prototype.js documentation when something doesn't work as expected.
textAreaObj.observe("keydown", function(e){
var code = e.keyCode;
if(code==38 || code ==40){
return selectItems();
}
})
function selectItems(){
//todo:select items
return false;
}
Fortunately, it works very well, but for wysiwyg editors which is based
on iframe and its designMode="on", the same way is failed, the code is
below. the cusor will be changed by typing up and down keys to navigate
the suggestion list.
var
frm=IsIE?frames["frm"]:document.getElementById('frm').contentWindow;
I'm pretty sure document.getElementById('frm').contentWindow works fine
in IE so I don't see why you need to test the browser..
frm.document.observe("keydown", function(e){
var code = e.keyCode;
if(code==38 || code ==40){
return selectItems();
}
})
function selectItems(){
//todo:select items
return false;
}
Could anyone to give me some suggestions for this
issue.~~~
Read the documentation when something doesn't work as expected.
Marius
On Mon, Jun 6, 2011 at 2:51 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com <mailto:mariusdumitru.florea@xwiki.com>>
wrote:
Hi James,
On 06/03/2011 02:52 PM, 许凌志(Jamesxu) wrote:
OK, Marius, I am working for finnal exam all
these days after I
finishing XWIK-5560, and till now, I have finnished most of exams
except
one in 10th June, But it is easy, so I am going
on these days.
Good luck with your final exam.
Though I am busy with final exams, I still did some prepares for my
projects, I have done the following things:
1. I read the some of the source codes of wysiwyg client, found
that if
I want to listen to the event when user input in
wysiwyg editor, I
should extend the onKeyUp function in WysiwygEditor.java
<https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-client/src/main/java/org/xwiki/gwt/wysiwyg/client/WysiwygEditor.java>which
is inherited from RichTextEditorController.java
<https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-client/src/main/java/org/xwiki/gwt/wysiwyg/client/RichTextEditorController.java>.
This is not the right way to do it. As I told you on IRC, you should
create a new plugin and register there listeners for the rich text area
events that you are interested in. Check the code of the existing
plugins.
2. I am thinking that I can implement the auto-suggestion features
without working on the GWT code because there is some APIs for me to
hook in the wysiwyg editors, I can use getRichTextArea() function
to get
the richtextarea object, then add some listeners
to it.
You can do this but it's not the best choice. IMO, you should use GWT
for the client code that is specific to the WYSIWYG editor (e.g.
catching rich text area events) and use Prototype.js for the client code
that is shared between the Wiki and the WYSIWYG editor.
Here is the
sample code, in the callback function of the listeners, we can use
getSelectionRange to get the range object of rich text area, it
is the
base for add auto-suggestion widget to rich text
area, what do
you think?
document.observe('xwiki:wysiwyg:loaded',
function() {
var editors = Wysiwyg.getAllInstances();
var
IsIE=navigator.appName!="Netscape";
This is wrong. You should use cross-browser APIs as much as possible
and, if you really need to write browser specific code then use the
available Prototype.js API for checking the current browser (e.g.
http://api.prototypejs.org/Prototype/Browser/ )
for(var hookId in editors){
var editor = editors[hookId];
var richEditor = editor.getRichTextArea();
var frm = richEditor.contentWindow
if(IsIE){
frm.document.onkeyup = function(){
console.debug(editor.getSelectionRange())
}
frm.document.onmousedown = function(){
console.debug(editor.getSelectionRange())
}
frm.document.onmouseup = function(){
console.debug(editor.getSelectionRange())
}
} else {
frm.document.addEventListener("keyup", function(e) {
console.debug(editor.getSelectionRange())
} ,false);
frm.document.addEventListener("mousedown", function(e) {
console.debug(editor.getSelectionRange())
} ,false);
frm.document.addEventListener("mouseup", function(e) {
console.debug(editor.getSelectionRange())
} ,false);
You should use Prototype's cross-browser Event.observe method obviously.
}
}
})
3. For wiki editor, I think there are two most important things I
should
notice:
a. Get the position of the input cursor, and get the context, if the
cursor is in the context of "[[ link or image ]]" or "{{ macros }}",
then initialized the auto-suggestion under this context, and show up
auto-suggestion widget according to user input.
b. Listen to the user input, and trigger the auto-suggestion
widget when
"[[" or "{{" are typed.
I am still doing some tests now, so if you have some tips for me,
please
tell me.
Ok, let us know how it goes.
Thanks,
Marius
On Fri, Jun 3, 2011 at 1:02 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com
<mailto:mariusdumitru.florea@xwiki.com>
<mailto:mariusdumitru.florea@xwiki.com
<mailto:mariusdumitru.florea@xwiki.com>>>
wrote:
Hi James,
How is the GSoC work going on? Hope everything is fine. Ping
me if
you need help.
Thanks,
Marius
--
Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong
University
_______________________________________________
devs mailing list
devs(a)xwiki.org <mailto:devs@xwiki.org>
http://lists.xwiki.org/mailman/listinfo/devs
--
Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University