[Twisted-web] Re: some questions about twisted.web
jack at chesspark.com
Wed Apr 8 16:21:48 EDT 2009
> I generally just use the default logging but then it's mostly for my
> own use, not end users.
We do as well. This app in particular is end user focused, so I
wanted something nicer.
> As an interim to any more extensive changes, perhaps you could just
> use a local HTTPFactory subclass for your site, overriding with your
> own log method that bypasses the twisted logging to do whatever you
That's essentially what I did in the code. It's not pretty though.
> I normally have more than just the web server running in a single process,
> but all you'd probably need is to instantiate your "Site" class, connect
> it with reactor.listenTCP, and then sit in reactor.run().
Yep. Tape currently does this, and all my command line XMPP tools do
as well. There's a lot of bootstrap though, and since most people I
know starting out want to write command line type utilities, this
makes learning Twisted significantly harder. At least making a tac
file is easy. You just make some services, call setServiceParent and
you're done. All that bootstrapping happens out of your view.
> As another view on this point, for me, I find the "work segment by
> segment" approach of twisted's to be very natural, albeit different
> than an arbitrary path mapping mechanism such as apache or many web
> frameworks. I actually missed the incremental lookup mechanism when
> first working with django on a project, for example. It can feel weird
> compared to other mechanisms, but just because it doesn't match how
> Apache works need not make it a problem. There's more than one way to
> navigate an object hierarchy within a server based on the URL in a
I think it's fine to support both approaches. I think my original
complaint was actually worded that way. The issue is that there may
not be a path from root to a child. Ie, /some/path/to/proxy exists,
but /some/path doesn't. It takes some jiggering to set that up right
now, because you have to make dummy nodes along the path. Which
works, but is not as optimal for this use case.
> One way to tie into the current framework to take more control is to
> define the resource at the root of your mapper-capable tree using
> "isLeaf". That resource's "render" method will then get called for
> any URLs at that point or below, have access to the full URL (already
> split into segments), and it can do whatever lookups/mapping to
> resource objects it might like. I've used that to strip out URL
> prefixes (such as client keys unique to them) and then re-perform the
> URL lookup to locate the resource, but it could just as easily do a
> mapper based URL lookup at that point to yield the right resource
> object to then call (instantiating it if needed) to render the
When the first getChild is called how do I know it's the first
getChild call so that I do the special logic? Perhaps that's what is
More information about the Twisted-web