This is a log of new features of note in DWiki.
DWiki has a new template handling scheme: the core idea is that we now have a way of a) picking the first existing template from a list of them and b) generating candidate templates by variable substitution and 'all parent directories' expansion. This gives DWiki a simple and general framework for doing things like 'template injection', which lets us skin an entire directory hierarchy (but not the entire wiki) with things like blog sidebars.
This also gives us a single top-level template that generates all normal HTML-based pages, thereby giving us a single place to skin the entire site. The per-view templates in
views/*(now only a convention) now just generate view-specific information, leaving all of the rest up to the top-level template.The clarity and lack of stupid template piece duplication of the result is a clear indication of how it is a better scheme. (And no more silly things like splitting a <div> start and end into different files and hoping they get included in the right spots.)
TemplateSyntax and TemplatesUsed have been revised appropriately.
One obvious way of handling blogs with categories is to create appropriate directory hierarchies for each category, then hardlink a page's file into all of the appropriate 'category' directories. However, this raises a problem: DWiki's idea of a page's identity is its path.
Directories can now have Readme files, called
__readme. Readme files are injected into pages via the new rendererinject::readme(probably the first of several injectors).The current templates don't inject
__readmein normal directory views, but do inject them for blog and blogdir views (as you may see from this directory). Blog and blogdir views now drop all files starting with__, taking out__readmeand__accessand any future special magic files.
DWiki can now generate Atom feeds for recently changed pages and recently made comments, either for the entire DWiki or for some subtree of it. For comments, this can be down to an individual article.
At the moment, pages in the Atom feed are rendered without macros except for
CutShort, for efficiency reasons. All of the links are turned into absolute links (with http:// et al), since this is basically required. Nulled-out macros produce a small message to that effect in the generated content, so that people reading the Atom feed can tell that something is going on.
The primary way of getting nested lists is now to indent the nested list entries relative to the parent list (entry). This looks visually better in plain ASCII for cases when there is a decent amount of text.
Although ChrisSiebenmann thought he wasn't going to, the old style of nesting lists (multiple list start characters, eg
***) still works. It turns out the GNU Emacs will properly autoindent for these lists but not for real indented lists, plus sometimes they actually look visually better.The amount of old-style nesting is ignored in an indented context; it's treated as just a new level.
You can now use LinkAbbrevs by name (not by URL) without a
|; ie, instead of writing[[<text>|]], you can just write[[<text>]]. This only happens if<text>wouldn't result in a link to a real page or an external URL if there was no abbreviation.Thus, one can write
[[Google http://www.google.com/]]in the page once, and later write[[Google]], and have it work out.
DWiki now lets you use spaces to separate things in
[[....]]links instead of|. If you do this, the last word is taken as the link URL or page, and the rest are the link name. (|has priority over this; DWiki tries space-separation only if there is no|.)Thus
[[Google Rules The Web http://www.google.com/]]turns into Google Rules The Web.You can use either side as an abbeviation later, for example: Google Rules The Web, Google Rules The Web. (See View Source.)
LinkAbbrevs done this way don't have to use
|, as long as there is a space in the value:[[Google Rules The Web]]still turns into Google Rules The Web.This allows somewhat more aesthetic long link name things.
Note that the opening
[[and the closing]]have to be on the same line in the wikitext.