May 6, 2004
So I wrote Dauxite. When I started I had a couple of design principles in mind:
Since Dauxite is mostly intended for my own use, I'm allowed some major drawbacks:
(Currently I have no plans to release Dauxite, 'cause it's still sort of messy, I have my hands full maintaining Lafcadio, and I'm not crazy about the idea of releasing unmaintained code.)
As with previous attempts, Dauxite starts by loading a single XML file which describes every resource on the site. The actual site contains about 100 individual pages, so what's below is just a sample of the file, which is called site.xml.
You can add new pages to the site by adding elements like <rss> or <file_html> to site.xml. These elements are represented in Ruby as Nodes, which are responsible for knowing things like their file's path on the web server, and what their content parents are. (Taken together, all the content_parent attributes describe a hierarchy which is used when generating each page's breadcrumb.)
Some of the node elements contain extra elements like <rss_retriever> or <file_input>. These are represented in Ruby as ContentFilters, which are the building blocks of HTML generation in Dauxite. To render its content, a node chains its content filters end-to-end. Each content filter receives XML input from the previous content filter (except for the first, which has to start from scratch), manipulates the XML, and then passes it along.
site.xml actually hides a lot of its content filter data, because many of Node's subclasses pre-define common combinations of nodes and content filters. For example,
is the same as
site.xml is a little messy, because it isn't screamingly obvious which XML elements are Nodes and which are ContentFilters. (Content filter elements can't contain other elements, but directories can, and directories are nodes.) If this format were designed by a standards committee it might look like
but I figure, hey, we're all adults here.