Hi Trevor,
Thanks for the reply! Actually I wrote this code for fun a few months ago; the core is done but there is still a lot of room for improvements ;)
I'm using a functional language called OCaml (www.ocaml.org). Have you ever heard of it?
It comes with several fancy tools; I used ocamllex to generate the lexer; and a custom parser to cope with the grammar. I didn't reused any line of the mediawiki parser, it is entirely written from scratch in pure ocaml. The ocaml code is compiled to javascript to get the js code you can see on the website. Using those tools, I've been able to set up a rather complicated program in js that I couldn't have written in a non typed language. (but perhaps because I'm a bad js programmer..)
About your questions:
1) No, I haven't check that. It is a very important issue, but if the current result is not correct it should be a matter of fixing a few bugs here and there, not a global design issue.
2) Yes, this case is not correctly handled. One more time, I didn't spent too much time on this, even if I'd love to !
3) Ah, perhaps, yes. This js is autogenerated. A friend of mine released a new ocaml->js compiler ( available from www.ocsigen.org ), perhaps his compiler will produce more compact code.
4,5) I only tested on safari and chrome where the preformance is actually quite good. Of course, the computations that were originally handled by the server have to be done by the browser, so it is slower; but with this method there is less load on the server (at least I believe so), the load is distributed to the users; it is a nice scheme for a community project isn't it ;)?
5) Well, the best should probably that you have a look to the source code. I can put it on github if you want; would you be interested? Is there an ocaml developer on the list that could give his opinion about the global process ?
Thanks !
William
2010/8/13 Trevor Parscal tparscal@wikimedia.org:
This looks very interesting.
1. Have you been checking the cleanliness of your diffs? 2. It seems like some of the links which link to a different word than the label text are being rendered incorrectly. Examples include "parents" and "joint ventures" in the second paragraph. 3. This page uses an enormous amount of JavaScript code... Even after combining all 161 JavaScript files, minifying them with JSMin, and compressing them with GZip, we're looking at 209KB, which is miraculous when you consider it started out as 2.4MB, but still, yes, trimming would help. Here's the stats for the files in various stages. -- 2408505 bytes (2.4 MB) wysiwyg.combined.js -- 1136034 bytes (1.1 MB) wysiwyg.combined.min.js -- 208361 bytes (209 KB) wysiwyg.combined.min.js.gz 4. What's browsers does this work in? 5. What's the performance like in less-modern browsers (if it supports them) such as any Internet Explorer browser, especially IE 6 and 7 which have some of the slowest JavaScript interpreters among the more common browsers. 6. What is your Wikitext > HTML / HTML > wikitext system using to parse and how much of the document does it understand as opposed to passively transform? Regex? BNF? Anything particularly cool or new? Just a port of the existing MediaWiki parser?
Let me also say, thank you for your work in this field, it's a very important area for research and development to be taking place, both at the foundation but most importantly in the community.
- Trevor
On 8/13/10 8:27 AM, William Le Ferrand wrote:
Hi,
I sent a mail several months ago on this list to 'advertise' for a wysiwyg editor for wikipedia. It is still hosted on a server, for instance if you attempt to edit the page Open_innovation you get that : http://www.myrilion.com:8080/wysiwyg?article=Open_innovation
The point with this editor that it is fully client based: the wiki markup is transformed in html on client side, edited as html through a javascript editor and then transformed back to mediawiki markup on client side as well.
The code of the translation engine is written in OCaml (www.ocaml.org) and compiled to javascript.
If anyone here is interested I'll be happy to clean the sources and to release it as an opensource project.
All the best,
William
2010/8/13 Павел Петроченкоpavel@onpositive.com:
Hi, glad to present our first demo on editing media wiki articles: http://www.screencast.com/t/NmMzMjVkNjUt Regards, Pavel
2010/8/3 Павел Петроченкоpavel@onpositive.com
Hi,
Yes, of course we are interested on it. Specifically, the ideal WISIWYG MediaWiki editor would allow easy WISIWYG editing to newbies, while still allowing to use the full wikisyntax to power users, without inserting crappy markup when using it, or reordering everything to its liking when WISIWYG was used to do a little change.
Thanks for the note, it may be an important issue.
From the screencast, it seems your technology is based in a local application instead of web. That's is a little inconvenience for the users, but an acceptable one IMHO. You could plug your app as an external editor, see:
http://www.mediawiki.org/wiki/Manual:External_editors
Yep according to my understanding this is major problem, but unfortunately we are rich client developers, so going web is only in our future plans. (Actually we are thinking about moving to it, but waiting for a first customer to help with transition)
On other side being a rich client app may add some benefits for advanced users, which are still hard to do in web apps (according to my poor desktop developer understanding).
custom groupings, personal inbox, local for work flow/validation rules and review. (just as initial examples)
The problem that makes this really hard is that MediaWiki syntax is not nice. So I'm a bit skeptical about that fast quality editor. You can find in the list archives many discussions about it, and also in
wikitext-l.
Things like providing a ribbon is a completely esthetical choice, it can't really help on the result of its editing. Maybe your backend is powerful enough to handle this without problems. Please, show me wrong :)
Yep - already meet some crap in dealing with it(much more complex than, Trac wiki one). But still hope to over helm most of problems, in a couple of month
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
Yes, this is one of pote
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Actually we are going to be open source and cross platform (we are Eclipse RCP based)
That was very interesting. Any chance the rest of us can try it for ourselves?
Our media wiki support is at very early stage now. Actually we are still not sure how much we are going to be committed into it, If there will be enough interest (at least couple of volunteer beta testers), we will start publishing builds somewhere.
Regards, Pavel OnPositive Technologies.
2010/8/3 Neil Kandalgaonkarneilk@wikimedia.org
On 8/2/10 9:29 AM, Павел Петроченко wrote:
Hi guys,
At the moment we are discussing an opportunity to create full scale true WYSIWYG client for media wiki. To the moment we have a technology which should allow us to implement with a good quality and quite fast. Unfortunately we are not sure if there is a real need/interest for having such kind of client at the media wiki world, as well as what are actual needs of media wiki users.
Definitely interested.
As for what the needs of MediaWiki users are, you can check out everything on http://usability.wikimedia.org/ . We are just beginning to address usability concerns. This study might be interesting to you:
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study
P.S. Screen cast demonstrating our experimental client for Trac wiki
That was very interesting. Any chance the rest of us can try it for ourselves?
I personally like the idea of a ribbon. I think we can assume that most wiki editors are always going to be novice editors, so taking up tremendous amounts of space by default to explain things is warranted. Experts should be able to drop into raw wikitext, or otherwise minimize the interface.
I don't have an issue with there being a closed source Windows app that edits wikitext well, but then there is going to be a bit of a difficult transition from reading to editing and back again.
And just FYI, generally our community is more interested in free and cross-platform software than proprietary, single platform software.
Still it looks interesting. Please let us know more.
-- Neil Kandalgaonkar (|neilk@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l