MyApplication.py
(for example) or a
package directory MyApplication
(for example) containing
a module file __init__.py
, and we write into that file a
definition
of the resource as follows:
class MyResource:
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.]
It is in this kind of resource class that we write the
actual application code or at least the beginnings of it. When a user
of the application sends us a request,
the respond
method will be called and the code
within it executed. The parts of the pseudo-code in
the above text which aren't valid Python
(ie. the bits in square brackets) will use the trans
object to find out what any given user of the application has sent us,
and to send information back
to the
user in response.
The simplest way to turn this into a working application is to
ignore the first two activities mentioned in the pseudo-code and just
to produce some kind of
response. Here is how we might do that (in our module file MyApplication.py
or MyApplication/__init__.py
):
class MyResource:
def respond(self, trans):
out = trans.get_response_stream()
print >>out, "Hello world."
To deploy this, we need an adapter - see "Deploying a WebStack Application" for something which will work with this example.
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.