On 08/01/2011 10:08 AM, 许凌志(Jamesxu) wrote:

On Mon, Aug 1, 2011 at 2:37 PM, 许凌志(Jamesxu)<[email protected]> wrote:

...

Hi, Last week I have done following things: 1. Implemented the sub-triggers 'attach:', '@', '.' for link autosuggestion. I record a video(see:http://youtu.be/7lXeORkI6Ns) of how to use this triggers under link suggestion context. But still have some problems: a. I didn't implement the trigger for attribute "||", because the suggestion trigger type and behaviour are a bit different from the others, for example, when you type "||" the attributes of the link will be shown, and when user select one, then type '="' the value should be suggested to user, and if user want to add second attributes to the link, he can type "space" key and then the suggestion for available attributes should also be shown. The process are a bit complex, and the cost of implementation is high compare to the utility of the functions. So I decide to abandon this sub-triggers and focus on the trigger "attach:", "@" and "." only which are more useful when user add or edit links.

b. Not full tested, I test most cases I can think of, and ask my classmates to use this function and gave me some feedback, I did found some bugs, and fixed them, but I am not very sure some unexcepted bugs will come up

c. I didn't implement the default suggestions for "attach:", "." and "@" sub-triggers, I need to discuss with mentor this week.

2. Thanks Marius and Sergiu, with their help, I find all the server side search service for getting the suggestions of the link sub-triggers. 3. Thanks Marius, with his help, I can refine the default Panels.Recent Modified page to get the recent modified pages and attachmens as the default suggestions for link trigger "[[".

I didn't found the sources codes in github, could you give me the link, so I can push the changes of Panels.Recent Modified to the repositories.

https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... Thanks, Marius

...

In this week, I am going to do the following things: 1. Implement the default suggestions for sub-triggers "attach:", "." and "@". 2. Implement the ctrl+space to re-open the suggestion box according to the different contexts of link suggestion.

-- Best wishes,

许凌志(Jame Xu)

MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University

Department of Computer Science and Technology, Xi’an Jiaotong University

On Fri, Aug 5, 2011 at 6:18 PM, Marius Dumitru Florea < [email protected]> wrote:

Hi James,

On 08/01/2011 09:37 AM, 许凌志(Jamesxu) wrote:

...

Hi, Last week I have done following things: 1. Implemented the sub-triggers 'attach:', '@', '.' for link autosuggestion. I record a video(see:http://youtu.be/7lXeORkI6Ns) of how to use this triggers under link suggestion context. But still have some problems: a. I didn't implement the trigger for attribute "||", because the suggestion trigger type and behaviour are a bit different from the others, for example, when you type "||" the attributes of the link will be shown, and when user select one, then type '="' the value should be suggested to user, and if user want to add second attributes to the link, he can type "space" key and then the suggestion for available attributes should also be shown. The process are a bit complex, and the cost of implementation is high compare to the utility of the functions. So I decide to abandon this sub-triggers and focus on the trigger "attach:", "@" and "." only which are more useful when user add or edit links.

...

b. Not full tested, I test most cases I can think of, and ask my classmates to use this function and gave me some feedback, I did found some bugs, and fixed them, but I am not very sure some unexcepted bugs will come up

It works pretty well. I have some remarks though:

* I don't like the scroll bars on the list of suggestions, especially when you have to go through all the wiki pages to get to the list of attachments. I think you should display only a small number of suggestions (5-10 maximum) without any scroll bars. Of course, the size of the suggestion box (both width and height) shouldn't be fixed. You can specify a max-width and max-height but the suggestion box should expand to fit its contents. Check http://www.youtube.com/watch?v=35M2zGWZ2Fc to see how link auto-complete looks in Confluence.

Ok, I have seen the video, it is better, I will reconsider and evaluated its implementation. However I might change many codes to re-implement the suggestion box, anyway, I will list it in my work list.

* You should generate relative references. For instance, if you are editing Sandbox.Text and you select Sandbox.WebHome from the list of link suggestions then the result should be:

[[Label Text>>WebHome]]

because the target page is in the same space.

Ok, I will consider it. Some questions below: 1. how how can I get the wiki name, space name and page name of current page in javascript?

* You shouldn't change the CSS of the text area used in wiki edit mode! Right now you add the .suggestion_editor CSS class which changes the font-size and font-family, among other things. This is bad.

At beginning, I have tried many ways to avoid changing the css of the editor, but the mask which is used to loacate the suggestion box get wrong positions very often, especially when I tested it in many other computers and OS, because the original editor is not decorated with css, like fonts, line-height, so they will be changed in different systems, that is a mass for identify the suggestion box position by the mask, because the default behaviour of the div is a little different with textarea if we don't use css to fix them. That is why I add some css to editor, but much, only for font-size, font-family, line-height, word-wrap, padding, margin, this styles not change the editor too much, so I think it might not a big problem. I investigate some other implementations of the autosuggestion for textarea, like the textarea of twitter(weibo.com) in china, the editor is decorated by the same css, but without this, the location of the suggestion box for "@" will not be correct always.

* It seem that attach: works outside of the link context ([[), which is fine because we support stand-alone links (without the [[ ]] wrapping) like:

I tested in my computer, attach: outside the link context didn't trigger the suggestion. I review the code, there is a decideLinkContext function which will avoid suggesting outside the link context.

before attach:[email protected] after

but the generated syntax is messed up.

* I think it's useful to display the location for attachments too in the list of suggestions, like you do for wiki pages.

Ok, I will add it.

* Default suggestions when there is no query would be very useful.

Yes, that is what I should discuss with you. I will discuss it in next mail

Hope this helps, Marius

...

c. I didn't implement the default suggestions for "attach:", "." and "@" sub-triggers, I need to discuss with mentor this week.

2. Thanks Marius and Sergiu, with their help, I find all the server side search service for getting the suggestions of the link sub-triggers. 3. Thanks Marius, with his help, I can refine the default Panels.Recent Modified page to get the recent modified pages and attachmens as the default suggestions for link trigger "[[".

In this week, I am going to do the following things: 1. Implement the default suggestions for sub-triggers "attach:", "." and "@". 2. Implement the ctrl+space to re-open the suggestion box according to the different contexts of link suggestion.

-- 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 [email protected] 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