paulb@350 | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
paulb@488 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"><head> |
paulb@488 | 3 | |
paulb@488 | 4 | <title>Treating the Path Like a Filesystem</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
paulb@488 | 5 | <link href="styles.css" rel="stylesheet" type="text/css" /></head> |
paulb@488 | 6 | |
paulb@327 | 7 | <body> |
paulb@350 | 8 | <h1>Treating the Path Like a |
paulb@350 | 9 | Filesystem</h1> |
paulb@350 | 10 | <p>...or as a reference into |
paulb@350 | 11 | deeply categorized resources. In this approach, |
paulb@327 | 12 | we take a path like this...</p> |
paulb@327 | 13 | <pre>/documents/news/2005/article.html</pre> |
paulb@350 | 14 | <p>...and we consider <code>documents</code>, |
paulb@350 | 15 | <code>news</code>, |
paulb@350 | 16 | and |
paulb@350 | 17 | <code>2005</code> |
paulb@350 | 18 | as directories, and <code>article.html</code> |
paulb@350 | 19 | as a |
paulb@327 | 20 | file-like resource. If we ask for the following path...</p> |
paulb@327 | 21 | <pre>/documents/news/2005</pre> |
paulb@350 | 22 | <p>...we may decide to provide a |
paulb@350 | 23 | listing of files within that directory, or |
paulb@350 | 24 | we may decide to refuse such a request. Indeed some kinds of |
paulb@350 | 25 | applications insist |
paulb@350 | 26 | that such a listing may only be produced with the following path |
paulb@350 | 27 | instead:</p> |
paulb@327 | 28 | <pre>/documents/news/2005/</pre> |
paulb@350 | 29 | <p>Applications of this kind are |
paulb@350 | 30 | quite common since the publishing of files |
paulb@350 | 31 | on a Web server often just involves exposing parts of a real filesystem |
paulb@350 | 32 | to |
paulb@327 | 33 | requests through the server.</p> |
paulb@350 | 34 | <h2>Resource Hierarchies in |
paulb@350 | 35 | WebStack</h2> |
paulb@350 | 36 | <p>There are a number of different |
paulb@350 | 37 | ways that paths can be interpreted and handled in WebStack |
paulb@350 | 38 | applications, including...</p> |
paulb@350 | 39 | <ul> |
paulb@350 | 40 | <li>Using predefined hierarchies |
paulb@350 | 41 | of resources.</li> |
paulb@350 | 42 | <li>By inspecting the path in a |
paulb@350 | 43 | top-level resource and then creating resources to deal with different |
paulb@350 | 44 | cases.</li> |
paulb@350 | 45 | <li>By handling all kinds of |
paulb@350 | 46 | paths in the same resource.</li> |
paulb@350 | 47 | </ul> |
paulb@350 | 48 | <h3>Predefining Resource |
paulb@350 | 49 | Hierarchies</h3> |
paulb@350 | 50 | <p>We might decide to represent |
paulb@350 | 51 | components in these kinds of paths using |
paulb@350 | 52 | different resource classes; for example:</p> |
paulb@350 | 53 | <ul> |
paulb@350 | 54 | <li>Folders or directories are |
paulb@350 | 55 | represented by a special resource class which contains other |
paulb@350 | 56 | folders and possibly some files.</li> |
paulb@350 | 57 | <li>Files or documents are |
paulb@350 | 58 | represented by special resource classes which provide access |
paulb@350 | 59 | to the content of such files.</li> |
paulb@350 | 60 | </ul> |
paulb@350 | 61 | We might then predefine a hierarchy of resources |
paulb@350 | 62 | so that when a request arrives for a resource, we can check it against |
paulb@350 | 63 | the |
paulb@350 | 64 | hierarchy and process the request according to whichever type of |
paulb@350 | 65 | resource is |
paulb@350 | 66 | being accessed. For example:<br /> |
paulb@350 | 67 | <ul> |
paulb@350 | 68 | <li><code>documents</code> |
paulb@350 | 69 | <ul> |
paulb@350 | 70 | <li><code>news</code> |
paulb@350 | 71 | <ul> |
paulb@350 | 72 | <li><code>2005</code> |
paulb@350 | 73 | <ul> |
paulb@350 | 74 | <li><code>article.html</code></li> |
paulb@350 | 75 | <li><code>another.html</code></li> |
paulb@350 | 76 | </ul> |
paulb@350 | 77 | </li> |
paulb@350 | 78 | <li><code>2004</code> |
paulb@350 | 79 | <ul> |
paulb@350 | 80 | <li><code>document.html</code></li> |
paulb@350 | 81 | </ul> |
paulb@350 | 82 | </li> |
paulb@350 | 83 | </ul> |
paulb@350 | 84 | </li> |
paulb@350 | 85 | </ul> |
paulb@350 | 86 | </li> |
paulb@350 | 87 | </ul> |
paulb@350 | 88 | <p>Consider the above hierarchy; |
paulb@350 | 89 | we would implement such a hierarchy with a |
paulb@350 | 90 | resource object mapped to <code>documents</code>, |
paulb@350 | 91 | and that resource object |
paulb@327 | 92 | would contain a mapping of years to other resources. Eventually, at the |
paulb@350 | 93 | bottom of the hierarchy, individual resources would represent articles |
paulb@350 | 94 | and be |
paulb@327 | 95 | mapped to names such as <code>article.html</code>.</p> |
paulb@327 | 96 | <div class="WebStack"> |
paulb@350 | 97 | <h3>WebStack API - Predefining |
paulb@350 | 98 | Resource Hierarchies in Adapter Code</h3> |
paulb@350 | 99 | <p>WebStack provides a resource |
paulb@350 | 100 | class for convenient mapping of path |
paulb@327 | 101 | components (ie. names) to resource objects: |
paulb@327 | 102 | <code>WebStack.Resources.ResourceMap.MapResource</code></p> |
paulb@350 | 103 | <p>This class can be used in <a href="deploying.html">adapter code</a> |
paulb@350 | 104 | to initialise an |
paulb@327 | 105 | application as follows:</p> |
paulb@350 | 106 | <pre>from WebStack.Resources.ResourceMap import MapResource<br />from MyApplication import FileResource # import some resource class<br /><br />article_resource = FileResource(...) # make a resource representing the article<br />document_resource = FileResource(...) # make a resource representing the document<br />year_2004_resource = MapResource({"document.html" : document_resource})<br />year_2005_resource = MapResource({"article.html" : article_resource})<br />news_resource = MapResource({"2005" : year_2005_resource, "2004" : year_2004_resource})<br />documents_resource = MapResource({"news" : news_resource})<br />top_resource = MapResource({"documents" : documents_resource})</pre> |
paulb@327 | 107 | </div> |
paulb@350 | 108 | <p>Of course, predefining resource |
paulb@350 | 109 | objects is not the only way to support such |
paulb@327 | 110 | hierarchies. We could inspect paths and act dynamically on the supplied |
paulb@350 | 111 | information, either choosing to create resources or choosing to handle |
paulb@488 | 112 | such paths in the same resource.</p> |
paulb@488 | 113 | </body></html> |