Introduction#

It's common for people to use a wiki and some discipline to replace a more complex application. They can add some plugins to make it easier.

It would be awesome to be able to program extensions of a wiki inside the wiki:

• integrated revision control
• low barrier to entry
• programming on the web

Related notions#

Existing plugin mechanisms#

Confluence plugins#

The Confluence wiki allows for a lot of different plugin types

JSPWiki plugins#

Scott's wikitools#

Scott just started some work on wiki extensions that allow to access the wiki from outside and that make use of templates Wiki Tools

Databases#

Most applications need to store data and often use a database. It's common to store large amounts of data on a wiki with a repetitive text format. This is in effect a primitive type of database that tends to mix data and its presentation. Plugins can be used to allow access to a database from a wiki page (Database and Wiki)

Use cases/Applications#

Elementary use cases#

Text to graphics#

It would be nice to be able to input some parameters and information and obtain a graphical representation. This can be achieved for certain graphical representations with Java JSPWiki plugins (e.g. ImageGen Plugins). With a template engine, SVG and some Javascript, we could probably create new similar plugins from the wiki.

Data sheets#

It would be nice to be able to create a simple database application simply by following some conventions (e.g. type JSON code or maybe wiki lists with key,value pairs) and then be able to perform some operations on it:

• render a template with values taken from a data sheet page
• search for pages with a certain key having certain values

The Weblog plugin of JSPWiki is an example of this type of application

CGI wiki pages#

CGI scripts (and other dynamic webpages) can set their output mime type and generate content on the fly. The wiki engine could have a new .jsp page that runs the regular page through the wiki engine without all the skin information and lets the page set its mime type. This would allow users to compose multiple such wiki pages simply by referencing the URL. This is very much like attachments and it might actually be seen as a special case, so the wiki tag for attachment could be reused.

Complete application#

Catalog app#

Many applications are just specialized catalog apps. The common example is a CD,DVD, book catalog. But a bug database, a collection of crash stacks (http://www.kerneloops.org) are really essentially the same thing.

A wiki is a natural fit for catalogs and can mostly be used for that without any additional development of plugins:

• use templates to assist with data input
• use regular search to find elements in catalog
• use tagging if available to get more restricted searches (ex: issues tagged as open)

A more full featured and custom developed catalog app would often feature:

• data validation
• forms instead of simple
• automatic completion to help with data input
• advanced search matching specific data fields
• reports, graphs and charts regarding the data

Requirement tracking#

Requirement tracking can be reduced to tagging software or system documentation and producing reports from those tags to check that the requirements are taken into account in the design, the code and tested. This is typically a document-centric activity and many systems are actually based on Microsoft Word or have to interface with it.

This is therefore a natural fit for a wiki:

• documentation can be done inside wiki pages
• requirement marking (definitions, references) can be done with simple text markup
• search mechanisms in a wiki can locate the text markup of requirements
• multiple pages can be merged into one and each requirement, test or other tracked item could thus have its own page to be easily referenced.

Additional features could include:

• cross referencing of requirements and other tracked items
• more freedom in the way the documents can be organized and edited

Language learning app#

Language learning app

Implementation ideas#

Template plugin#

Scott is into Velocity templates these days and plugins for JSPWiki tend to print a lot of text with some variable parts, so this looks like a good way to design plugins. If most of the interesting parts of a plugin end up in a template, this brings the question of allowing a more generic plugin that takes the template from a wiki page and builds a velocity context to run it.

A velocity context can provide:

• formatted data an objects (e.g. key/value pairs defined in a plugin invocation or in a document referenced by the invocation (raw page, rendered page, attachment)
• access to methods and objects

The wiki could expose methods for:

• search in the wiki
• information about the user if logged in (actually risky: one user could spy on users accessing a page of his).
• access to the rendering engine

The output could be:

• wiki text that is then run through the wiki's rendering engine.
• html code
• SVG or other in a page that has an appropriate mime type
• Javascript code

Wiki services#

To make it easier to develop pages with more behavior (AJAX style), we need the wiki to automatically provide services based on the pages:

• a template plugin and a mechanism to get a rendered page without the skin should provide read services easily.
• a service to create a page and fill it with data would be useful although it might be relatively easy to emulate that by POSTing to /Edit.jsp?page=<page>
• a service to attach a file containing data
• renaming and deleting pages
• the search feature of the wiki exposed as a service
• a service to accept POST of forms and perform some generic action automatically (take keys/values and put them into a wiki page or append them to one. Applying a velocity template is an option here)

The ability to run code on the wiki side based on parameters received in the request and then compute changes to be made to the wiki (e.g. update multiple pages) might be useful but really seems less natural.