Paul Hammant's Blog: An alternative to wikis

Wiki reticence

The development community has struggled to deliver a fantastic documentation tool or technology that is universally popular. There have been many attempts at a system that allows developers to document projects or users to edit more general content easily. When XML felt like a cure-all, XML generated into sites was a popular option. Refer DocBook and predecessors.

One might have thought that Wikis were that panacea, but there are grumblings. The barrier to entry for content editing may have been lowered and needless workflow stripped away, but there is real reticence about text areas in web pages for editing. Whether a cunning markup language or a fancy Web2.0 WYSIWYG editor there are some that elect to not edit content that way. You can try to compare and contrast many of the wiki implementations, but there grumbles persist. Choose your best from wikimatrix and I bet there are still grumblings on use. Some people think tagging is a redeeming factor, particularly for those wiki apps that did not retrofit the feature, but the in-a-webpage gripe persists. Personally I’m sick of that side of wikis. Sorry Ward.

I outline here an alternative to wikis for content editing. I think it is quite smooth to use. Others may not.

Enter DAV and live editing of pages

WebDAV (or just DAV) is more or less an extension to HTTP that allows for the live modification of pages amongst other things.

SeaMonkey (renamed from ‘Mozilla Suite’ some time ago) is essentially the same browser engine as Firefox, but with Mail, News and page editing built in. The page editor is known as Composer and is the continuation of an idea from the mid 90’s that existed in Netscape’s now dead ‘Communicator’ product. Communicator was the bigger brother to Navigator. Incidentally I really like Joel’s article on refactoring versus rewrite , or at least the original take on it. It concerned the whole Netscape Navigator becomes Mozilla initiative.

Composer has spawned some forks. The first, NVU is Composer wrapped in some Dreamweaver-like site functionality. Its pretty good but has one serious flaw to me. It cannot be launched from the command line with a first argument of the page to edit. It simply launches and ignores the page-to-edit argument. The second is a fork of that called KompoZer and seems to exist because NVU is stagnant in terms of development.

Simple WebDAV editing experience with SeaMonkey

You start on a page. Any page. In the case below it is a missing page. At least it was missing when I took these screen snaps.

Then you do a Ctrl-E (Apple-E on Mac), to do into edit mode:

It is a full WYSIWYG editor. A thick rather than thin UI. I’m guessing that it uses Mozilla’s famed Gecko rendering engine under the hood. It is also quite a pleasant experience, reminiscent of the high bar document editing experience. That is MS Word of course, but this one is pitched towards HTML editing rather than .doc editing. There are many reasons why the former is more desirable than the latter.

When you’re happy you hit the publish button (or hot key) to push it back to the server:

You will note that the publishing site (PUT) is different to that for the GET. That is a slight of hand that is not always necessary, but is for the sake of the particular server setup we’re using for this discussion.

Then you can refresh the view of the browser and see it again:

Its all quite simple. Perhaps it would have been less confusing were I not to have left the page title/content “404: Not found” etc.

Separation of Content and style

It is clear that decent websites are more sophisticated than simple static pages linking to each other. Most have navigation bars at the top, or down one site, and standardized footers not to mention active content. Thus it is really desirable to have a way to separate the content from styling/skinning/look and feel.

So the nirvana for me, is a web application the in view mode is very polished and a pleasurable experience. The pattern is ‘The decorator’ and the dominant implementation for servlets is Sitemesh (which has a .Net port). -My blog uses Sitemesh to separate static content from styling. Contrast /blog/did-you-send-this.html to /blog/did-you-send-this.html (hit cancel on the print dialog). You’re seeing the contrast between one decorator for the ‘site’ experience and another for the minimalistic printable form ( not quite the undecorated form)-.

[ Note: In 2011, my blog no longer uses Sitemesh - it’s Jekyll + Github-Pages now ]

What I’d love to be able to do is seamlessly use SeaMonkey to edit the raw form of a page, via the website, without a second domain to handle the DAV updates. This would mean that the web app behind the site in question would need to be able to tell the difference between a page request from the browser component of SeaMonkey versus Composer. There’s a note on the mod_dav page that suggests it is impossible for mod_dav to conditionally serve up raw versus presented pages.

A feature I would also like to see, is each DAV edited page to have its head revision bumped on the server side when published. ‘Head revision’ implying source control invisibly activated behind mod_dav. Subversion would be the ideal candidate seeing as it is DAV capable already.

Considering the undecorated/decorated problem again, there is a Microsoft proposed extension to HTTP that would allow the requesting application to ask for something ‘untranslated’ (unstyled, unexecuted, raw .. whatever you’re preferred term is). The HTTP header command was @translate: f@ . It was not popular. Principally because if left on by default it would give away the source for your website when that might not have been your intent.

For this to work, server side applications do need to be able to differentiate between requests from browsers and editors. The simplest way I found was to hack SeaMonkey to do exactly that [next section] though not a full blown @translate: f@ solution.

Hacking SeaMonkey

Similar to the way that Sitemesh works with printable decorators, its easy to add a query string argument to the request to the webserver. Thus editMode=true feels to be a sensible argument name.

