So, ever since finding out about Safari 1.3's HTML editing support, there have been some stirrings at the back of my mind, with the word Ajax popping up now and then. Incidentally, this epiphany is being brought to you thanks to my Blackberry, Markdown and a long cab drive.
It turns out that the biggest hang-up in my NewWikiMigration project hasn't been Python (which I'm not as familiar with as Perl, PHP, etc.), or Snakelets (which has a learning curve, but works wonderfully once you get the hang of it), or lack of time (that will be the one immovable constraint no matter what I do).
No, it's been about Wiki markup. Besides the usual issues of long-term content storage and conversion/migration to other systems (I like to think long-term, and having a database full of PhpWiki markup isn't very appealing to me), it turns out that getting perfect Markdown-HTML round-trip conversions both ways is pretty much impossible.
You end up losing blockquote, or mis-nesting lists, or even losing formatting for entire blocks of text, and that's been the case for pretty much all the umpteen variations on Textile that I've tried over the past few weeks.
And writing my own parser seems to be a considerable investment of my (pretty much non-existing) free time, for which there is no measurable return.
So, after my earlier post on web collaboration tools and my initial leaning towards storing Wiki data in some sort of XML dialect, having HTML editing in all three browsers (IE, Firefox and Safari) ties in pretty nicely, since it lets me bypass the markup issue completely and just get on with things.
Pick Atom as the basis for the XML dialect used for Wiki storage, and hey, you've got pretty much all the bases covered:
- WYSIWYG HTML editing of Wiki entries (which, again, gets rid of the whole parser thing)
- Ajax used to enhance the editing experience by:
- Providing alternative plaintext (Markdown) input, if you must have it
- Displaying a sidebar with relevant Wiki references as you type (LiveSearch-like, although I'm aiming for something more along the lines of tab completion)
- Making it easier to upload and insert images (ideally, without any popups)
- And, finally, a file-based storage back-end that:
Since most of the Ajax action seems to be around Ruby and Rails these days, and given the 47Mb video I saw yesterday (via Melo's post), I think I'll have another look at Ruby to see if it makes any of this simpler to attain.
I have Programming Ruby already, and although the language itself isn't as readable - and probably not as maintainable in the long run - as Python, the current hype around it looks promising (even after you tone it down a bit). Of course, there will be a lot to do on the HTTP optimization front (gzip encoding, the usual If-Modified-Since and caching stuff, etc.).
The only gripe I have is that I'll be spreading myself even thinner, but hey, it's a hobby.
For now, at least.