paulb@327 | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
paulb@327 | 2 | <html> |
paulb@327 | 3 | <head> |
paulb@327 | 4 | <meta http-equiv="Content-Type" content="text/html"> |
paulb@327 | 5 | <title>Treating the Path Like a Filesystem</title> |
paulb@327 | 6 | <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/"> |
paulb@327 | 7 | <link href="styles.css" rel="stylesheet" type="text/css"> |
paulb@327 | 8 | </head> |
paulb@327 | 9 | |
paulb@327 | 10 | <body> |
paulb@327 | 11 | <h1>Treating the Path Like a Filesystem</h1> |
paulb@327 | 12 | |
paulb@327 | 13 | <p>...or as a reference into deeply categorized resources. In this approach, |
paulb@327 | 14 | we take a path like this...</p> |
paulb@327 | 15 | <pre>/documents/news/2005/article.html</pre> |
paulb@327 | 16 | |
paulb@327 | 17 | <p>...and we consider <code>documents</code>, <code>news</code>, and |
paulb@327 | 18 | <code>2005</code> as directories, and <code>article.html</code> as a |
paulb@327 | 19 | file-like resource. If we ask for the following path...</p> |
paulb@327 | 20 | <pre>/documents/news/2005</pre> |
paulb@327 | 21 | |
paulb@327 | 22 | <p>...we may decide to provide a listing of files within that directory, or |
paulb@327 | 23 | we may decide to refuse such a request. Indeed some approaches will insist |
paulb@327 | 24 | that such a listing may only be produced with the following path instead:</p> |
paulb@327 | 25 | <pre>/documents/news/2005/</pre> |
paulb@327 | 26 | |
paulb@327 | 27 | <p>Applications of this kind are quite common since the publishing of files |
paulb@327 | 28 | on a Web server often just involves exposing parts of a real filesystem to |
paulb@327 | 29 | requests through the server.</p> |
paulb@327 | 30 | |
paulb@327 | 31 | <h2>Resource Hierarchies in WebStack</h2> |
paulb@327 | 32 | |
paulb@327 | 33 | <p>We might decide to represent components in these kinds of paths using |
paulb@327 | 34 | different resource classes, so that folders or directories are represented by |
paulb@327 | 35 | one kind of resource class and files or documents are represented by other |
paulb@327 | 36 | kinds of resource classes. We might then predefine a hierarchy of resources |
paulb@327 | 37 | so that when a request arrives for a resource, we can check it against the |
paulb@327 | 38 | hierarchy and process the request according to whichever type of resource is |
paulb@327 | 39 | being accessed.</p> |
paulb@327 | 40 | |
paulb@327 | 41 | <p>Consider the above hierarchy; we would implement such a hierarchy with a |
paulb@327 | 42 | resource object mapped to <code>documents</code>, and that resource object |
paulb@327 | 43 | would contain a mapping of years to other resources. Eventually, at the |
paulb@327 | 44 | bottom of the hierarchy, individual resources would represent articles and be |
paulb@327 | 45 | mapped to names such as <code>article.html</code>.</p> |
paulb@327 | 46 | |
paulb@327 | 47 | <div class="WebStack"> |
paulb@327 | 48 | <h3>WebStack API - Predefining Resource Hierarchies in Adapter Code</h3> |
paulb@327 | 49 | |
paulb@327 | 50 | <p>WebStack provides a resource class for convenient mapping of path |
paulb@327 | 51 | components (ie. names) to resource objects: |
paulb@327 | 52 | <code>WebStack.Resources.ResourceMap.MapResource</code></p> |
paulb@327 | 53 | |
paulb@327 | 54 | <p>This class can be used in adapter or "glue" code to initialise an |
paulb@327 | 55 | application as follows:</p> |
paulb@327 | 56 | <pre>from WebStack.Resources.ResourceMap import MapResource |
paulb@327 | 57 | article_resource = [some resource representing the article] |
paulb@327 | 58 | year_2004_resource = [a MapResource with definitions] |
paulb@327 | 59 | year_2005_resource = MapResource({"article.html" : article_resource}) |
paulb@327 | 60 | news_resource = MapResource({"2005" : year_2005_resource, "2004" : year_2004_resource}) |
paulb@327 | 61 | documents_resource = MapResource({"news" : news_resource}) |
paulb@327 | 62 | top_resource = MapResource({"documents" : documents_resource})</pre> |
paulb@327 | 63 | </div> |
paulb@327 | 64 | |
paulb@327 | 65 | <p>Of course, predefining hierarchies is not the only way to support such |
paulb@327 | 66 | hierarchies. We could inspect paths and act dynamically on the supplied |
paulb@327 | 67 | information.</p> |
paulb@327 | 68 | </body> |
paulb@327 | 69 | </html> |