1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/paths-filesystem.html Fri Apr 08 22:33:56 2005 +0000
1.3 @@ -0,0 +1,69 @@
1.4 +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
1.5 +<html>
1.6 +<head>
1.7 + <meta http-equiv="Content-Type" content="text/html">
1.8 + <title>Treating the Path Like a Filesystem</title>
1.9 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/">
1.10 + <link href="styles.css" rel="stylesheet" type="text/css">
1.11 +</head>
1.12 +
1.13 +<body>
1.14 +<h1>Treating the Path Like a Filesystem</h1>
1.15 +
1.16 +<p>...or as a reference into deeply categorized resources. In this approach,
1.17 +we take a path like this...</p>
1.18 +<pre>/documents/news/2005/article.html</pre>
1.19 +
1.20 +<p>...and we consider <code>documents</code>, <code>news</code>, and
1.21 +<code>2005</code> as directories, and <code>article.html</code> as a
1.22 +file-like resource. If we ask for the following path...</p>
1.23 +<pre>/documents/news/2005</pre>
1.24 +
1.25 +<p>...we may decide to provide a listing of files within that directory, or
1.26 +we may decide to refuse such a request. Indeed some approaches will insist
1.27 +that such a listing may only be produced with the following path instead:</p>
1.28 +<pre>/documents/news/2005/</pre>
1.29 +
1.30 +<p>Applications of this kind are quite common since the publishing of files
1.31 +on a Web server often just involves exposing parts of a real filesystem to
1.32 +requests through the server.</p>
1.33 +
1.34 +<h2>Resource Hierarchies in WebStack</h2>
1.35 +
1.36 +<p>We might decide to represent components in these kinds of paths using
1.37 +different resource classes, so that folders or directories are represented by
1.38 +one kind of resource class and files or documents are represented by other
1.39 +kinds of resource classes. We might then predefine a hierarchy of resources
1.40 +so that when a request arrives for a resource, we can check it against the
1.41 +hierarchy and process the request according to whichever type of resource is
1.42 +being accessed.</p>
1.43 +
1.44 +<p>Consider the above hierarchy; we would implement such a hierarchy with a
1.45 +resource object mapped to <code>documents</code>, and that resource object
1.46 +would contain a mapping of years to other resources. Eventually, at the
1.47 +bottom of the hierarchy, individual resources would represent articles and be
1.48 +mapped to names such as <code>article.html</code>.</p>
1.49 +
1.50 +<div class="WebStack">
1.51 +<h3>WebStack API - Predefining Resource Hierarchies in Adapter Code</h3>
1.52 +
1.53 +<p>WebStack provides a resource class for convenient mapping of path
1.54 +components (ie. names) to resource objects:
1.55 +<code>WebStack.Resources.ResourceMap.MapResource</code></p>
1.56 +
1.57 +<p>This class can be used in adapter or "glue" code to initialise an
1.58 +application as follows:</p>
1.59 +<pre>from WebStack.Resources.ResourceMap import MapResource
1.60 +article_resource = [some resource representing the article]
1.61 +year_2004_resource = [a MapResource with definitions]
1.62 +year_2005_resource = MapResource({"article.html" : article_resource})
1.63 +news_resource = MapResource({"2005" : year_2005_resource, "2004" : year_2004_resource})
1.64 +documents_resource = MapResource({"news" : news_resource})
1.65 +top_resource = MapResource({"documents" : documents_resource})</pre>
1.66 +</div>
1.67 +
1.68 +<p>Of course, predefining hierarchies is not the only way to support such
1.69 +hierarchies. We could inspect paths and act dynamically on the supplied
1.70 +information.</p>
1.71 +</body>
1.72 +</html>