The simplest way to think of a Web application is as just some code +which +gets run every time an HTTP request arrives at a specific network +address and +which produces an HTTP response. Without WebStack, such code often +needs to +be tailored to the software which causes it to be run, but with +WebStack you +just need to do this:
+Most of the time, you need only to think about the first activity
+(writing
+against the WebStack API).
+
class MyResource:+
"This is a resource - something which defines the behaviour of an application."
def respond(self, trans):
[Examine the transaction, decide what the user wants to do.]
[Perform some kind of action with the information supplied.]
[Produce some kind of response which tells the user what happened.]
The parts of the pseudo-code in the above text which aren't valid
+Python
+(ie. the bits in square brackets) will use various WebStack API calls
+to look
+at what the user specified in the request and to send information back
+to the
+user in the response.
+
WebStack applications consist of resource classes which contain the
+application code. In the above example, the only thing we need to
+consider is what our code does, not how resource objects are created
+and invoked (that is done in the adapter code). In more complicated
+applications, there may be a need to create our own resource objects
+explicitly, but this is not particularly interesting to think about at
+this point - see "Treating the Path
+Like a Filesystem" for a discussion of multiple resource objects.
+
When writing an application, we must consider a number of factors +which +have an impact on the code (and other things) that we will need to +provide as +part of the finished product or service.
+ + + diff -r 7ddd3d0bc4d1 -r fb79a0a0bd3a docs/index.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/index.html Fri Apr 08 22:33:56 2005 +0000 @@ -0,0 +1,38 @@ + + + +This set of documents describes the process of making a Web +application +using the WebStack framework.
+First of all, let us assume that the WebStack distribution has been
+unpacked and now sits in the WebStack-0.9 directory.
Before we begin, we must make sure that the WebStack package is
+available
+to Python. The easiest way to do this is to change into the
+WebStack-0.9 directory and to run the setup.py
+script provided with the version of Python you are going to be using
+(possibly as a privileged user like root):
cd WebStack-0.9+
python setup.py install
If you don't want to install WebStack in this way, or if you can't
+do so
+because you don't have root privileges, you can just make
+sure
+that the WebStack-0.9 directory sits on the
+PYTHONPATH.
...or as a reference into deeply categorized resources. In this approach, +we take a path like this...
+/documents/news/2005/article.html+ +
...and we consider documents, news, and
+2005 as directories, and article.html as a
+file-like resource. If we ask for the following path...
/documents/news/2005+ +
...we may decide to provide a listing of files within that directory, or +we may decide to refuse such a request. Indeed some approaches will insist +that such a listing may only be produced with the following path instead:
+/documents/news/2005/+ +
Applications of this kind are quite common since the publishing of files +on a Web server often just involves exposing parts of a real filesystem to +requests through the server.
+ +We might decide to represent components in these kinds of paths using +different resource classes, so that folders or directories are represented by +one kind of resource class and files or documents are represented by other +kinds of resource classes. We might then predefine a hierarchy of resources +so that when a request arrives for a resource, we can check it against the +hierarchy and process the request according to whichever type of resource is +being accessed.
+ +Consider the above hierarchy; we would implement such a hierarchy with a
+resource object mapped to documents, and that resource object
+would contain a mapping of years to other resources. Eventually, at the
+bottom of the hierarchy, individual resources would represent articles and be
+mapped to names such as article.html.
WebStack provides a resource class for convenient mapping of path
+components (ie. names) to resource objects:
+WebStack.Resources.ResourceMap.MapResource
This class can be used in adapter or "glue" code to initialise an +application as follows:
+from WebStack.Resources.ResourceMap import MapResource
+article_resource = [some resource representing the article]
+year_2004_resource = [a MapResource with definitions]
+year_2005_resource = MapResource({"article.html" : article_resource})
+news_resource = MapResource({"2005" : year_2005_resource, "2004" : year_2004_resource})
+documents_resource = MapResource({"news" : news_resource})
+top_resource = MapResource({"documents" : documents_resource})
+Of course, predefining hierarchies is not the only way to support such +hierarchies. We could inspect paths and act dynamically on the supplied +information.
+ + diff -r 7ddd3d0bc4d1 -r fb79a0a0bd3a docs/paths-opaque.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/paths-opaque.html Fri Apr 08 22:33:56 2005 +0000 @@ -0,0 +1,28 @@ + + + +Since many Web applications have complete control over how paths are +interpreted, the form of the path doesn't necessarily have to follow +any +obvious structure as far as users of your application is concerned. +Here's an +example:
+/000251923572ax-0015+
However, many would argue that such obscure references, whilst +perfectly +acceptable to machines, would make any application counter-intuitive +and very +difficult to reference. Sometimes, application developers do not want +people +"bookmarking" resources or functions within an application, and so such +concerns don't matter to them.
+ + diff -r 7ddd3d0bc4d1 -r fb79a0a0bd3a docs/paths-services.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/paths-services.html Fri Apr 08 22:33:56 2005 +0000 @@ -0,0 +1,25 @@ + + + +...but really using it to broadly identify different resources or +services. In this approach, we take a path like this...
+/tools/viewer+
...and interpret it as being a request for a certain function of the +application. Often, this approach is used because it matches some +aspect of +how the application is actually organised. Consider this example:
+/cgi-bin/script.pl+
This kind of thing generally appears in URLs because of the way the +application concerned has been deployed - CGI programs live in a +particular +place and are accessed using a special path "prefix".
+ + diff -r 7ddd3d0bc4d1 -r fb79a0a0bd3a docs/paths.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/paths.html Fri Apr 08 22:33:56 2005 +0000 @@ -0,0 +1,120 @@ + + + + +The URL at which your application shall appear is arguably the first part +of the application's user interface that any user will see. In this context, +a user can be any of the following things:
+What the URL is supposed to do is to say where (on the Internet or on an +intranet) your application resides and which resource or service is being +accessed, and these look like this:
+http://www.boddie.org.uk/python/WebStack.html+ +
With WebStack, we also talk about a "path" as being just the part of the +URL which refers to the resource or service, ignoring the actual Internet +address, and so these look like this:
+/python/WebStack.html+ +
When writing a Web application, most of the time you just need to
+concentrate on the path because the address doesn't usually tell you anything
+you don't already know. What you need to do is to interpret the path
+specified in the request in order to work out which resource or service the
+request is destined for.
+
WebStack provides the following transaction methods for inspecting path +information:
+get_pathget_path_without_query/folder/application/resource+Let us say that the application was deployed in a Zope server instance inside +
folder and with the name application. We may then
+say that the path to the application is this:
+/folder/application+Meanwhile, the path within the application is just this: +
/resource+ +
On transaction objects, the following methods exist to inspect paths to +resources within applications.
+get_path_infoget_virtual_path_infoset_virtual_path_info
+ method.There are various differing approaches to the problem of interpreting +paths to resources within Web applications, but these can mostly be divided +into three categories:
+ +| Approach | +Examples | +
|---|---|
| Path as filesystem | +WebDAV interface to a repository | +
| Path as resource or service + identifier | +A Web shop with very simple paths, eg. /products,
+ /checkout, /orders |
+
| Path as opaque reference | +An e-mail reader where the messages already have strange and + unreadable message identifiers | +