On Wed, Jul 23, 2008 at 9:13 AM, Phil Mayers
<p.mayers@imperial.ac.uk> wrote:
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?
_______________________________________________
Twisted-web mailing list
Twisted-web@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web