The Wheat server doesn't have to map the entire object tree to the public URI space. In fact, like Apache, there is a mapping layer that allows various parts of the object tree to be mapped into different parts of the URI space.

Modules define how a request is handled. Modules combined with mapping allow the Wheat server to support different modes of use.

In the example at left:

• / maps to the objects under /web. These are rendered with mod_file, which mimics what most file based web servers do: render a file object by asking for its byte stream and mime-type, and render directory objects via 'index.html' files or generated directory listings.
• /blog maps to a collection of blog objects. These are rendered using the standard Wheat rendering process described in the last slide.
• /dev maps the whole object tree using mod_dev which renders as a web based development environment.
• /markl maps a home object via WebDAV so that this part of the tree can be mounted as a remote file system on a user's computer. The file system appears as a collection of XML files that users can edit with their preferred editing tools.

Implementation note: While the server is just talking to the object tree, and knows nothing about object media, there is a clever path through the code: When mod_file asks for a file's byte stream contents, and it turns out that that the file object is actually a host file mounted via the host file object media, then the server ends up with a stream handler reading right from the file. So static content, like images, get streamed from the disk to the network without overhead.