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).
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
