Stephan Schmidt discussed some different strategies for creating wiki render engines, which translate wiki markup into HTML for display. Even with WYSIWYG editors, wiki render engines will still be needed to propagate wiki content. They can be engineered to be more intelligent and versatile.
There are three kinds of render engines: Custom parser (loops out of the main loop that allow for other actions with the substitution), a Regex Engine (pattern matching with regular expressions), and a Generated Parser (creates parsers based on grammar constructs). The last one is preferred by software developers, but isn’t easy to make pattern changes in runtime. Custom parsers get the job done, but are error-prone and have difficulty with large text.
Radeox, a regex engine, started as java based component in SnipSnap wiki. It evolved into a component due to user requests, and ultimately was re-licensed from GPL to ASL. It is currently used in several Java based wikis.
Stephen explored the future of the render engine. Standardized markup is difficult to predict, control or enforce. An engine written specifically for one kind of markup likely won’t work on another kind of wiki. Javascript — which has regained some prominence as a programming tool, even on the server side — can be used for a render engine platform to put the processing on the client side. That means it will potentially work with all wikis and, with AJAX, make fewer server requests. Render engines can also become context aware by placing wiki content in an Abstract Syntax Tree (AST). Most wikis don’t know where the page belongs or what the structure of the page looks like. By breaking the content into known sections and sections into paragraphs, templates and controls can be given to each bit of microcontent. The engine can then use this information to perform higher level manipulations, such as refactoring.
For more information, see WikiSym abstract or download the paper.
