Rendering And Template Requirements

Advisor/Customer: Eelco Visser

An essential component of any wiki is the rendering of text in a simple wiki markup language to full blown HTML files. Following the tradition of the original c2 wiki, this rendering phase is regular-expression based. As is known from programming languages, this leads to badly designed languages when adding new features.

• line by line processing makes it awkward to write well structured markup

• rendering operations interfere with each other, e.g., a wiki word in a forced link

The TWiki clone of wiki extends the basic wiki markup scheme with a server-side template mechanism, which allows configuration of page layout. The template mechanism is 'propietary' and ad-hoc. Being server-side it cannot be maintained via the wiki itself.

GW should support

• A wiki markup language based on context-free parsing

• Extensibility to new markup languages through an XML-based intermediate format, which separates parsing from rendering

• Stylesheets for rendering of wiki markup and composition of pages

The following ingredients are necessary to achieve this.

GWML: XML Schema for the GW Intermediate Representation

Design an XML schema for structured representation of wiki markup. The first version should support all the markup in the TWiki TextFormattingRules? . The second version should also incorporate TWiki variables.

WikiML? would be a logical name, but is already claimed. See http://wiki.wikiml.org/ also for inspiration.

Parsing TWiki Markup

Parse the TWiki markup. Since we want to migrate several existing wikis (ST Wiki, program-transformation.org, stratego-language.org) to the new wiki, the twiki format should be supported. The parser should produce an XML document in DOM format to be passed on to an XSLT transformer.

Rendering: GWML representation to HTML in XSLT

When viewing a page, its GWML representation is converted to HTML by an XSLT stylesheet (or wiki formatting template). The stylesheet is obtained from the wiki.

Cascading Stylesheet: pretty layout

The amount of formatting in the XSLT stylesheet can be limited by separating logical layout and graphical layout. The latter should be achieved using cascading stylesheets. The CSS for viewing pages should also be part of the wiki. A good set of conventions for element classes and nice initial graphical layout should be designed.

Templates provide context for generated HTML

In addition to rendering the contents of a page to HTML, templates can add context information such as navigation bars, headers, footers, and menus. Define templates for viewing, editing, previewing, and saving pages. See the FlexibleSkin? templates for inspiration. For example in the ST wiki the WebContents? page is included in the navigation bar on the left.

Finding Preferences

Rather than just providing a single template, subtrees or specific pages of the wiki may adopt a different presentation style. For that purpose it should be possible to override the default templates with new templates. There should be a scheme for finding the applicable templates. Also it should be possible to reuse (inherit) as much code as necessary from exising templates.

Type-Based Rendering

A wiki hierarchy does not necessarily only consist of proper wiki files. Rather it can also contain pure HTML files, files in other document formats such as PDF or Postscript, files in data formats such as XML, Bibtex, plain text, CSS. Each of these file types should be 'viewed' and 'edited' using the appropriate wiki operations. This requires a rendering function for each type and thus the rendering engine should be extensible with new rendering functions. There should be a standard interface for such rendering functions.

(Note that 'rendering' a pdf file may simply mean providing a link to the file, or to copy it to the browser untouched.)

See also relation with Form rendering in Forms project

Context Variables

Wiki pages may use a series of variables to refer to their context. That way the page may be easier to port (move to another location), to include dynamic information (current time, user logged in), or search results. Also it allows the creation of generic files for inclusion in other files. See TWikiVariables for inspiration and legacy requirements.

Access Control

Integrate with access control; don't show a page if no access to it is granted. What happens if a component of a page is not accessible (e.g., reviews for a paper are not accessible to its authors until notification)

Dependencies

When creation of page views becomes involved, the efficiency of presenting pages may suffer. Therefore, it may become necessary to maintain a cache of page renderings. In order to maker sure that pages in the cache are invalidated when a page used for its creation changes it is necessary to infer the its dependencies, i.e., all files accessed for rendering a page and all authentication needed to obtain them. This should be achievable by asking user and storage management for a trace.

Integration with Forms

A wiki page is a form with textarea field, which can also have other fields such as parents and access control. There may be different access controls for different fields.

Risks

The prim risk seems to be to find a good parsing technology is key to (1) obtaining a working parser for twiki markup and (2) for its maintainability.