Subdirectories: NewFeatures.
2005-06-01
Redirection Files
Files in the page directory can create HTTP redirections, making it trivial to support plurals, moved/renamed pages, and so on. There are two ways of doing it:
REDIRECTcontent and symbolic links.If a file starts with a line that says '
REDIRECT somewhere', and does not have more than a few lines of content, DWiki considers it a redirection. The somewhere is basically interpreted as if it was appearing in a[[....]], so it can be:
- redirection to another DWiki page.
- redirection to an external web site, written as
http://....- redirection to an absolute URL on this web site, written as
<...>These files are generically called REDIRECT files.
A symbolic link is only considered a redirect if DWiki can 'resolve' it into an existing page. To resolve the symbolic link redirect, DWiki tries to interpret the symbolic link's value as if it was appearing in a
[[...]]as a DWiki relative page name.If the symbolic link doesn't resolve this way, DWiki treats the whole thing as an ordinary page; this keeps 'ordinary' uses of symlinks intact in most cases, including when the symlinks point to something outside the DWiki page directory.
Redirects to http:// links or absolute URL links are a convenient way of creating WikiWord abbreviations to external things for local use. Make an appropriate REDIRECT file, stick it in your Aliases area, and now every page in the DWiki can say GoogleSearch or something and get a link, bam.
(WikiWord redirection rewriting means that in many cases the generated link will even point to the real target instead of the REDIRECT file, as you can see here.)
A DWiki RedirectFile can now point to absolute URLs as well
as local DWiki pages. Absolute URLs are written like they would be in
[[...]]; either http:// or <...>.
DWiki now supports generating links to URLs on the wiki's web server
that are outside the DWiki itself. These are written as links in the
format <...> and have to happen inside [[...]]. For example:
See [[the root of this web server|</>]].
generates a link to the DWiki's web server's root, which is all but certain to be outside the DWiki space if you're running DWiki as a CGI-BIN.
DWiki now remembers the name and URL for links that you write with
[[...|...]] and thereafter allows you to omit one side of the |,
at which point it will fill in the remembered values. This means that
if you want to link to Google a lot in your
document, you only have to write (eg) the URL once, and can thereafter
refer to Google much more compactly.
This does collide a little bit with using [[...|]] to write totally
unstyled text: it only comes out unstyled if it's not already been
used as the name of a link.
For now I will live with that.
The RecentChanges DWikiText macro now accepts additional arguments
that are the list of directories to restrict the listing to, or with a
dash at the front, directories to exclude from the listing. If you
combine both, both criteria must match: in an included directory and
not excluded.
This lets a RecentChanges listing exclude areas that churn too much or are otherwise less interesting to list. (Perhaps, for example, a blog sub-hierarchy in a DWiki.)
If there is a common directory prefix that scanning is limited to, the scan is efficient: only that directory and lower is looked at at all.
2005-05-31
Template expansion via #{...} now removes a final newline if such a
final newline is present. (It doesn't remove more than one newline.)
The final newline is really an implementation artifact of files; it's there because lines end with newlines, not because people consider it to be part of the file's real content. Deleting it thus brings template expansion closer to inserting people's idea of the file's contents into place.
It also means that we avoid having templates introduce whitespace into undesired places. For example:
[There's more starting at %{blog::seemore}#{blog/rangemore}]
and blog/rangemore of:
or %{range::moreclip}
doesn't introduce a gap between the end of %{range::moreclip}'s output
and the ']' in what the browser displays. (See how we didn't think of
blog/rangemore as actually having a newline at the end as part of
it?)
If {{RecentChanges}} is invoked in a {{Striped:...}} context, it now names the links to the pages by the name of the page instead of the page's full path. This turns out to be much less annoying if many (or even some) of the changes are deep in a hierarchy.
Rational: you asked for a compact display so you're going to get it.
All wikitext macros and template renderer functions now have Python docstrings. This is because there is a new macro, {{DocAll}}, that spits out a list of macros or renderers and their docstrings, thereby creating a one-stop shop for a list of them all and documentation for them.
Formatting and TemplateSyntax have been changed to use this, thereby killing several birds and a fix-me with one somewhat extended stone.
In the process of writing docstrings, I fixed several irritating limitations and renamed a few renderers.
ChrisSiebenmann likes this approach best because it keeps the documentation closely attached to the function, thereby serving as a clear visual reminder that a) change the function, update the documentation that's right there in front of him and b) write a new function, write a docstring to go with it.
Directories can now be displayed as a 'blog', which treats all file descendants of the directory as if they were blog entries and attempts to be somewhat intelligent about how much to show and how to navigate things, supporting navigation by page date or Nth to Mth most recent pages.
ChrisSiebenmann doesn't believe this makes BlogDir obsolete. BlogDir is an excellent view for ChangeLog style situations, which is exactly what NewFeatures uses it for; however, it makes a bad way of displaying a true blog-style environment because of eventual information overload. BlogView is designed to deal with that by trimming what gets displayed and providing time-based and range-based navigation.