Jason, these are great questions. So good, in fact, I want to share
my answers with the TurboGears list.
On 1 Nov, 2005, at 7:57 pm, Jason Chu wrote:
I just have a couple of questions about your more recent changes:
- Why have a model.somodel instead of the original model module?
Well, the goal is to have multiple providers. The provider built into
TurboGears works with SQLObject and is called
SqlObjectIdentityProvider (packaged in
turbogears.identity.provider.soprovider). It allows you to use your
own SQLObject-derived classes from a module of your own, or if you
don't specify, it will use the classes present in
turbogears.identity.model.somodel.
My goal was to decouple the SQLObject-based provider from the
specific classes used to implement the model, because not everyone
(probably few people) will be interested in using the base classes. I
expect most people will want to provide their own User, Group,
Permission, and SecretToken classes once they get familiar with the
identity framework.
- Why does the soprovider have a so in front of it? How is it
different
from the base provider? (I'll admit, I haven't looked into this one
much)
The base IdentityProvider just defines the interface and some generic
functionality. It's a place to start, an incomplete base class for
concrete implementations of the IdentityProvider interface. The first
such concrete implementation is the SqlObjectIdentityProvider
(packaged in turbogears.identity.provider.soprovider). The so stands
for SQLObject.
Ultimately, I expect the providers package to include
LdapIdentityProvider (probably in
turbogears.identity.provider.ldapprovider) and OpenIdIdentityProvider
(~.provider.oiprovider?) and others. Each provider may well have its
own model (the LdapIdentityProvider may use SQLObject to store the
SecretTokens for each identity).
--
Jeff Watkins
http://newburyportion.com/
"Not everything that can be counted counts, and not everything that
counts can be counted."
-- Albert Einstein
