NewFeatures: Chronological entries

New: /oldest/ virtual directory restriction

DWiki has long been able to give people the latest N things in a virtual directory context (as latest/<N>). Now it can give them the oldest N things, using the obvious syntax: oldest/<howmany>.

Just to show off, ranges properly convert themselves into 'oldest/<N>' at the end of their run, just as they convert themselves into 'latest/<N>' at the start.

Documentation has been updated appropriately.

New: Better Last-Modified handling

Over the past while it has become increasingly obvious that it's useful for as many responses as possible to carry a Last-Modified: header. (The last straw was wanting Google's index to show modification dates for DWiki pages.)

My reason for killing Last-Modified: was so that things like logging in and logging out, which can't be reflected in the timestamp, would still have conditional GETs be served new pages. But since the conditional GET logic is in DWiki itself, I can have DWiki be smarter about it.

DWiki now separates the page timestamp from the idea of whether the page timestamp is reliable or simply vaguely useful information. The page timestamp will always be served if it exists at all, but conditional GETs only look at the page timestamp if it's reliable (which means that if authentication is on, the answer is generally 'not').

This should work much better.

New: Page Titles

Pages now have accessible 'titles', sort of. A page's title is taken to be the value of the header that starts the page, if said header is on the very first line. (So this page's nominal title is 'New: Page Titles'.) The header level doesn't matter; a <h6> is as good as a <h1>, so long as it's the first line on the page.

This info is available only after the page has been rendered, in the new global context variable :wikitext:title. Fortunately for us, Atom feed entries can have their fields in any order, so we are free to generate <title> after <content>.

Why did I do this? First, it's suitably low rent, and second I decided I wanted some vague way to generate semi-real page titles in Atom feeds instead of the current full path to the page (ever so helpful and informative as it is).

The only tricky bit was making sure that only the appropriate magic wikitext renderers set the page title, and not all the times that we spin through wikitext looking for, eg, permissions. (Especially important in Atom feeds, as Atom feeds look at everyone's permissions before they do the real rendering.)

A DWiki page (technically, any wikitext, so comments too) can now start with the line '#pragma pre' to declare that the entire rest of the page is simply preformatted text and should be barfed out as such (minus the #pragma line, which is swallowed). '#pragma plaintext' is accepted too.

This is a much more convenient and maintainable way to stick plaintext files (such as program source or something) into a DWiki than indenting the entirity of their text one space.

Note that this does not make the page come out as text/plain. The page is still text/html and fully templated, it's just that the wikitext is one big <pre> lump, instead of more sophisticated formatting.

It's unlikely that DWiki will acquire any other sorts of pragmas (eg to say 'format this as nicely HTML-ized Python code'), partly because ChrisSiebenmann is dubious about the 'nicely HTML-ized' bit of any formatters since they invariably involve aesthetic decisions that people (eg, him) can and do object to. Having an easy way of including plaintext is the 80%-90% solution, and that is the DWiki way.

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.