Steve Alexander wrote:
I think so too. But I whould not try to explain a PAU (pluggable
authentication utility) without to use the word principal. I think
using the words user or participant for a principal in this case is
not a good idea.

Perhaps the scope of the PUA can be extended to have a plug-in factory
for User objects, and to make the current User easily available inside
page templates and other presentation code.

People who wish to use[1] the PUA would define their own User class,
which could be as simple as taking the principal id, but would often be
more complex according to the needs of their application.

Some abstractions to deal with user objects (which for instance can have an email address to name a common case) in Zope 3 would indeed be useful. I found I had to build my own already.

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'...

The wrong way to go about this is to store user information somewhere under ++etc++, 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

Reply via email to