This isn't a fully-fleshed-out idea, so bear with me on this: Right now, the only way I can see to customize how identity actually validates a user is to write a whole new provider. This usually entails copy-and-pasting most of <so|sa>provider.py and changing just one or two methods, depending on needs.
It also means that the choice of ORM is tightly coupled both to the model objects and to the identity provider, which feels a bit odd. Plus, the User class becomes a "dumb object" that only provides data, and the logic sits in a different class (the provider). That's usually a code smell. Wouldn't it be easier and more object-oriented to make the User and Visit classes have the responsibility for validation (via configurable methods like 'User.validate()'), and just have identity contain only ORM-independent identity logic? The specific use case I'm running into is implementing login-by-email-address, so what I'd really like to have is a User class that provides a 'lookup()' method that abstracts away SQLObject/SQLAlchemy differences as well as user_name/email_address differences, and a 'validate()' method that abstracts away the password check. Thoughts? If this sounds reasonable, I think I'm going to try coding up a genericized identity provider to see if there are any hidden corners I'm missing. -- Tim Lesher <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
