Per ProcessingModel, DWiki ultimately produces output by expanding a template. This means that DWiki has to figure out what template to use for this process, and because the TemplateSyntax is fairly limited, it is much simpler for DWiki to start with a separate template for every different view of things it wants to have.
This means that while DWiki tries not to hardcode template names or the structure of the template directory, there are a certain amount of hardcoded names it knows about that need to be there for proper DWiki operation.
The short list of such templates is:
dwiki/view-*.tmpl, dwiki.tmpl: starting view templates.views/*: conventional location for templates that display a
particular ordinary view.error.tmpl, errors/*: displaying errors (always 404 responses).login-error.tmpl: displaying a login error (a regular page, not a
404).comment/comment.tmpl: used to show each comment when we're
showing all comments.comment/posting.tmpl: used to show the result of posting a
comment. By convention, comment/posted-<result>.tmpl is used
to display specific results, where <result> is one of 'good'
(the comment was posted successfully), 'bad' (something went wrong),
'badchars' (the comment has bad characters in it), or 'nocomment'
(the comment was empty and DWiki refused to post it).blog/blogdirpage.tmpl: used to show each page in BlogDir view.blog/blogentry.tmpl: used to show each page in Blog view.syndication/atomentry.tmpl: used to render an Atom feed entry for
each page.syndication/atomcomment.tmpl: used to render an Atom feed entry
for each comment.syndication/rss2entry.tmpl: used to render an RSS 2.0 feed entry for
each page.All paths are relative to the template directory.
For views that are displayed using templates, DWiki tries to find the starting template by looking in three places, in order:
dwiki/view-<view>-<pagetype>.tmpldwiki/view-<view>.tmpldwiki.tmplBy convention, everything that generates text/html pages just goes
through dwiki.tmpl so that there is one place that does top-level
'skinning' for the entire DWiki. Only views that both use templates
and generate something besides text/html sidestep this.
The standard dwiki.tmpl uses the #{<...} first-found template
inclusion mechanism (see TemplateSyntax) to pull in the real per-view
content. It looks in four places to try to find this content, in this
order:
Overrides/...$(page)/$(view-format).tmplOverrides/...$(page)/all.tmplviews/$(view-format)-$(pagetype).tmplviews/$(view-format).tmplThe first two allow page and directory hierarchy specific overrides; the latter two are the generic places. Most views don't need to distinguish between file types, but the 'normal' view must use different templates for files and directories (since a directory doesn't have wikitext to display).
The current template-based views are: normal, history, search, blog, blogdir, atom, atomcomments, sitemap, showcomments, and writecomment. The login and logout views are 'synthetic' and don't actually display anything unless an error happens. The 'source' view simply dumps the page content out straight without getting anywhere near templates.
Note that the atom and atomcomments views are special: although they
render through templates, they generate application/atom+xml content
instead of text/html. Thus they use dwiki/view-* templates
directly, bypassing dwiki.tmpl. The sitemap view is similarly
special, although it generates application/xml content.
Errors are rendered by the template error.tmpl. There are special
error renderers error::title and error::body that look for
error-specific additional templates in the subdirectory errors/.
Each type of error looks for titles as errors/<error>-title.tmpl and
main error body as errors/<error>.tmpl (with internal defaults if
they don't exist).
Current error types: badaccess, badformat, badpage, inconsistpage, nopage.
That's it. DWiki has no other hardcoded template names.