On Saturday 12 June 2004 18:41, Finlay McWalter wrote:
Jim Higson wrote:
Hi all.
I'm testing the ground for writing a java aplet based mini-editor for
mediawiki (and maybe other wikis, although the lack of a standard makes
that difficult).
What I have in mind is a relatively light applet - a more specialised
version of the generic text input, that creates well formatted wiki
markup, by allowing a syntax highlighted or whysiwyg view of the article.
This wouldn't require comunication with the server, other than uploading
the article, as happens now.
The program would be GPL, and as far as possible be designed to work with
the GNU classpath.
What do you think of this idea? My main aim is to make editing easier for
non-technical users.
Jim
It's a noble idea, but doing it properly (where it could replace the
normal mode of editing on a mature wiki like wikipedia) is *hard*.
Agreed, but I've got a year and want a good hard project :)
Doing basic wysiwyg stuff (bold, italic, links,
paragraphs) is fairly
straightforward (particularly if classpath's implementation of swing's
rich text edit thingy is in good shape). Byt wysiwyg editing of hard
stuff like floating images and tables essentially entails reimplementing
rather a lot of the browser's display code in java.
It all depends how intact the GNU classpath is, but the javax.swing.text
packages are very full for this kind of thing, floating images shouldn't
really be a problem. There are quite a few ways I could tackle it.
When I was first researching the idea (when I saw 'export as XML' on the wiki)
I thought the wikitext must be converted to an intermediatory XML format, and
then to HTML/PDF/whatever via XSL. I see that this isn't the case, which
makes the applet a lot harder, I'd have to reproduce the function of the PHP
in Java and can't help but be a step behind.
Even then,
everytime your conception of how things will look and the browser's
conception differ, you're no longer remotely wysiwyg. And then there's
stylesheets. So I think a full-featured solution is essentially
impractical, and certainly not worthwhile.
Yes, I've been thinking the same thing myself, it certainly makes the project
very difficult that the user could have a css defined. True wysiwyg in the
sense that the article looks exactly how it will when submitted is probably
impossible (well, unless browsing in HotJava...). But the user should not
rely on the oddities of their browser's rendering anyway, since the page will
look different to people with other browsers. A 'wysiwyg' editor that showed
how the page will end up in some generic, W3C compliant browser might be
helpful.
I don't think I can automatically pick up the user's css, but I could provide
them with an option to select some local file and use that.
What is practical, and I think is worthwhile, is using
the browser's
rendering engine itself for wysiwyg editing (or, in the interim, wysiwyg
preview). Implement the editor using DOM (which I fear means "in
javascript" too, in practice). I think there's enough support in DOM2
to do everything necessary, and you can realistically hope to handle
advanced stuff like images, tables, etc.
I don't know how it will work on broken browsers like IE.
FIn