1) Install SeaMonkey.

2) go to its chrome directory that contains comm.jar in a command shell

3) Do jar -xf comm.jar content/editor/editorApplicationOverlay.js

4) edit that file

5) change ….

function editPage(url, launchWindow, delay) {
  // Always strip off "view-source:" and #anchors
  url = url.replace(/^view-source:/, "").replace(/#.*/, "");@

to ….

function editPage(url, launchWindow, delay) {
  // Always strip off "view-source:" and #anchors
  url = url.replace(/^view-source:/, "").replace(/#.*/, "");
  if (url.substr(0,4) == "http") {
  if (url.indexOf("?")>0) {
    url = url + "&editMode=true";
  } else {
    url = url + "?editMode=true";
  }
}

6) Do jar -uf comm.jar content/editor/editorApplicationOverlay.js

Other Browsers

Internet Explorer has a edit capability, but it is not built in. Somewhere in options you can choose name of the application that will do the editing on its behalf. MS Word (at least Word 2003) is compatible and has DAV capability. Dreamweaver can too. With some small modifications, SeaMonkey’s Composer could be compatible with Internet Explorer. Specifically, it needs to register itself with Windows as a bona-fide HTML editor for the user to selection in the applicable options panel for Internet Explorer.

There is nothing for Safari or Firefox etc. They would need a pluggable edit handler like IE to be part of this solution.

Pragmatic Interim Solution

There is a neat solution that can work with out of the box Apache and mod_dav. Without Sitemesh, Subversion and the editor somehow signaling the server app that GET is on behalf of an edit.

The solution still leverages SeaMonkey and a relatively recent enhancement to HTML (iframes). If an ‘outer’ master page could dynamically change its apparent content in a iframe. Some accompanying Javascript tied to the navigation bar could cause appropriate changes, with a query string signaling clearly which page is required for the purposes of clean bookmark handling.

That exact solution is how the JRemoting website is laced together. See http://jremoting.codehaus.org/ and play with the navigation links on the right. Pages like http://jremoting.codehaus.org/?page=example should result.

There are some flaws. Foremost of which is there is no history, this if there are concurrent edits, only the last edit will be preserved. Also, the transition from browse to edit is only going to work correctly when the mouse pointer is over the contained page rather than any element of the master page.

If the caret is in right place, hitting Ctrl-E will cause the edit of the page presented in the iframe. Like so:

If you like it the source is pretty easy to copy as its all client side. There’s some Javascript that is actioned on page switch to load the iframe, while trying to eliminate the scroll bars for it, but it is pretty simple stuff that I’ve cut/paste from elsewhere.

Google Code?

I had thought that GoogleCode when launched at OSCON this year would do something magic with Subversion in respect of this post-wiki idea. Especially given that Google has retained the services of many of the Subversion leads. I could not chat to them in the run up to the announcement, not after as they were busy with the launch. They had written a new back end to Subversion (I thought Svn was a back-end ? ;) called BigTable.

Greg Stein, (Apache Chair, Google techie, author of original mod_dav for Apache Web Server) and the other Subversion committers there at that moment (Brian ‘Fitz’ Fitzpatrick and Karl Fogel) had previously foisted mod_dav onto Apache and DAV onto the Subversion project. The latter is a compelling alternative or supplement to the binary svn:// mode of client/server operation for Subversion. Given Greg’s gift to the Subversion community, I felt he was only a step away from the content editing nirvana outlined above. Of course this flies in the face of Google’s Writely-style directions.

Yet to be done

Apart from the general evolution of a Sitemesh/DAV/Svn driven site, with the best bits of wikis preserved, there are a number of technical challenges to a wider adoption of a DAV based wiki (diki) or editing solution. The best bits of wikis are [wiki word] or WikiWord automatic linking IMHO.

Perhaps outside of my skill set:

  1. mod_dav backed by Subversion - needs to forward/recognize mime types more automatically (we did some experimental dav-wiki stuff in 2003 in ThoughtWorks).
  2. mod_dav to have some form of configurable trigger capability such that a CGI-like script could be run for each page PUT back (plus other DAV operations)
  3. Composer needs to register itself with Windows as allowable editor for IE
  4. MS Word needs to write uncluttered HTML by default
  5. Command line launching of Composer more elegant than ‘-edit’ function
  6. Composer to support @translate: f or@ W3C to pen standard replacement for @translate: f@
  7. Servlet bundled with Sitemesh that will interop with Jakarta Slide (or mod_dav via proxy design)
  8. Servlet/daemon/trigger functionality to do wiki-word functionality behind the scenes to web pages
  9. Firefox, Safari etc, to have a Ctrl-E capability via a plugin even if they ship without an implementation

Footnote - I have some prior blog entries on the same topic - content editing nirvana . Barrow Kwan and I built the Sitemesh/Svn concept in the past using an early beta of Subversion. Around the same (2003) time two other TW staff (Joe Walnes, Mike Roberts) made a similar solution but leveraged CruiseControl and Perforce as part of the workflow.

Published

December 7th, 2006
Reads:

Tags

Categories