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:
+The simplest way to think of a +Web application is as just some code which +sits on a server and is sent messages - specifically HTTP requests - to +which it must respond by writing out messages to send back - +specifically HTTP responses. When using WebStack, we think of the +situation in terms of the following components:
+| Application + - +The application is described in this part of the documentation. | +
|---|
| Adapter + - +Adapters are explained in the deployment +documentation. | +
| Server +environment - +Server environments are covered in the deployment +documentation. | +
To get an application up and +running, this is what you have to do:
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.
-In this part of the +documentation, we will ignore the second +activity (it is covered in "Deploying a +WebStack +Application") and concentrate on the more important task of +defining an application's functionality with "A Very Simple Example".
diff -r effeae83e027 -r 7b8005a9072a docs/simple-example.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/simple-example.html Mon Apr 18 22:47:28 2005 +0000 @@ -0,0 +1,53 @@ + + + + +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.
+It is in this kind of resource class that we write 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 effeae83e027 -r 7b8005a9072a docs/styles.css --- a/docs/styles.css Mon Apr 11 21:32:23 2005 +0000 +++ b/docs/styles.css Mon Apr 18 22:47:28 2005 +0000 @@ -1,54 +1,61 @@ -BODY { -background-color: white; -font-size: 12pt; -} +/* Generated by CaScadeS, a stylesheet editor for Mozilla Composer */ -H1 { -color: navy; -font-family: sans-serif; -font-size: 20pt; -} + body { background-color: white; + font-size: 12pt; + } + + h1 { color: navy; + font-family: sans-serif; + font-size: 20pt; + } -H2 { -color: navy; -font-family: sans-serif; -font-size: 18pt; -} + h2 { color: navy; + font-family: sans-serif; + font-size: 18pt; + } -H3 { -color: navy; -font-family: sans-serif; -font-size: 16pt; -} + h3 { color: navy; + font-family: sans-serif; + font-size: 16pt; + } + + h4 { color: navy; + font-family: sans-serif; + font-size: 14pt; + } + + ul { list-style-type: disc; + } -H4 { -color: navy; -font-family: sans-serif; -font-size: 14pt; -} + pre { border: 1pt solid black; + padding: 0.5em; + background-color: silver; + color: black; + } -UL { -list-style-type: disc; -} + .WebStack { border: 1pt solid black; + background-color: rgb(224, 224, 224); + padding-left: 0.5em; + padding-right: 0.5em; + } + + th, td, caption { font-size: 12pt; + } -PRE { -background-color: silver; -color: black; -border-style: solid; -border-color: black; -border-width: 1pt; -padding: 0.5em; -} + .explanation { border-style: solid; + border-width: 2px; + padding: 0.25em; + top: -0.5em; + width: 40%; + display: block; + float: right; + position: relative; + left: 10%; + background-color: rgb(255, 255, 153); + font-weight: normal; + } -.WebStack { -background-color: #e0e0e0; -border-style: solid; -border-color: black; -border-width: 1pt; -padding-left: 0.5em; -padding-right: 0.5em; -} + .layers { width: 60%; + text-align: center; + } -TH, TD, CAPTION { -font-size: 12pt; -}