The information about the user does not belong in any Resource subclass: a Resource is a page that can be generated for different users, so it should only contain information that is the same for all users. Any user specific data should be fetched via the request object.
This is totally inaccurate. It's perfectly reasonable to store user-specific data in Resource objects. "a Resource is a page that can be generated for different users" is either irrelevant or not true, I can't tell which. You can dynamically and return Resources based on which user is making the request.
Now, I'm not sure my favorite abstraction for a user is a string; I'd probably pass something other than a username to a Resource. Perhaps a rich object representing the user.
Since this is a common mis-conception (one I suffered from and have now disabused myself of) it's worth discussing. If my understanding is correct: twisted.cred uses the concept of an "avatar". Avatars (I think...): * are protocol objects * represent the user In twisted.web, the Resource *is* the avatar. In twisted.mail.imap, the Mailbox is the avatar. In twisted.conch, the Shell is the avatar (and so on). I found this initially confusing, because in many web frameworks e.g. Zope, where I came from, the objects representing resources are: * long lived * the same instances serve >1 HTTP request * instantiated at process start time It's also somewhat confusing because unlike other protocols, HTTP requests are very short-lived. It's worth noting you *can* have long-lived multi-instance t.w.Resource objects. In twisted, a common design pattern seems to be (I hope; I adopted it...) * have your realm return a root Resource i.e. one for "/" * attach your User object to that resource * have your root resource dynamically create the leaf resources via locateChild or childFactory, then attach the User object * when you need user info, get at it via e.g. self.user * let the leaf/root objects get GC-ed when the HTTP request is done I believe changes have been committed to twisted.web making this design pattern even more preferred: http://twistedmatrix.com/trac/changeset/23950 Code which, by the way, I very much like the look of. Could someone clarify if this is the "right" way of doing things?