WikiWiki's are Dead, Long Live the WikiWiki
A good discussion on how to combine WikiWiki's and WebDAV together are going on at Scott Mitchell's blog and Justin Chapweske's blog. Scott has volunteered to do integration work with the Tomcat WebdavServlet and JSPWiki at the code level, rather than the file-system level which I used as a hack to get a quick WikiWiki/WebDAV prototype going. His approach is the right way going forward. Justin also has some very interesting ideas on how to structure these Wiki pages on disk if we are to access them as folders through a WebDAV filesystem.
One issue I ran into when playing with this idea is what to do if someone uploads full HTML into a Wiki page that they are editing, such as EmployeeList, using Microsoft Front Page for example. Then, when they edit the form through a browser they will see the full page's HTML, including javascript, the HEAD tag, etc. There are visibility issues with displaying full HTML within the context of a Wiki template, for example (i.e. the Wiki system has its own chrome, like an edit button), as well as security issues with allowing the full use of HTML by pages.
One way to get around the first issue is to actually get rid of the concept of a WikiWiki entirely; instead of WikiWiki's being on the server-side we instead move the notion of editing and saving pages of any type into the browser itself. This is one of the ideas that I was playing around with in the full Paper Airplane mockups, my perpetual Sisyphean project that I hack on a bit when time comes along. So instead of having edit and save buttons on the page, we create a new editing toolbar [screenshot 1, screenshot 2] that has an edit and save button that appear if the page "supports this". This could be automagic, perhaps using a variety of mechanisms such as sensing if the Atom API is supported and an edit URI is in the page, if we are at a WikiWiki, if the page supports WebDAV, if the page supports JSPWiki's XML-RPC APIs, if it's an Atom Wiki, etc. When you press the edit button the browser "automagically" discovers the best way to edit that page and then the content portion of the browser then changes into a fullblown Internet editor [screenshot], or maybe just a simple rich text control, if the page is HTML, or possibly spawns an external editor that can be associated with that MIME type just as we associate plugins for viewing content. Then, when you are finished, you simply press Save and the page gets saved using the appropriate mechanism, again automagically, and the content portion transforms back into a normal browser. It's like in-place editing on steroids. If authentication is needed then we simply use the browser's authentication, either Basic, Digest, or Atom and popup a authentication dialog. Why not bring editing, saving, and the Wiki philosophy into the browser itself? WikiWikis are dead, long live the WikiWiki.
The second issue can be ameliorated by stripping out unsafe tags on save, such as the object tag and javascript.
One issue I ran into when playing with this idea is what to do if someone uploads full HTML into a Wiki page that they are editing, such as EmployeeList, using Microsoft Front Page for example. Then, when they edit the form through a browser they will see the full page's HTML, including javascript, the HEAD tag, etc. There are visibility issues with displaying full HTML within the context of a Wiki template, for example (i.e. the Wiki system has its own chrome, like an edit button), as well as security issues with allowing the full use of HTML by pages.
One way to get around the first issue is to actually get rid of the concept of a WikiWiki entirely; instead of WikiWiki's being on the server-side we instead move the notion of editing and saving pages of any type into the browser itself. This is one of the ideas that I was playing around with in the full Paper Airplane mockups, my perpetual Sisyphean project that I hack on a bit when time comes along. So instead of having edit and save buttons on the page, we create a new editing toolbar [screenshot 1, screenshot 2] that has an edit and save button that appear if the page "supports this". This could be automagic, perhaps using a variety of mechanisms such as sensing if the Atom API is supported and an edit URI is in the page, if we are at a WikiWiki, if the page supports WebDAV, if the page supports JSPWiki's XML-RPC APIs, if it's an Atom Wiki, etc. When you press the edit button the browser "automagically" discovers the best way to edit that page and then the content portion of the browser then changes into a fullblown Internet editor [screenshot], or maybe just a simple rich text control, if the page is HTML, or possibly spawns an external editor that can be associated with that MIME type just as we associate plugins for viewing content. Then, when you are finished, you simply press Save and the page gets saved using the appropriate mechanism, again automagically, and the content portion transforms back into a normal browser. It's like in-place editing on steroids. If authentication is needed then we simply use the browser's authentication, either Basic, Digest, or Atom and popup a authentication dialog. Why not bring editing, saving, and the Wiki philosophy into the browser itself? WikiWikis are dead, long live the WikiWiki.
The second issue can be ameliorated by stripping out unsafe tags on save, such as the object tag and javascript.
Comments