Chris's Wiki :: dwiki/NewFeatureshttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/?atomDWiki2024-02-26T21:44:35ZRecently changed pages in Chris's Wiki :: dwiki/NewFeatures.tag:cspace@cks.mef.org,2009-03-24:/dwiki/NewFeatures/RSS2Feedscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> can now generate RSS 2.0 format syndication feeds for recently
changed pages. This is a terrible hack that should not exist but
<a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a> has to deal with a few things that don't accept Atom
format feeds, only RSS 2.0 feeds.
RSS 2.0 page feeds are just like Atom page feeds and all Atom page feed
restrictions and configuration options apply to them too. They are not
advertised anywhere (either in page tools or in feed automdiscovery);
to get access to them you must specify the feed URL directly, using the
view name '<code>rss2</code>' (as in http://you.cim/dwiki/?rss2).</p>
<p>See <code>dwiki/view-rss2.tmpl</code> and <code>syndication/rss2entry.tmpl</code> for what
RSS 2.0 elements are used and how.</p>
<p>There is no RSS 2.0 feed for page comments.</p>
<p>(Because this is a hack, asking for the RSS 2.0 feed of <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/VirtualDirs">VirtualDirs</a>
that are restricted such that they get redirections to the base
directory, per <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeedsAndVirtualDirs">AtomFeedsAndVirtualDirs</a>, will get you a redirection
to the <em>Atom</em> feed for that base directory. This is considered
acceptable since people aren't supposed to be using those feeds
anyways.)</p>
</div>
/dwiki/NewFeatures/RSS2Feeds2024-02-26T21:43:53Z2013-08-27T14:32:53Ztag:cspace@cks.mef.org,2009-03-24:/dwiki/NewFeatures/AtomFeedsAndVirtualDirscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> can now restrict what sorts of <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/VirtualDirs">VirtualDirs</a> advertise
<a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeeds">AtomFeeds</a> (both in <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/SyndicationDiscovery">SyndicationDiscovery</a> and in the Atom toolbar)
and/or provide them if they're requested by URL.</p>
<p>It turns out that when you have a fair amount of content in a <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a>
your <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/VirtualDirs">VirtualDirs</a> and thus your <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeeds">AtomFeeds</a> proliferate like over-active
rabbits. Then <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/SyndicationDiscovery">SyndicationDiscovery</a> kicks in so that anyone who looks at
a virtual directory can discover its Atom feed and either start polling
it or just crawl it. Once your <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> gets big enough this becomes not
really a good thing, as Chris has found out with his techblog.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeedsAndVirtualDirs">Read more »</a></p>
</div>
/dwiki/NewFeatures/AtomFeedsAndVirtualDirs2024-02-26T21:43:53Z2013-02-01T22:46:19Ztag:cspace@cks.mef.org,2009-03-24:/dwiki/NewFeatures/DisallowDirViewscks<div class="wikitext"><p>Directories can now say that they don't want to be rendered in specific
view types. The usage case Chris has in mind is his techblog, where the
blogdir view of categories is utterly huge because it renders hundreds
of entries. Because this is intended to be a graceful gentle fix,
trying to view a directory in a disallowed view generates a (permanent)
redirection to the default view of the directory. To avoid redirection
loops, this redirection only happens if the view has been specified
explicitly as a URL parameter.</p>
<p>(For obvious reasons, disallowed views are also disallowed in virtual
directories derived from a particular real directory.)</p>
<p>This is done similarly to <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefaultDirViews">DefaultDirViews</a>: touch a file in the directory
called <code>.flag.noview:<strong><viewname></strong></code>. Unlike default views, this is not
currently inherited by child directories.</p>
<p>The 'See As' page tools links also exclude disallowed view types. Right
now they do so a little bit too thoroughly, in that they exclude the
default view if it's also disallowed. Moral: don't do that, even though
the code saves you from a redirection loop in this case.</p>
<p>Right now there is no restrictions on what (directory) views can be
disallowed, so you can disallow Atom feeds. This is probably not a
feature and will probably not be staying, although Chris may change
his mind about this or just be lazy.</p>
</div>
/dwiki/NewFeatures/DisallowDirViews2024-02-26T21:43:53Z2011-12-09T18:43:38Ztag:cspace@cks.mef.org,2009-03-24:/dwiki/NewFeatures/VariousConfigBitscks<div class="wikitext"><p>Not covered before now are various new configuration options that have
been quietly added to <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> over the five or so years that I have been
using it as mostly a blogging engine. As you might expect, a bunch of
these have to do with dealing with obnoxious clients of various sorts.</p>
<p>They are by and large documented in <a href="https://utcc.utoronto.ca/~cks/space/dwiki/ConfigurationFile">ConfigurationFile</a>. I am not
going to try to remember them here.</p>
</div>
New: various new configuration options2024-02-26T21:43:53Z2011-06-01T14:09:45Ztag:cspace@cks.mef.org,2009-03-24:/dwiki/NewFeatures/ProcessingNotescks<div class="wikitext"><p>These are directives that change how <a href="https://utcc.utoronto.ca/~cks/space/help/DWikiText">DWikiText</a> is interpreted to do
things like turn off certain font characters or map a simple-to-type
character sequence like '->' to a HTML entity. They are documented
in <a href="https://utcc.utoronto.ca/~cks/space/help/DWikiText">DWikiText</a> so I am not going to repeat myself here.</p>
<p>In the process I added a new and less annoying plain quoting
mechanism: ``...''. It looks better in ASCII than it probably
does in the font here.</p>
<p>(The code for this was written in August of 2007 or so, but I sat
on it because I wasn't entirely sure I liked the feature. Well, nuts
to that; time to roll things out and just go.)</p>
</div>
New: <a href="https://utcc.utoronto.ca/~cks/space/help/DWikiText">DWikiText</a> has 'processing notes' (and better quoting)2024-02-26T21:43:53Z2011-06-01T14:06:13Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/IndexViewcks<div class="wikitext"><p>I've decided that sometimes I really want a directory to have an
index page, not just a list of the contents. So now I can, with the
unimaginatively named 'index' view. It's mostly template based; the
normal template uses <code>inject::index</code> to display an <code>__index</code> file.
However, the view has several special properties:</p>
<ul><li>unlike other directory views, it is not inherited by subdirectories.</li>
<li>it is only listed as an available view in the page tools area if
there is a file called <code>__index</code> in the directory.</li>
<li>if <code>__index</code> is a redirection, the index view will just generate
a redirect to the target.</li>
</ul>
<p>(Thus, the index view could be used to replace the <code>wikiroot</code>
<a href="https://utcc.utoronto.ca/~cks/space/dwiki/ConfigurationFile">configuration directive</a>.)</p>
<p>The index view is valid on directories even without a <code>__index</code>
page in the directory. Right now the template just displays a normal
directory listing in that case.</p>
</div>
New: directories can have an index 'page'2024-02-26T21:43:53Z2006-04-08T23:56:37Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/PragmaSearchcks<div class="wikitext"><p>I got tired of the relative links in my blog drafts (written in an
entirely different directory than their eventual home) not working.
So, introducing <code>#pragma search</code>; this adds additional directories to
search for pages when resolving relative links, both WikiWords and
explicit [[...]] links. The directories listed in a search pragma must
be absolute path names, and are searched only after the hard-coded
possibilities have been exhausted (including the alias directory for
WikiWords).</p>
<p>You can't have both a <code>#pragma search ...</code> and a <code>#pragma pre</code>
in the same page, partly because it doesn't make any sense.
(This is the simple way of getting out of handling multiple
<code>#pragma</code> directives.)</p>
</div>
New: <code>#pragma search ...</code>2024-02-26T21:43:53Z2006-03-26T04:30:58Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/Cachingcks<div class="wikitext"><p>Having run out of other ways to really improve performance, I added
a disk-based caching infrastructure to <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> and then put in two
caches.</p>
<p>The real cache is the renderer cache, which stores the results of
selected renderers (currently just the <code>wikitext</code> renderers). Via some
glue it's also used to store the results of the filesystem walk that's
the expensive bit of <code>blog::prevnext</code>.</p>
<p>The Brute Force Cache is for dealing with Slashdotting style situations;
it just caches complete requests for N seconds when the system seems to
be under load. I also hijacked it as a convenient place to add extra
caching for Atom feeds and to force this caching on software that
doesn't do conditional GET.</p>
<p>(For more details, see <a href="https://utcc.utoronto.ca/~cks/space/dwiki/Caching">Caching</a>.)</p>
<p>This required a new storage pool class. Like the comment store, it
uses a customized and restricted interface to write things (and a new
interface to read them). The cache storage pool stores <em>objects</em>, not
data blobs, using the cPickle module to make the swap back and forth.
(This may be a mistake, but it's fast and easy.)</p>
<p>Since removing files in <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> makes me nervous, I didn't bother to
implement any sort of cache cleaning; you get to do that by hand. The
cache has TTLs, and the renderer cache has validation layered on top
of the cache object store, but when they detect something invalid they
just ignore it. (On the other hand, the cache storage layer does use
temporary files and <code>rename()</code>, so in a sense it's already removing
files.)</p>
<p>In theory the cache interface is generic, so later I can hook up
a <a href="http://www.danga.com/memcached/">memcached</a> setup or something
without having to change higher-level code.</p>
</div>
New: optional disk-based caching2024-02-26T21:43:53Z2006-03-22T07:52:40Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/MacroTextFormattingcks<div class="wikitext"><p>I (<a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a>) found myself with a genuine need for text set in
HTML <strike>. Rather than try to invent a formatting setup for this
that did not make me cringe, I just punted to the easy solution: macros
that do text formatting.</p>
<p>So, <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now has grown the new macros:</p>
<ul><li><code>ST</code> for the font styles <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> didn't already have.</li>
<li><code>C</code> for character entities, and <code>ShowCharEnts</code> to show the named
entities we support.</li>
<li>because I was there anyways, <code>AB</code> for <abbr>, so I could have those
cute inline abbreviation expansion things. Tragically <abbr> is not
supported by IE 6 and less, so <code>AB</code> may quietly change to generating
<acronym> someday.</li>
<li>and finally, <code>IMG</code> to generate <img>. Width, height, and alt text is
mandatory, and there is a hacky way to also roll title text in too.
(Title text is optional.)</li>
</ul>
<p>Through special black magic, <code>ST</code>, <code>C</code>, and <code>AB</code> can be used in comments
(the omission of <code>IMG</code> is deliberate). In theory this lets a commenter
cause character set explosions, but in practice a bad commenter can just
write UTF-8 directly (UTF-8 is the common and only sane character set
choice, so).</p>
<p>Implementing these as macros means that they have some limitations. You
can't nest <code>C</code>, <code>AB</code>, or a differently styled <code>ST</code> inside an <code>ST</code>, and
currently none of them can be done inside link text (<code>[[....]]</code>).</p>
<p>These macros are a bit of a hack. It's relatively easy to implement
bits of HTML this way, but I'm not sure if it's good design overall.</p>
</div>
New: Text formatting via macros2024-02-26T21:43:53Z2006-02-27T08:48:06Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/PrevNextLinkscks<div class="wikitext"><p>The more I have used <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> for a blog, the more I've realized that I
want individual entries to be able to have Previous (entry) and Next
(entry) links. At first I resisted because this would require an
expensive filesystem walk on even individual page views, but I have
now given in and made the <code>blog::prevnext</code> renderer, which will do
this if I want.</p>
<p><code>blog::prevnext</code> generates links directly to the pages, not to
<code>/range/N-N/</code> virtual directories, because I think that works better.
(It would be less code the other way, but better links are worth the
code.)</p>
</div>
New: Previous and Next links in pages in blog views2024-02-26T21:43:53Z2006-02-05T07:23:02Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/GoogleSitemapscks<div class="wikitext"><p>I added the ability for <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> to generate Google Sitemap format XML
files, using the view 'sitemap'. The information included is very basic
currently: just the URL for each file page, all of them set to priority
0.8 (in the hopes that Google will decide that all of the directories
are priority 0.5 and prefer returning file page results).</p>
<p>Google does not say what Content-Type you should return sitemaps
in, so I have opted for 'application/xml'.</p>
<p>In the future, something as elaborate as Atom rendering may be
done. For now, everything is hardcoded in the <code>sitemap::minurlset</code>
renderer.</p>
<p>Updated: now directories are shown too, at priority 0.6. This feature
is clearly going to be in flux for a while.</p>
</div>
New: <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> can generate Google Sitemaps2024-02-26T21:43:53Z2005-12-18T08:37:25Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/HttpsUrlscks<div class="wikitext"><p>As part of fixing Atom feeds to not break embedded https:// urls, I
decided that we should support plaintext https:// URLs, like say
<a href="https://bugzilla.redhat.com/">https://bugzilla.redhat.com/</a>.</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> should now support non-HTTP URLs much better in general (before,
there were a number of problems and issued). You can even include
mailto: links if you really want to.</p>
</div>
New: https:// now supported in plain text2024-02-26T21:43:53Z2005-09-24T04:00:43Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/SyndicationDiscoverycks<div class="wikitext"><p>There's a standard for autodiscovery of Atom feeds, involving
<code><link rel="alternate" type="application/atom+xml" href="..."></code>
element in your <code><head></code>. Now <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> has a <code>atom::autodisc</code> renderer to
create them.</p>
<p>The current code only generates 'recently changed pages' Atom feed
links, and so disappears entirely when there isn't one. In theory one
can have multiple autodiscoverable feeds (the first is the default,
and they get <code>title="..."</code> elements), but I don't quite feel like
being that daring just yet.</p>
<p>(I am also not confidant that clients have the UI issues involved
sorted out. I'm not sure <em>I</em> have the issues sorted out; for example,
should file pages have only the comment feed in the autodiscovery, or
should they also have the recent changes for their directory feed in?
Which better matches practical user expectations? Can I expect users
to be aware of the difference between directory pages and file pages?)</p>
</div>
New: Atom feed autodiscovery2024-02-26T21:43:54Z2005-09-15T05:11:41Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/LinkToCommentscks<div class="wikitext"><p>This is a little new renderer that creates a link to a page in the
view necessary to show comments. In turn, this has caused the 'your
comment has been posted' template page to be tarted up so that it
uses it, thereby letting people who have posted comments see them in
the page they go to.</p>
<p>(I have decided not to have it link to the comment section of the
page, just on general principle. I may change my mind about this.)</p>
</div>
New: linktocomments renderer2024-02-26T21:43:53Z2005-09-14T19:39:37Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/FeedMaxSizecks<div class="wikitext"><p>This is all because LiveJournal has undocumented size limits on
incoming syndication feeds, limits that <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> can easily blow past.
Since I actually wanted LiveJournal to be able to get syndication
feeds from me, <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> has grown two new configuration settings.</p>
<p><code>feed-max-size</code> is an integer kilobytes. It is a rough limit on how
large any feed can be; once <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> generates a feed that is this many
kilobytes or larger it stopps adding more entries, regardless of the
setting for <code>atomfeed-display-howmany</code>. If unset, there is no size
limit.</p>
<p><code>feed-max-size-ips</code> restricts <code>feed-max-size</code> to the whitespace
separated list of IP addresses or tcpwrappers style IP address
prefixes (eg '<code>66.150.15.</code>' to get all of <code>66.150.15.*</code>).
Syndication fetches from other addresses will behave as if there was
no <code>feed-max-size</code>.</p>
<p>Strictly speaking, <code>feed-max-size</code> limits only the size of the
<code>atom::pages</code> or <code>atom::comments</code> output to that size. Whatever else
is tacked on to make up a feed (hopefully not very big) will add some
extra size.</p>
<p>Moral: undersize <code>feed-max-size</code> a bit. For LiveJournal, the limit is
apparently 150 kilobytes (currently), so setting it to '120' or so
should provide a comfortable safety margin.</p>
<p>Although I'm not entirely fond of this (to put it one way), the
documentation has been updated appropriately, making this feature more
or less official.</p>
</div>
New: <code>feed-max-size</code> and <code>feed-max-size-ips</code>2024-02-26T21:43:53Z2005-09-12T04:39:49Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/OldestVirtDirscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> has long been able to give people the latest N things in a
virtual directory context (as <code>latest/<N></code>). Now it can give them the
oldest N things, using the obvious syntax: <code>oldest/<howmany></code>.</p>
<p>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.</p>
<p>Documentation has been updated appropriately.</p>
</div>
New: <code>/oldest/</code> virtual directory restriction2024-02-26T21:43:53Z2005-09-03T05:19:40Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BetterLastModHandlingcks<div class="wikitext"><p>Over the past while it has become increasingly obvious that it's
useful for as many responses as possible to carry a <code>Last-Modified:</code>
header. (The last straw was wanting Google's index to show
modification dates for <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> pages.)</p>
<p>My reason for killing <code>Last-Modified:</code> was so that things like logging
in and logging out, which can't be reflected in the timestamp, would
still have conditional <code>GET</code>s be served new pages. But since the
conditional <code>GET</code> logic is in <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> itself, I can have <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> be
smarter about it.</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> 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 <code>GET</code>s only look at the page timestamp if it's reliable
(which means that if authentication is on, the answer is generally
'not').</p>
<p>This should work much better.</p>
</div>
New: Better Last-Modified handling2024-02-26T21:43:53Z2005-09-03T04:40:54Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/PageTitlescks<div class="wikitext"><p>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 <code><h6></code> is as good as a
<code><h1></code>, so long as it's the first line on the page.</p>
<p>This info is available only after the page has been rendered, in the
new global context variable <code>:wikitext:title</code>. Fortunately for us,
Atom feed entries can have their fields in any order, so we are free
to generate <code><title></code> after <code><content></code>.</p>
<p>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).</p>
<p>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.)</p>
</div>
New: Page Titles2024-02-26T21:43:53Z2005-06-14T20:31:16Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/PragmaPrecks<div class="wikitext"><p>A <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> page (technically, any wikitext, so comments too) can now
start with the line '<code>#pragma pre</code>' 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). '<code>#pragma plaintext</code>' is
accepted too.</p>
<p>This is a much more convenient and maintainable way to stick plaintext
files (such as program source or something) into a <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> than
indenting the entirity of their text one space.</p>
<p>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.</p>
<p>It's unlikely that <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> will acquire any other sorts of pragmas (eg
to say 'format this as nicely HTML-ized Python code'), partly because
<a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a> 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 <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> way.</p>
</div>
/dwiki/NewFeatures/PragmaPre2024-02-26T21:43:54Z2005-06-11T06:10:03Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/NewTemplateSchemecks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> 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 <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> 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.</p>
<p>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 <code>views/*</code> (now only a
convention) now just generate view-specific information, leaving all
of the rest up to the top-level template.</p>
<p>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.)</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/TemplateSyntax">TemplateSyntax</a> and <a href="https://utcc.utoronto.ca/~cks/space/dwiki/TemplatesUsed">TemplatesUsed</a> have been revised
appropriately.</p>
</div>
/dwiki/NewFeatures/NewTemplateScheme2024-02-26T21:43:54Z2005-06-10T22:38:19Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/HardlinkedPagescks<div class="wikitext"><p>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: <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a>'s idea of a page's identity
is its path.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/HardlinkedPages">Read more »</a></p>
</div>
/dwiki/NewFeatures/HardlinkedPages2024-02-26T21:43:54Z2005-06-09T05:38:35Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ReadmeFilescks<div class="wikitext"><p>Directories can now have Readme files, called <code>__readme</code>. Readme
files are injected into pages via the new renderer <code>inject::readme</code>
(probably the first of several injectors).</p>
<p>The current templates don't inject <code>__readme</code> in 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 <code>__</code>, taking out <code>__readme</code> and <code>__access</code> and any
future special magic files.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ReadmeFiles">Read more »</a></p>
</div>
/dwiki/NewFeatures/ReadmeFiles2024-02-26T21:43:54Z2005-06-06T22:04:22Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeedscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> can now generate Atom feeds for recently changed pages and
recently made comments, either for the entire <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> or for some
subtree of it. For comments, this can be down to an individual
article.</p>
<p>At the moment, pages in the Atom feed are rendered without macros
except for <code>CutShort</code>, 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.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeeds">Read more »</a></p>
</div>
<div> (<a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AtomFeeds?showcomments#comments">2 comments</a>.) </div>/dwiki/NewFeatures/AtomFeeds2024-02-26T21:43:53Z2005-06-05T04:58:15Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/NestedListsWithIndentcks<div class="wikitext"><p>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.</p>
<p>Although <a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a> thought he wasn't going to, the old style of
nesting lists (multiple list start characters, eg <code>***</code>) still
works. It turns out the GNU Emacs will properly autoindent for these
lists but not for <em>real</em> indented lists, plus sometimes they actually
look visually better.</p>
<p>The amount of old-style nesting is ignored in an indented context;
it's treated as just a new level.</p>
</div>
/dwiki/NewFeatures/NestedListsWithIndent2024-02-26T21:43:54Z2005-06-03T22:37:16Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ImprovedLinkAbbrevscks<div class="wikitext"><p>You can now use <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/LinkAbbrevs">LinkAbbrevs</a> <em>by name</em> (not by URL) without a <code>|</code>; ie,
instead of writing <code>[[<text>|]]</code>, you can just write <code>[[<text>]]</code>.
This only happens if <code><text></code> wouldn't result in a link to a real page
or an external URL if there was no abbreviation.</p>
<p>Thus, one can write <code>[[Google http://www.google.com/]]</code> in the
page once, and later write <code>[[Google]]</code>, and have it work out.</p>
</div>
/dwiki/NewFeatures/ImprovedLinkAbbrevs2024-02-26T21:43:54Z2005-06-02T19:12:48Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/SpaceLinkSepscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now lets you use spaces to separate things in <code>[[....]]</code> links
instead of <code>|</code>. If you do this, the last word is taken as the link
URL or page, and the rest are the link name. (<code>|</code> has priority over
this; <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> tries space-separation only if there is no <code>|</code>.)</p>
<p>Thus <code>[[Google Rules The Web http://www.google.com/]]</code> turns into
<a href="http://www.google.com/">Google Rules The Web</a>.</p>
<p>You can use either side as an abbeviation later, for example:
<a href="http://www.google.com/">Google Rules The Web</a>, <a href="http://www.google.com/">Google Rules The Web</a>. (See View
Source.)</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/LinkAbbrevs">LinkAbbrevs</a> done this way don't have to use <code>|</code>, as long as there is a
space in the value: <code>[[Google Rules The Web]]</code> still turns into
<a href="http://www.google.com/">Google Rules The Web</a>.</p>
<p>This allows somewhat more aesthetic long link name things.</p>
<p>Note that the opening <code>[[</code> and the closing <code>]]</code> have to be on the
same line in the wikitext.</p>
</div>
/dwiki/NewFeatures/SpaceLinkSeps2024-02-26T21:43:54Z2005-06-02T19:06:26Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/URLRedirectscks<div class="wikitext"><p>A <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> <a href="https://utcc.utoronto.ca/~cks/space/dwiki/RedirectFile">RedirectFile</a> can now point to absolute URLs as well
as local <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> pages. Absolute URLs are written like they would be in
<code>[[...]]</code>; either http:// or <code><...></code>.</p>
</div>
/dwiki/NewFeatures/URLRedirects2024-02-26T21:43:54Z2005-06-01T18:46:25Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/AbsoluteLinkscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now supports generating links to URLs on the wiki's web server
that are outside the <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> itself. These are written as links in the
format <code><...></code> and have to happen inside <code>[[...]]</code>. For example:</p>
<blockquote><pre>
See [[the root of this web server|</>]].
</pre>
</blockquote>
<p>generates a link to the <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a>'s web server's root, which is all but
certain to be outside the <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> space if you're running <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> as a
CGI-BIN.</p>
</div>
/dwiki/NewFeatures/AbsoluteLinks2024-02-26T21:43:53Z2005-06-01T18:17:28Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/LinkAbbrevscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now remembers the name and URL for links that you write with
<code>[[...|...]]</code> and thereafter allows you to omit one side of the <code>|</code>,
at which point it will fill in the remembered values. This means that
if you want to link to <a href="http://www.google.com">Google</a> a lot in your
document, you only have to write (eg) the URL once, and can thereafter
refer to <a href="http://www.google.com">Google</a> much more compactly.</p>
<p>This does collide a little bit with using <code>[[...|]]</code> to write totally
unstyled text: it only comes out unstyled if it's not already been
used as the name of a link.</p>
<p>For now I will live with that.</p>
</div>
/dwiki/NewFeatures/LinkAbbrevs2024-02-26T21:43:54Z2005-06-01T18:05:38Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/FilteredRecentChangescks<div class="wikitext"><p>The <code>RecentChanges</code> <a href="https://utcc.utoronto.ca/~cks/space/help/DWikiText">DWikiText</a> 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.</p>
<p>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 <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a>.)</p>
<p>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.</p>
</div>
/dwiki/NewFeatures/FilteredRecentChanges2024-02-26T21:43:54Z2005-06-01T05:47:16Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/TemplateNewlinescks<div class="wikitext"><p>Template expansion via <code>#{...}</code> now removes a final newline if such a
final newline is present. (It doesn't remove more than one newline.)</p>
<p>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 <em>real</em> content. Deleting it thus brings
template expansion closer to inserting people's idea of the file's
contents into place.</p>
<p>It also means that we avoid having templates introduce whitespace into
undesired places. For example:</p>
<blockquote><pre>
[There's more starting at %{blog::seemore}#{blog/rangemore}]
</pre>
</blockquote>
<p>and <code>blog/rangemore</code> of:</p>
<blockquote><pre>
or %{range::moreclip}
</pre>
</blockquote>
<p>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
<code>blog/rangemore</code> as <em>actually</em> having a newline at the end as part of
it?)</p>
</div>
/dwiki/NewFeatures/TemplateNewlines2024-02-26T21:43:54Z2005-06-01T02:30:27Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ShortRecentChangescks<div class="wikitext"><p>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.</p>
<p>Rational: you asked for a compact display so you're going to get it.</p>
</div>
/dwiki/NewFeatures/ShortRecentChanges2024-02-26T21:43:54Z2005-06-01T02:04:27Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DocStringDocscks<div class="wikitext"><p>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.</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/Formatting">Formatting</a> and <a href="https://utcc.utoronto.ca/~cks/space/dwiki/TemplateSyntax">TemplateSyntax</a> have been changed to use
this, thereby killing several birds and a fix-me with one somewhat
extended stone.</p>
<p>In the process of writing docstrings, I fixed several irritating
limitations and renamed a few renderers.</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a> 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.</p>
</div>
/dwiki/NewFeatures/DocStringDocs2024-02-26T21:43:54Z2005-05-31T20:25:45Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogViewcks<div class="wikitext"><p>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.</p>
<p><a href="https://utcc.utoronto.ca/~cks/space/People/ChrisSiebenmann">ChrisSiebenmann</a> doesn't believe this makes <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogDir">BlogDir</a> obsolete. <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogDir">BlogDir</a> is
an excellent view for ChangeLog style situations, which is exactly
what <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/">NewFeatures</a> uses it for; however, it makes a bad way of displaying a
true blog-style environment because of eventual information
overload. <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogView">BlogView</a> is designed to deal with that by trimming what gets
displayed and providing time-based and range-based navigation.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogView">Read more »</a></p>
</div>
/dwiki/NewFeatures/BlogView2024-02-26T21:43:53Z2005-05-31T08:15:00Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefaultDVsInheritcks<div class="wikitext"><p>Default directory views, mentioned before in <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefaultDirViews">DefaultDirViews</a>, are now
inherited from parent directories if the child specifies no particular
desire about the whole thing.</p>
<p>This is convenient for setting an entire hierarchy to a <a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogView">BlogView</a>
(qv).</p>
</div>
/dwiki/NewFeatures/DefaultDVsInherit2024-02-26T21:43:53Z2005-05-31T07:25:31Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/StarSeparatorscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> has a new formatting feature. If you write just '* * *' on a
line by themselves, they center and become a separator. Like, well,
this:</p>
<p align="center">* * *</p>
<p>You can't indent them, because I decided that would run too much risk
of confusing things with pre-formatted text blocks.</p>
<p>Why? I just decided I liked that style of chunk separator. (Maybe if I
could get a <hr> variant that didn't stretch the entire width...)</p>
<p>Note: feature subject to me changing my mind.</p>
</div>
/dwiki/NewFeatures/StarSeparators2024-02-26T21:43:54Z2005-05-30T23:33:54Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/SymlinksRedirectcks<div class="wikitext"><p>Symbolic links inside the <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> page area now cause redirections if
their value would be a valid redirection in a REDIRECT line.</p>
<p>For example: <a href="https://utcc.utoronto.ca/~cks/space/People/">FrobTig</a>, which is a symlink in /Aliases with the value
'<code>../People</code>'.</p>
<p>We could have tried using os.path.realpath() on the symlink and taking
the result relative to the store root, but I think that that has more
subtle explosive breakages.</p>
<p>Symbolic links that don't resolve to a real <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> page this way are
interpreted normally, so you can still have symlinks that point to
files outside the <a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> pagestore root.</p>
</div>
/dwiki/NewFeatures/SymlinksRedirect2024-02-26T21:43:54Z2005-05-30T20:26:58Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/VirtualDirscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now supports 'virtual directories': directories that don't
really exist but instead serve to limit what's shown for a real
directory. For example, you can limit what's shown for a real
directory to only the most recent 5 things, or to only things written
on 2005/05/29.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/VirtualDirs">Read more »</a></p>
</div>
/dwiki/NewFeatures/VirtualDirs2024-02-26T21:43:54Z2005-05-30T05:12:43Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BetterTablescks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a>'s tables can now have rows that span multiple lines, using
indentation to continue them on subsequent lines just like with
lists. The appearance is straightforward; just write:</p>
<blockquote><pre>
| start your table | another cell that
is continued on another line | the end cell |
| cell one | cell two | cell three |
</pre>
</blockquote>
<p>A row is closed by having a '<code> |</code>' at the end of a line, or just by
starting a new row.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BetterTables">Read more »</a></p>
</div>
/dwiki/NewFeatures/BetterTables2024-02-26T21:43:53Z2005-05-29T18:24:32Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefinitionListscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now supports definition lists (<dl>, <dt>, <dd> in HTML). I
started with what I think was Wikipedia's syntax but decided it was
ugly in plain text so came up with my own that I like better.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefinitionLists">Read more »</a></p>
</div>
/dwiki/NewFeatures/DefinitionLists2024-02-26T21:43:53Z2005-05-29T10:29:30Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/HierarchicalSecuritycks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now has a simple hierarchical way of handling access to pages
for various things (both access <em>and</em> commentability), so you can give
(or take away) permissions for things to entire directory trees at a
shot. We use a simple implementation where directories can have a
magic file called <code>__access</code>, which creates default permissions for
everything under them.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/HierarchicalSecurity">Read more »</a></p>
</div>
/dwiki/NewFeatures/HierarchicalSecurity2024-02-26T21:43:54Z2005-05-28T19:42:33Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/Searchcks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now has an extremely low-rent generic from-the-web search
functionality. It's so low-rent I'm not sure I'm going to keep it, but
we'll have to see.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/Search">Read more »</a></p>
</div>
/dwiki/NewFeatures/Search2024-02-26T21:43:54Z2005-05-28T09:21:15Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/Commentscks<div class="wikitext"><p><a href="https://utcc.utoronto.ca/~cks/space/dwiki/DWiki">DWiki</a> now supports comments on pages; comments are themselves written
in <a href="https://utcc.utoronto.ca/~cks/space/help/DWikiText">DWikiText</a>. Currently pages have to be specifically enabled for
this; in the future I will have a better global or semi-global
mechanism for this.</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/Comments">Read more »</a></p>
</div>
/dwiki/NewFeatures/Comments2024-02-26T21:43:53Z2005-05-27T23:38:55Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ViewSourceFixcks<div class="wikitext"><p>As part of the fallout of other work, I fixed the nit where 'View
Source' would show as a page tool on pages where viewing the source
would get you a permission or unavailability error.</p>
</div>
/dwiki/NewFeatures/ViewSourceFix2024-02-26T21:43:54Z2005-05-27T19:19:03Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ShortTeaserscks<div class="wikitext"><p>With blog-style things now decently supported, there is the problem
that some pages want to be longer than is comfortable for display in a
blog setting. Now wikitext can signal that only the front should be
shown in some contexts, like so:</p>
<p class="teaser"><a href="https://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/ShortTeasers">Read more »</a></p>
</div>
/dwiki/NewFeatures/ShortTeasers2024-02-26T21:43:54Z2005-05-27T05:03:10Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/DefaultDirViewscks<div class="wikitext"><p>Directories can now have default view types associated with them, by
the simple yet sleazy method of touching a file in them called
<code>.flag.prefview:<strong><viewname></strong></code>.</p>
<p>This lets us auto-set a directory to default to a blogdir view.</p>
<p>The page tools now autogenerate a list of 'See As <whatever>' links
for alternate directory formats.</p>
<p>This required some innards magic to distinguish a normal view being
explicitly specified from no view being specified and us just
defaulting to a normal view.</p>
</div>
/dwiki/NewFeatures/DefaultDirViews2024-02-26T21:43:53Z2005-05-27T04:33:43Zhttps://utcc.utoronto.ca/~cks/space/dwiki/NewFeatures/BlogDircks<div class="wikitext"><p>Directories can now be displayed as a 'blogdir', which treats the files
in the directory as if they were blog entries: they are sorted by
modification time, most recent first, and then they are all displayed
inline with a title.</p>
<p>A chunk of this behavior is controlled by templates and new renderers.
'blogdir' is a new view, only valid for directories, which uses
<code>blogdir.tmpl</code>. The <code>blog::blogdir</code> renderer does the direct
expansion, running each file through the template <code>blog/blogentry.tmpl</code>.</p>
<p>There are also new renderers for the new blog-like time format and for
showing the owner of a file. (Currently the Unix and/or RCS owner.)</p>
<p>This is ... how shall we say it ... not hugely scalable over the long
run in terms of time structure and number of entries.</p>
</div>
/dwiki/NewFeatures/BlogDir2024-02-26T21:43:53Z2005-05-27T03:51:14Z