2011/3/30 Marius Dumitru Florea <[email protected]> > Hi James, > > On 03/29/2011 06:13 PM, 许凌志(Jamesxu) wrote: > > Thanks Marius for giving me a quick response for my new designation in > > IRC, he gave me two short advices > > 1. Using "p:", "a:", "i:" for triggering the auto-suggestion might not > > be suitable for some users who are not familar with English, because > > "p",a","i" are the first characters of English words. > > 2. Suggestion for wikipage and attachments should be combined together, > > In my previous designation, I seperated them. > > > > I am considering these two advices carefully, > > for the first advice I think it is true not suitable to use "p","a","i" > > for triggering auto-suggestion, according to the confluence, we can > > change them into "[[" for links , "!" for images > > > > for the second advice, I think combine wikipage and attachments > > suggestion together could be easier for users to get quick suggestion > > without remembering more shortcuts. > > > > According to the two advices, I re-design the auto-suggestion for > > wikipage and attachments in the following: > > (1). User type "[[" to trigger suggestion, and the default contents in > > suggestion box are shown in the following, I design two, they all > > contains the list of wikipages user recently changed, and also a list of > > attachments of this wikipage. The difference is that in the first > > design(image 1), at the top of wikipage list, there is a search form for > > searching wikipages(the function is implemented in WYSIWYG rich text > > editor, link dialog), and the second one is without the wikipage search > > form(image 2). > > --------------------------------------------- > > > Image 1(with search form) --- view > > by:<http://www.flickr.com/photos/44893839@N00/5571391228/> > http://www.flickr.com/photos/44893839@N00/5571513534/in/photostream/ > > Why do you think the search is needed? Isn't the user actually searching > when she types after the autocomplete feature is triggered? >
I am confused about the search functions, IMO the auto-suggestion for links will be narrowed according to what user have inputted, for example if user have inputed "xwiki", then a list of pages whose name starts with "xwiki" will list in suggestion box, but I found the search function in the existed "link" widget not do the same way, it seems to search full-text, not limited to the title. I wondered which functions should be suitable for auto-suggestion? > > > Image 2(without search form) ---- view > > by:<http://www.flickr.com/photos/44893839@N00/5571391200/in/photostream/ > >http://www.flickr.com/photos/44893839@N00/5571513478/in/photostream/ > > The panel title and the link at the bottom should be updated since you > offer suggestions for attachments also. Otherwise it looks good. > > > > > (2). when user keep typing, the suggestion will be narrowed according to > > the user input(as shown in image 3), if there is no wikipage or > > attachment, there will be a quick link "Add new page(in current page)" > > for adding a new wikipage. and also a quick link "upload new file" for > > add new attachments. > > I really think that typing should trigger a search on the existing wiki > pages and attachments and not just filter the recently modified pages. > ok, I have found that, i will fixed it later. > > > if user select upload new file, then, the suggestion box change the > > context to attachment uploader shown in Image 4 > > -------------- > > Image 3(narrowed suggestion) --- view > > by:http://www.flickr.com/photos/44893839@N00/5571559670/ > > > Image 4(attachment uploader) --- view > > by:http://www.flickr.com/photos/44893839@N00/5570955919/ > > Why not opening the existing Upload Attachment dialog instead? > Yes, that is what I am thinking about, at the beginning I designed two senario, the one is to navigate to the existing upload attachment dialog. but I thought if so, there will be a overlay showed up to cover the editor, it might slow down the user input, so I move it to the auto-suggesion box, but I think it is easy to link it directly to the existing upload attachment dialog, and follow the stragtegy "insert quickly, edit later".as you said. > > > > > (3). if user select one wikipage, the suggestion box change the context > > to link editor as shown in Image 5 > > --------------- > > Image 5(link editor) --- view by: > > http://www.flickr.com/photos/44893839@N00/5571543390/in/photostream/ > > I don't think it's important to fill at the link parameters. The label > for instance can be edited in-line and the tool tip is not that > important. In most of the cases inserting the link with the default > settings and then letting the user edit the link is better. IMO the goal > is to allow users to insert links quickly and easily. The link wizard > will continue to be available on the WYSIWYG editor menu for those that > want to go through all the steps. So the strategy should be "insert > quickly, edit later". > I love the strategy "insert quickly, edit later", I will remove the link editors from the auto-suggesion box to make it much more lightweight > > Hope this helps, > Marius > > > > > (4). when user finish the up steps, they can view the inserted links in > > the rich editor. > > > > 2011/3/29 许凌志(Jamesxu) <[email protected] > > <mailto:[email protected]>> > > > > Dear Marius > > > > I think you are right that I misunderstood the WYSIWYG source editor > > and WYSIWYG rich text editor, in my previous designation, I have > > spent so much effort on how to auto-suggest or auto-complete for > > some specific xwiki syntaxes, though those features might be > > convienent for users, it is uneccessary, because they do care about > > inserting image ,link, or some macros faster, instead of > > autocompleting the syntaxes of them in source editor. > > > > As you said, the effective way to speed up is to insert or edit them > > without leaving keyboard, we can design some shortcuts for > > auto-suggestion based on context. And the auto-suggestion should > > focus on image, link and some common used macros first. > > > > For current WYSIWYG rich text editor, when users need to insert > > image,link or macros, they have to leave their keyboard and click on > > the link, image or macro icons on the toolbar of rich text editor to > > insert them, it must slow down the speed. > > For solving this problem, we can design some shortcuts to activate > > the auto-suggestion for links, images or macros according to user > > input and context. I think the autocompletion features for > > confluence rich text editor can be a good example for me > > ( > http://confluence.atlassian.com/display/DOC/Confluence+3.2+Beta+Release+Notes > ) > > > > > > And I think I should also focus on auto-suggestion for links, images > > first. , I have to discuss with you which macros should be > > considered further, or you can give me some advice for macros > > auto-suggestion features for WYSIWYG rich text editor. > > Here are my new designations: > > > > *Links:* > > There are 4 kinds of links: wiki page, attachment files, url and > > email link. > > (1). wiki page: > > Auto-suggestion functions are triggered when user types "*p:*", then > > it shows up a suggestion box bellow cursor to list the current wiki > > pages the user visited as default(see screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570694194/in/photostream/>), > > when user keep typing, they will get recommendations(see screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570694220/in/photostream/>). > > > > > > (2). Attachment files: > > Auto-suggestion for attachment is triggered by typing "*a:*", it > > also shows up a suggestion box with a list of attached files of > > current pages(see screenshot > > <http://www.flickr.com/photos/44893839@N00/5570143783/>), user can > > click on the link "upload new file" on the top of the list to lauch > > a quick attacment upload form(see screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570143805/in/photostream/>), > > after uploading the attachment, user can edit it as shown in this > > screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570732742/in/photostream/>. > > > > Another much easier way is to supply with users a quick link to the > > "attacment uploader" widget, and user do the following process in > > this widget. > > > > (3). URL and Email. > > Usually user will add(might paste) url or email direct into rich > > editor, the rich editor should make it a real url or email link to > > the target. There are two ways to do that: > > > > First, as gmail rich editor, there is a url icon on the toolbar(See > > screenshot <http://www.flickr.com/photos/44893839@N00/5570022483/>), > > after selecting the url text (see screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570022507/in/photostream/>)and > > click the icon, the url text can be automatically changed to a real > > url or email link(see screenshot > > <http://www.flickr.com/photos/44893839@N00/5570029069/>). > > Second, as microsoft word, when you type a url or email link, it > > will be automatically changed to a real link. > > > > When user clicks on the url or email link, there will be a minimal > > url infromation box with edit link for it will show up(see > > screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570022537/in/photostream/>), > > and user can click on it to edit the url. > > > > *Images:* > > The images insertion are triggered by typing "*i:*", and in the > > suggestion box, it lists all the images in this page(see screenshot > > <http://www.flickr.com/photos/44893839@N00/5570183615/>), user > > select one and enter the editor page for editing details for the > > selected image(is it neccessary?)(see screenshot > > < > http://www.flickr.com/photos/44893839@N00/5570772796/in/photostream/>). > > User can also upload new images by clicking on the link "upload new > > images" at the top of list, there will be an uploader form in the > > box for user to upload image, and the uploaded image will be > > automatically inserted into the rich editor; > > Another much easier way is to supply with users a quick link "open > > the image dialog" in the box which links to the image uploader > > widget(existed); > > > > For xwiki editor, it will be a bit different, because user type > > xwiki syntaxes in xwiki editor, so the auto-suggestion should not > > only for links, images, but also some attributes of these syntaxes, > > especially for the attributes of various macros, the design details > > will be sent to you later. > > > > > > > > > > > > > > > > 2011/3/28 Marius Dumitru Florea <[email protected] > > <mailto:[email protected]>> > > > > Hi James, > > > > On 03/26/2011 02:58 PM, 许凌志(Jamesxu) wrote: > > > Dear serg and marius, > > > > > > These days I am focus on two things: > > > > > 1. Design the auto-suggestion scenarios, and now it have been > > down as a > > > draf, because the docs are very long, and with lots of > > pictures, so I > > > upload it to the google doc, I invited you to view this doc > > in the > > > following > > > > > link: > https://docs.google.com/document/pub?id=1dRp-d0Lj9b4Tf9YWEQgaPuDBk3N3Bw0GvP_LrrviCeU > , > > > and I have also sent you the invitation for editing this > > document. > > > I also upload pictures envolved in the doc to flicr, the url > > link is > > > under each picure, so that you can see the big picture more > > clearly. > > > > I see you already put a loot of effort into writing this draft. > Be > > careful with that. You shouldn't spend time on details before > > you know > > you're going into the right direction. First, make sure you > > understand > > correctly what we expect from the project, by asking questions > > on this > > mailing list. Then you should start with small examples, for > > only one > > syntax element (link/image/macro). > > > > Regarding your draft, I think it's too syntax oriented. You have > to > > understand that the content is king. The scope of this project > > is _not_ > > to help users learn the XWiki 2.0 syntax but to speed up content > > creation/editing using the WYSIWYG/wiki editor. > > > > Basic users don't care that image syntax starts with [[image: or > > that > > bold syntax is enclosed in **. They just want to insert an image > > quickly. > > > > Text formatting is not a problem for the WYSIWYG editor users > > because > > they already know that Ctrl+B makes text bold. They don't have > > to type > > ** or remember a shortcut key that will open a suggestion for **. > > > > So for the WYSIWYG editor (the rich text area, not the source > text > > area!) you have to focus only on link, image and macro syntax > > (macro is > > very important!). In the end the user should be able to insert a > > link, > > an image or a macro quickly, without leaving the text area, > > using only > > the keyboard. > > > > The wiki editor should behave almost as the WYSIWYG editor. One > > of the > > differences could be that the wiki editor offers autocomplete > > suggestions for the link, image and macro parameters (which > > doesn't make > > sense in the WYSIWYG editor because you don't see the XWiki 2.0 > > syntax > > of a link/image/macro but their output). > > > > > > > > 2.I am build the develop environment for wysiwyg editors > > follow marius' > > > introduction. and finnally get the compiled war file, but I > > came across > > > a problem: where is the entry for it, I tried > > > "localhost:8080/wysiwyg/gwtrpc.gwtrpc" and also > > > "localhost:8080/xwe/gwtrpc.gwtrpc", according to the web.xml > > file under > > > the war file, but both I got 404 error page, could you give > > me the right > > > entry for it? > > > > The WYSIWYG editor can be used outside of XWiki but its main > > features: > > link, image and macro insertion/editing are XWiki specific and > > thus are > > available only when you use the editor inside XWiki. > > > > The best approach is to download the latest XWiki Enterprise > > snapshot > > from > > > http://maven.xwiki.org/snapshots/org/xwiki/enterprise/xwiki-enterprise-jetty-hsqldb/ > > and update the WYSIWYG editor: > > > > * overwrite the jars from WEB-INF/lib with the ones from the > WYSIWYG > > editor's war (only if you made changes to the server side) > > * replace the /resources/js/xwiki/wysiwyg/xwe directory with the > one > > from the WYSIWYG editor's war (don't overwrite! remove the > existing > > directory and copy the new one) > > > > Don't forget to build xwiki-gwt-wysiwyg-war module using -Pdev > > profile > > so that it doesn't generate all the GWT permutations. > > > > Hope this helps, > > Marius > > > > > > > > This is the web.xml file: > > > <?xml version="1.0" encoding="ISO-8859-1"?> > > > <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xmlns:web="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; > > > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; > > > version="2.4"> > > > > > > <display-name>xwe</display- > > > name> > > > <description>XWiki's WYSIWYG Editor</description> > > > > > > <!-- This filter is used to convert the HTML generated by the > > WYSIWYG > > > editor to source syntax --> > > > <filter> > > > <filter-name>ConversionFilter</filter-name> > > > > > > <filter-class>com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter</filter-class> > > > </filter> > > > > > > <!-- This filter is used to initialize the XWiki context > before > > > processing a request. --> > > > <filter> > > > <filter-name>XWikiContextInitializationFilter</filter-name> > > > > > > <filter-class>com.xpn.xwiki.wysiwyg.server.filter.XWikiContextInitializationFilter</filter-class> > > > </filter> > > > > > > <filter-mapping> > > > <filter-name>ConversionFilter</filter-name> > > > <url-pattern>/*</url-pattern> > > > </filter-mapping> > > > > > > <filter-mapping> > > > <filter-name>XWikiContextInitializationFilter</filter-name> > > > <servlet-name>gwtrpc</servlet-name> > > > </filter-mapping> > > > > > > <!-- This is the entry point for all component-based XWiki > > GWT services. --> > > > <servlet> > > > <servlet-name>gwtrpc</servlet-name> > > > > > > <servlet-class>com.xpn.xwiki.wysiwyg.server.XWikiRemoteServiceServlet</servlet-class> > > > </servlet> > > > > > > <servlet-mapping> > > > <servlet-name>gwtrpc</servlet-name> > > > <url-pattern>*.gwtrpc</url-pattern> > > > </servlet-mapping> > > > </web-app> > > > > > > > > > 2011/3/26 许凌志(Jamesxu) <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected] > >>> > > > > > > > > > > > > On Thu, Mar 24, 2011 at 7:00 PM, Marius Dumitru Florea > > > <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > > > > > > > > > > > On 03/24/2011 08:51 AM, 许凌志(Jamesxu) wrote: > > > > > > > > > > > > On Thu, Mar 24, 2011 at 10:54 AM, Sergiu Dumitriu > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > > > On 03/22/2011 03:37 AM, 许凌志(Jamesxu) wrote: > > > > > Hi Marius Florea, > > > > > > > > > > Thanks for your reply, it is really helpful for me to go > > > > further. > > > > > > > > > > For xwiki syntaxes, you gave me a good suggestion that I > > > should not > > > > > autocomplete all the attributes for a tag, it could be > > > added when > > > > user > > > > > triggers by some inputs or by the hotkeys just like > eclipse > > > HTML > > > > editor. > > > > > > > > > > However, in my opinion, for some syntaxes, to suggest > > user some > > > > required > > > > > atrributes would be helpful for them to make less > > mistakes, and > > > > it is more > > > > > intuitive for them to fullfill the blank attributes which > are > > > > required. > > > > > > > > +1, mandatory attributes should be inserted. > > > > > > > > > > > > > Anyway, I haven't gone through and evaluate all the xwiki > > > > syntaxes, I should > > > > > finished this step first, and then think about the use > > case for > > > > some of > > > > > these syntaxes. Here are my steps for preparation before > > > coding: > > > > > > > > > > - Go through and evaluate all the xwiki syntaxes, to find > > out a > > > > list of > > > > > syntaxes which are suitable to implement autocompletion > > > features > > > > > > > > > > > The main target is xwiki/2.0 (and xwiki/2.1 which is almost > > > the same > > > > thing). Any other syntax is just a bonus. > > > > > > Thanks to its (relatively) new rendering engine ( > > > http://rendering.xwiki.org ) XWiki is a polyglot wiki. Before > > having > > > this new rendering engine we used Radeox for rendering wiki > > > pages and > > > the only supported syntax was xwiki/1.0. With the new > rendering > > > engine > > > we introduced xwiki/2.0 syntax as the default syntax for wiki > > > pages and > > > marked xwiki/1.0 syntax as deprecated. xwiki/2.1 syntax is > > now under > > > development, trying to fix some of the limitations of the > > > xwiki/2.0 syntax. > > > > > > > > > Thanks for the introduction to the xwiki syntax rendering > > machanism, > > > I know better now, it will be very helpful in my future work; > > > > > > > > > Taken this into account, the main target is, as Sergiu said, > the > > > xwiki/2.0 syntax. Of course, it would be great if you can come > > > with a > > > design that allows us to easily add autocomplete support for > > other > > > syntaxes in the future. So basically you should split your > code > > > in two: > > > a part that is syntax independent and a part that is specific > to > > > xwiki/2.0 syntax. And the second part should be as much as > > possible > > > plugable. > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > I install the xwiki/3.0, but I haven't found the > > > autocompletion features > > > > for the wysiwyg editor. > > > > > > Note that the wiki syntax version is independent from the > XWiki > > > Enterprise version. The latest XE release is 3.0RC1 and it > uses > > > xwiki/2.0 as the default syntax for its wiki pages. XE 4.0 > > might use > > > xwiki/2.1 as the default syntax for its wiki pages. > > > > > > As Caty told you, neither the WYSIWYG editor nor the wiki > editor > > > have > > > syntax autocomplete implemented. > > > > > > > you refered "xwiki/2.1 which is almsot the same thing", I > > > didn't catch > > > > the meaning for the "same thing". > > > > > > > > Do you mean some of xwiki syntaxes have been implemented for > > > > autocompletion features in WYSIWYG editor of xwiki/2.1? > > > > If so, could you give a link for introducing these features. > > > > > > > > > > > I have already found the only doc > > > > "http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax"; > for > > > > introduction the xwiki syntaxes 2.0, and after reading > > > through, I found > > > > the newest version of xwiki syntaxes is 2.1, so could you > > > give me some > > > > docs about syntaxes 2.1, and could you explain to me, what > > > kind of xwiki > > > > syntaxes versions used in different version of xwiki. > > > > > > xwiki/2.1 syntax is still under development, that's why it > isn't > > > fully > > > documented. > > > > > > > > > > > > > > > > - Design the use cases with some screenshots for them, > just > > > like > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/UserStatusProposal > > > > > - Pick some to implement the prototype of them to get the > > > > feedbacks from the > > > > > mailing list > > > > > - Start to coding for all of them > > > > > > > > Good plan. The best approach is to have something working > > > ASAP and then > > > > incrementally improve/build upon it. > > > > > > > > > > > > > > > Thank you, these days I have read all the docs from "xwiki > > > development > > > > zone <http://dev.xwiki.org/xwiki/bin/view/Main/WebHome>", > it > > > is really > > > > helpful for me to understand how to contribute to xwiki, I > am > > > trying to > > > > download xwiki WYSIWYG editor source codes and building > them, > > > try to > > > > have a look its source files. > > > > I think it is the neccessary things I am have to do before > > > coding. > > > > > > The WYSIWYG editor sources are in > > > http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/ . The > > > xwiki-gwt-wysiwyg-war module packages the > > > xwiki-gwt-wysiwyg-server and > > > the xwiki-gwt-wysiwyg-client modules. The > > xwiki-gwt-wysiwyg-client > > > module depends on xwiki-gwt-wysiwyg-plugin-api, > > xwiki-gwt-user and > > > xwiki-gwt-dom modules. > > > > > > > > > I have downloaded all the code under > > > http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/ , and > > build > > > with maven in eclipse. > > > finally I got a war file > > > "xwiki-web-gwt-wysiwyg-war-3.1-SNAPSHOT.war", I renamed it to > > > "wysiwyg.war" and put it uder tomcat6.0.18,I also look > > through the > > > web.xml file under this war file, I found the entry is > > > "localhost:8080/wysiwyg/gwtrpc.gwtrpc" according to the > web.xml > > > file, but I got nothing excpet the 404 error. > > > I think maybe the entry url is wrong, but what is the right > url, > > > according to the web.xml file bellow, I also tried > > > "localhost:8080/xwe/gwtrpc.gwtrpc", but resulted in the same > > error; > > > > > > <?xml version="1.0" encoding="ISO-8859-1"?> > > > <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xmlns:web="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; > > > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; > > > version="2.4"> > > > > > > <display-name>xwe</display-name> > > > <description>XWiki's WYSIWYG Editor</description> > > > > > > <!-- This filter is used to convert the HTML generated by the > > > WYSIWYG editor to source syntax --> > > > <filter> > > > <filter-name>ConversionFilter</filter-name> > > > > > > <filter-class>com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter</filter-class> > > > </filter> > > > > > > <!-- This filter is used to initialize the XWiki context > before > > > processing a request. --> > > > <filter> > > > <filter-name>XWikiContextInitializationFilter</filter-name> > > > > > > <filter-class>com.xpn.xwiki.wysiwyg.server.filter.XWikiContextInitializationFilter</filter-class> > > > </filter> > > > > > > <filter-mapping> > > > <filter-name>ConversionFilter</filter-name> > > > <url-pattern>/*</url-pattern> > > > </filter-mapping> > > > > > > <filter-mapping> > > > <filter-name>XWikiContextInitializationFilter</filter-name> > > > <servlet-name>gwtrpc</servlet-name> > > > </filter-mapping> > > > > > > <!-- This is the entry point for all component-based XWiki GWT > > > services. --> > > > <servlet> > > > <servlet-name>gwtrpc</servlet-name> > > > > > > <servlet-class>com.xpn.xwiki.wysiwyg.server.XWikiRemoteServiceServlet</servlet-class> > > > </servlet> > > > > > > <servlet-mapping> > > > <servlet-name>gwtrpc</servlet-name> > > > <url-pattern>*.gwtrpc</url-pattern> > > > </servlet-mapping> > > > </web-app> > > > > > > > > > The wiki editor is a plain HTML text area so it doesn't have > any > > > code. > > > > > > > > > > > > > > > >> Good knowledge of JavaScript, DOM and OOP (for the GWT > > > code) is the > > > > >> basic requirement to finish this project. > > > > > > > > > > I think javascript, DOM, OOP would not be a problem for > me, I > > > > used it almost > > > > > everyday for 3 years, and and experienced with dojo, > > jquery, I > > > > also wrote > > > > > some tutorial for them, GWT is some kind javascript lib > like > > > > them, though > > > > > there are some differences, I think I would be a quick > > learner > > > > for it, since > > > > > now, I have learned it for a while. > > > > > > > > > > > > > GWT is not quite another JavaScript library. It's actually > > a Java > > > > toolset which compiles a form of Java code into JavaScript. > > > > > > > > > > > > Yes, you are right, I am reading the docs of GWT now, it is > > > pretty > > > > different from normal javascript tools, foutunitly, I am > > > practiced in > > > > Java and javascript, though it is weild to get to know GWT > at > > > first, and > > > > now, I think it is not so difficult, and I am now > downloading > > > the source > > > > code of WYSWYG editors, trying to understand the structure > > > using GWT, > > > > and aslo read some samples from GWT documentation center. > > > > > > > > > > > > > > > Personally I'm against using GWT here, and I'd prefer > > > something using > > > > basic Prototype.js > > > > > > Sergiu, you are against using GWT for the wiki editor only, > > right? > > > Anyway, the autocomplete feature should have the same look and > > > feel in > > > both the WYSIWYG and wiki editor. A basic design would be to > > > have three > > > modules: > > > > > > (1) Determine the context based on the current selection/caret > > > (2) Offer suggestions based on the context > > > (3) Output the selected suggestion in the target syntax > > > > > > (1) and (3) depend on the editor/syntax, but (2) should be the > > > same: it > > > doesn't matter the editor or the syntax when you display a > > list of > > > documents to choose from in order to create a link. > > > > > > The language used to implement (1) and (3) depends on the > target > > > editor. > > > I think we should use GWT for the WYSIWYG editor and > > > Prototype.js for > > > the wiki editor. The question is what to use for (2). Sergiu > > clearly > > > prefers Prototype.js and I'm ok with that. > > > > > > Hope this helps, > > > Marius > > > > > > > > > > > > > > > It is a good idea to use some native javascript tools like > > > Prototype, I > > > > have used Prototype for more than 4 years, and also I am a > > > fans of dojo > > > > and jquery, I think the the WYSIWYG could be implemented as > a > > > prototype > > > > or dojo module. > > > > > > > > However, I think the first thing we should do is to work on > the > > > > autocompletion idea based on GWT, cause till now, the editor > is > > > > implemented by GWT, it would be easy to move on. > > > > > > > > > > > > -- > > > > Sergiu Dumitriu > > > > http://purl.org/net/sergiu/ > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[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 > > > _______________________________________________ > > > devs mailing list > > > [email protected] <mailto:[email protected]> <mailto:[email protected] > > <mailto:[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 > > > > > > > > > > > > > > > -- > > > Best wishes, > > > > > > 许凌志(Jame Xu) > > > > > > MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University > > > > > > Department of Computer Science and Technology, Xi’an Jiaotong > > University > > > > > > > > > > -- > > Best wishes, > > > > 许凌志(Jame Xu) > > > > MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University > > > > Department of Computer Science and Technology, Xi’an Jiaotong > University > > > > > > > > > > -- > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
