Hi James, On 03/29/2011 10:42 AM, 许凌志(Jamesxu) wrote: > 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. http://jira.xwiki.org/jira/browse/XWIKI-4179 Jerome will appreciate this for sure. > 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. Note that we already have a dialog for inserting links to web pages and since offering suggestions for external URLs doesn't make much sense I think you should focus on internal links. > > *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 Images could be displayed in a better way. I think they take too much space right now. Also take into account how the user will navigate them with the keyboard. > 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/>). No, I don't think so. The user can edit the image parameters later, using the existing Edit Image dialog. > 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; The existing Upload Image dialog should be used instead IMO. > 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. Thanks, Marius > > > > > > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
