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
. The second version should also incorporate TWiki
would be a logical name, but is already claimed. See
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
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.
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.
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
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
and legacy requirements.
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
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.
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