[Twisted-Python] session

[Thomas Weholt]

> That's documented in Request's API ;-)

Yes, after some digging around I found out that the API-docs explained alot.
I'll try there first in the future.

> > - is this the preferred way of doing things? Can I base my work on this
>
> No -- you want to use .rpys (.rpys can be used for XML-RPC resources
> too, of course). William made some nice changes to that example, but
> changing it to instantiate its own server.Site was a bad one.

Ok. I liked that way, but I'm porting a project from a solution based on
BaseHTTPServer and a very customized RequestHandler to Twisted and like to
do it the Twisted-way as much as possible. But I need to have some
middle-man between the server and the .rpy that will produce the content. So
far I've decided what method to use to produce content by path:

/test/index.html would be something like :

server.webapps['test'].index(request, response, server)

in my earlier code. ( Actually the method called was found using getattr and
some ugly code, so if there's a better way I'm read to learn. ) I cannot get
the grip on how to use childs and leafs in Twisted. I think my code should
be written to use that somehow. The reason I need this is because I need to
have a perstistent object, containing compiled templates ( using
simpleTAL/ES ), users-information and a dict of what I've called webapps,
similar to the rpys I guess, in memory. I think that can work with some of
the sample code I've seen. But I want to pass more parameters to the
rpy-file that will produce the content, not just call it's render method.

In short; how can I turn Williams example into a rpy and still have the
ability to decide what render-method to call based on the requested path and
pass more parameters to the rendering method? Is that possible?

I don't want to write an rpy for each file that will produce on page. In my
previous solution I've seperated businesslogic, data and content-generation
in such a way that the content-producer method took only a few lines each.
It made it possible to have them in one class, instead of a bunch of small
files. It could look something like this ;

class MyPage:

     def index(self, request, response, server):
        # produces content for index.html

    def about(self, request, response, server):
        # produces content for about.html

    ... etc ...

It made it easier to maintain, easier to reuse code between
content-generator methods and overall easier to understand. I think. Since
design was in templates all I did was build a dict of values, find the right
template and call the proper method in simpleTAL/ES to produce the content
with the dict and name of template as parameters. It was very easy and done
in just a few lines of code.

> Twisted applications, unless you know what you're doing :-)

So far I'm without a clue, but hopefully I'm getting there ;-) Thanks. Sorry
if I'm writing a bunch of crap here, but I'm very excited about getting the
hang of Twisted.

Best regards,
Thomas