| paulb@654 | 1 | <?xml version="1.0" encoding="iso-8859-1"?> |
| paulb@515 | 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| paulb@654 | 3 | <html xmlns="http://www.w3.org/1999/xhtml"><head> |
| paulb@654 | 4 | <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type" /> |
| paulb@654 | 5 | <title>ResourceMap - Simple Mappings from Names to Resources</title> |
| paulb@515 | 6 | <link href="styles.css" rel="stylesheet" type="text/css" /></head> |
| paulb@515 | 7 | <body> |
| paulb@515 | 8 | <h1>ResourceMap - Simple Mappings from Names to Resources</h1> |
| paulb@654 | 9 | <p>The <code>ResourceMap</code> module provides classes (although |
| paulb@515 | 10 | currently only one class is supplied) which act as standard WebStack |
| paulb@515 | 11 | resources, but which examine the path or URL from incoming requests and |
| paulb@515 | 12 | direct such requests to other resources based on the contents of the |
| paulb@515 | 13 | path or URL. In other words, such classes map names or patterns to |
| paulb@654 | 14 | WebStack resources and dispatch requests accordingly.</p><h2>Introducing MapResource</h2><p>The <a href="paths-filesystem.html">"Treating the Path Like a Filesystem"</a> document contains an example involving the <code>MapResource</code> class; this class is initialised with a dictionary mapping names to resources as described below.</p><div class="WebStack"> |
| paulb@654 | 15 | <h3>WebStack API - The MapResource Class</h3> |
| paulb@515 | 16 | |
| paulb@654 | 17 | <p>The <code>MapResource</code> |
| paulb@515 | 18 | class (found in the |
| paulb@515 | 19 | <code>WebStack.Resources.ResourceMap</code> module) maps names to |
| paulb@515 | 20 | resource objects, where to select a resource the |
| paulb@654 | 21 | corresponding name must match the first component discovered |
| paulb@515 | 22 | in the <a href="path-info.html">virtual "path info"</a>. For example, |
| paulb@515 | 23 | consider the following virtual "path info" (where there may have been |
| paulb@654 | 24 | more information in the path, but this has already been processed):</p><pre>/documents/news/2005/article.html</pre><p>Here, the name <code>documents</code> |
| paulb@515 | 25 | would match the above virtual "path info". Meanwhile, after processing |
| paulb@515 | 26 | more of the information, we might have the following remains of the |
| paulb@654 | 27 | path:</p><pre>/2005/article.html</pre><p>Here, the name <code>2005</code> would match, leaving the following information unprocessed:</p><pre>/article.html</pre><p>Here, the name <code>article.html</code> would match. However, let us consider the following original virtual "path info" instead:</p><pre>/documents/news/2005/</pre><p>After processing the leading components, we may instead end up with this:</p><pre>/</pre><p>Here, only an empty string as the name will specifically match the above.</p><h4>Further Reading</h4><p>The <a href="../apidocs/public/WebStack.Resources.ResourceMap.MapResource-class.html">API documentation</a> for the <code>MapResource</code> |
| paulb@515 | 28 | class provides more detail on the subject of name matching, including |
| paulb@515 | 29 | the special "catch all" name and a discussion of the pass-through |
| paulb@654 | 30 | parameter.</p></div></body></html> |
