> Note that such user objects (or group objects) in applications are
> frequently content objects and are accessible through content space. I
> think in Zope 2 terms this entity may be called 'member'...
In Launchpad, we have a Person table in the database. Data from there
are converted into objects, and used in the application. These are
The "user" for a given request is a Person object. It is the Person
object representing the user who is identified as using the system in
that thread at that time.
Here we go... some docs from the Launchpad wiki:
> The wrong way to go about this is to store user information somewhere
> under ++etc++,
Sorry for the crudeness, but ++etc++ makes me want to barf.
Have an "etc stuff" web server running on a different port, with a
different root traversal resource. Don't make it part of the web app
that you show to users. You'll just want to turn it off later on.
> as that isn't content space in my book and I don't want
> to expose end users (that need to do user management sometimes) to
> anything in ++etc++. (it's okay to store low-level user information in
> ++etc++, as at is now, but no extensible user info with extra
> information like email addresses, etc, I think).
Zope3-dev mailing list