Re: [xwiki-devs] GSoc 2011: idea "Auto Completion in Content Editors" (updated)
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+Note...) 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]>
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_... , 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... 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]>>
On Thu, Mar 24, 2011 at 7:00 PM, Marius Dumitru Florea <[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]>>> 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]>> > 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]> 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
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/ 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/ (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. 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/ (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/ (4). when user finish the up steps, they can view the inserted links in the rich editor. 2011/3/29 许凌志(Jamesxu) <[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+Note...)
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]>
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_... , 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... 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]>>
On Thu, Mar 24, 2011 at 7:00 PM, Marius Dumitru Florea <[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]>>> 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:
<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]> 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
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?
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.
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?
(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". 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+Note...)
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_..., > 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... 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
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+Note... )
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_... ,
> 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...
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
On 03/30/2011 11:21 AM, 许凌志(Jamesxu) wrote:
2011/3/30 Marius Dumitru Florea <[email protected] <mailto:[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?
It's up to you. The way you build the list of suggestions from the typed text is part of your proposal. It should be smart. Nothing stops you from including in the list of suggestions wiki pages that have the typed text in their content. You just have to weight the importance of these pages compared to those that have the typed text in their title or name. Hope this helps, Marius
> 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]> > <mailto:[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+Note...) > > > 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]> > <mailto:[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_..., > > 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... > 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]>> > > <mailto:[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]>> > > <mailto:[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]>>> > > > <mailto:[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]>>> > <mailto:[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]>> <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 > > > > > > > > > > -- > > 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] <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
Hi, followed by my previous mail for designing the auto-suggestion features for WYSIWYG rich text editor, the following is my new designation of auto-suggestion for Macros for xwiki editor: For Link and image, I will talk later in next mail, here I will focus on the designation of Macros; As Marius told me, there are some APIs for getting the list of all Macros available. and the macros in syntaxes 2.x are formatted as '{{macroName attribute1=" " attribute2=" " ... }} content {{/macroName}}', some of the attributes of specific macros may be required and some are optional. In xwiki editor, when user type "{{" to activated the auto-suggestion for macros, and the default view is a list for all available macros, user can navigate them by "up" and "down" keys, when one of the macros is focused, on the right of the suggestion box will show up a canvas for showing details of this focused macros, including a short introduction and its attribute list(see sceenshot<http://www.flickr.com/photos/44893839@N00/5573230062/in/photostream/>), when user keeps typing, the suggestion will be narrowed(see screenshot<http://www.flickr.com/photos/44893839@N00/5573230138/in/photostream/> ). After they click "Enter" key, the focused macro will be selected, and the result will be shown in the editor with its required attributes automatically added. For example, if user select "code" macro, the result are shown(see screenshot<http://www.flickr.com/photos/44893839@N00/5572640201/in/photostream/> ) Sometimes, user need to add some optional attributes for macros, and they focus cursor after one added attribute or the macro name and type space key, then it shows up a suggestion box for attributes of this macro(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230230/>), after user selects one, the selected one will be added to the attributes list in xwiki editor, for example, if user selects "CssClass" for "code" macro, then the result are shown as(see screenshot<http://www.flickr.com/photos/44893839@N00/5573230104/in/photostream/> ). Thanks if you can read all of my designation patiently, and if you can give me some advices, I will be so appreciated. 2011/3/29 许凌志(Jamesxu) <[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+Note...)
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]>
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_... , 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... 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]>>
On Thu, Mar 24, 2011 at 7:00 PM, Marius Dumitru Florea <[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]>>> 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:
<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]> 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
Hi James, On 03/30/2011 05:52 AM, 许凌志(Jamesxu) wrote:
Hi, followed by my previous mail for designing the auto-suggestion features for WYSIWYG rich text editor, the following is my new designation of auto-suggestion for Macros for xwiki editor:
For Link and image, I will talk later in next mail, here I will focus on the designation of Macros; As Marius told me, there are some APIs for getting the list of all Macros available. and the macros in syntaxes 2.x are formatted as '{{macroName attribute1=" " attribute2=" " ... }} content {{/macroName}}', some of the attributes of specific macros may be required and some are optional.
In xwiki editor, when user type "{{" to activated the auto-suggestion for macros, and the default view is a list for all available macros, user can navigate them by "up" and "down" keys, when one of the macros is focused, on the right of the suggestion box will show up a canvas for showing details of this focused macros, including a short introduction
and its attribute list(see sceenshot <http://www.flickr.com/photos/44893839@N00/5573230062/in/photostream/>),
I'm not sure the M icon is useful and the category information could be displayed differently. Otherwise it looks good. I needs to be polished of course.
when user keeps typing, the suggestion will be narrowed(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230138/in/photostream/>).
After they click "Enter" key, the focused macro will be selected, and the result will be shown in the editor with its required attributes automatically added. For example, if user select "code" macro, the result are shown(see screenshot <http://www.flickr.com/photos/44893839@N00/5572640201/in/photostream/>)
Sometimes, user need to add some optional attributes for macros, and they focus cursor after one added attribute or the macro name and type space key, then it shows up a suggestion box for attributes of this
macro(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230230/>), after user
Looks good. Note that we call them macro "parameters", not "attributes".
selects one, the selected one will be added to the attributes list in xwiki editor, for example, if user selects "CssClass" for "code" macro, then the result are shown as(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230104/in/photostream/>).
Thanks if you can read all of my designation patiently, and if you can give me some advices, I will be so appreciated.
An advice would to think about the functional specification of the autocomplete feature (what will the user be able to do, what information would be visible) and then think about the best way (from a UX point of view) to expose this functions to the user. Hope this helps, Marius
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+Note...)
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_..., > 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... 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
2011/3/30 Marius Dumitru Florea <[email protected]>
Hi James,
On 03/30/2011 05:52 AM, 许凌志(Jamesxu) wrote:
Hi, followed by my previous mail for designing the auto-suggestion features for WYSIWYG rich text editor, the following is my new designation of auto-suggestion for Macros for xwiki editor:
For Link and image, I will talk later in next mail, here I will focus on the designation of Macros; As Marius told me, there are some APIs for getting the list of all Macros available. and the macros in syntaxes 2.x are formatted as '{{macroName attribute1=" " attribute2=" " ... }} content {{/macroName}}', some of the attributes of specific macros may be required and some are optional.
In xwiki editor, when user type "{{" to activated the auto-suggestion for macros, and the default view is a list for all available macros, user can navigate them by "up" and "down" keys, when one of the macros is focused, on the right of the suggestion box will show up a canvas for showing details of this focused macros, including a short introduction
and its attribute list(see sceenshot <http://www.flickr.com/photos/44893839@N00/5573230062/in/photostream/>),
I'm not sure the M icon is useful and the category information could be displayed differently. Otherwise it looks good. I needs to be polished of course.
what about I design different icons for different category, and put them before the macro names which belong to them. for example for "Content" category, I design an icon with the word "Content" or its capitcal "C", and put it before "Activity" macro which is a content macro.
when user keeps typing, the suggestion will be narrowed(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230138/in/photostream/>).
After they click "Enter" key, the focused macro will be selected, and the result will be shown in the editor with its required attributes automatically added. For example, if user select "code" macro, the result are shown(see screenshot <http://www.flickr.com/photos/44893839@N00/5572640201/in/photostream/>)
Sometimes, user need to add some optional attributes for macros, and they focus cursor after one added attribute or the macro name and type space key, then it shows up a suggestion box for attributes of this
macro(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230230/>), after user
Looks good. Note that we call them macro "parameters", not "attributes".
Ok, remember that.
selects one, the selected one will be added to the attributes list in xwiki editor, for example, if user selects "CssClass" for "code" macro, then the result are shown as(see screenshot <http://www.flickr.com/photos/44893839@N00/5573230104/in/photostream/>).
Thanks if you can read all of my designation patiently, and if you can give me some advices, I will be so appreciated.
An advice would to think about the functional specification of the autocomplete feature (what will the user be able to do, what information would be visible) and then think about the best way (from a UX point of view) to expose this functions to the user.
Ok, after I finnish all the drafts of the designation, I will design the use case and detailed the autocompleion features.
Hope this helps, Marius
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+Note... )
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_... ,
> 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...
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
On 03/30/2011 11:31 AM, 许凌志(Jamesxu) wrote:
2011/3/30 Marius Dumitru Florea <[email protected] <mailto:[email protected]>>
Hi James,
On 03/30/2011 05:52 AM, 许凌志(Jamesxu) wrote: > Hi, followed by my previous mail for designing the auto-suggestion > features for WYSIWYG rich text editor, the following is my new > designation of auto-suggestion for Macros for xwiki editor: > > For Link and image, I will talk later in next mail, here I will focus on > the designation of Macros; > As Marius told me, there are some APIs for getting the list of all > Macros available. and the macros in syntaxes 2.x are formatted as > '{{macroName attribute1=" " attribute2=" " ... }} content > {{/macroName}}', some of the attributes of specific macros may be > required and some are optional. > > In xwiki editor, when user type "{{" to activated the auto-suggestion > for macros, and the default view is a list for all available macros, > user can navigate them by "up" and "down" keys, when one of the macros > is focused, on the right of the suggestion box will show up a canvas for > showing details of this focused macros, including a short introduction
> and its attribute list(see sceenshot > <http://www.flickr.com/photos/44893839@N00/5573230062/in/photostream/>),
I'm not sure the M icon is useful and the category information could be displayed differently. Otherwise it looks good. I needs to be polished of course.
what about I design different icons for different category, and put them before the macro names which belong to them. for example for "Content" category, I design an icon with the word "Content" or its capitcal "C", and put it before "Activity" macro which is a content macro.
+1 for graphic icons. You can use the letter icons in your prototype for now, but it would be nice to have graphic icons in the end. Thanks, Marius
> when user keeps typing, the suggestion will be narrowed(see screenshot > <http://www.flickr.com/photos/44893839@N00/5573230138/in/photostream/>). > > After they click "Enter" key, the focused macro will be selected, and > the result will be shown in the editor with its required attributes > automatically added. For example, if user select "code" macro, the > result are shown(see screenshot > <http://www.flickr.com/photos/44893839@N00/5572640201/in/photostream/>) > > Sometimes, user need to add some optional attributes for macros, and > they focus cursor after one added attribute or the macro name and type > space key, then it shows up a suggestion box for attributes of this
> macro(see screenshot > <http://www.flickr.com/photos/44893839@N00/5573230230/>), after user
Looks good. Note that we call them macro "parameters", not "attributes".
Ok, remember that.
> selects one, the selected one will be added to the attributes list in > xwiki editor, for example, if user selects "CssClass" for "code" macro, > then the result are shown as(see screenshot > <http://www.flickr.com/photos/44893839@N00/5573230104/in/photostream/>). > > Thanks if you can read all of my designation patiently, and if you can > give me some advices, I will be so appreciated.
An advice would to think about the functional specification of the autocomplete feature (what will the user be able to do, what information would be visible) and then think about the best way (from a UX point of view) to expose this functions to the user.
Ok, after I finnish all the drafts of the designation, I will design the use case and detailed the autocompleion features.
Hope this helps, Marius
> > 2011/3/29 许凌志(Jamesxu) <[email protected] <mailto:[email protected]> > <mailto:[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+Note...) > > > 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]> > <mailto:[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_..., > > 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... > 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]>> > > <mailto:[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]>> > > <mailto:[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]>>> > > > <mailto:[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]>>> > <mailto:[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]>> <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 > > > > > > > > > > -- > > 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] <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
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+Note...)
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_..., > 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... 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
On Wed, Mar 30, 2011 at 4:28 PM, Marius Dumitru Florea < [email protected]> wrote:
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+Note... )
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.
ok, I will put it into candidate list, and low its priority.
*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.
I get it now.
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.
ok, I think so now.
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_... ,
> 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...
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:
> <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
-- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University
participants (2)
-
Marius Dumitru Florea -
许凌志(Jamesxu)