Subdirectories: NewFeatures.
2005-09-03
/oldest/ virtual directory restrictionDWiki 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.
Virtual Directories in DWiki
A virtual directory is a way of restricting what pages get shown out of a real directory. It works by tacking on 'virtual' directories after the real directory (ie, as subdirectories) to tell DWiki what you want to see.
Virtual directories restrict pages based on their most recent modification time. There are three versions available:
- calendar: with the format
<year>/[<month>/[<day>]], all as digits. Only pages most recently changed in the time period get selected.- latest: with the format
latest/<howmany>. They show just the most recently changed<howmany>pages.- oldest: with the format
oldest/<howmany>. They show just the least recently changed<howmany>pages.- range: with the format
range/<start>-<end>. They show the start'th to the end'th most recently changed page.All pieces of a virtual directory must really be virtual. If you have a directory
Foo/with aFoo/2005/subdirectory (or file), you cannot use the virtual directoryFoo/2005/05/to see things from May of 2005 inFoo/. Moral: let DWiki organize things based on time for you, don't do it yourself.Virtual directories are paid attention to by some renderers, which are generally used in some views. You can get the full list in TemplateSyntax.
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.