> Before I say anything remotely negative about it, I just want to say
> this: despite my feelings, I do believe that its wonderfully coded,
> amazingly robust, and much better than anything I would have coded
> myself. Its an amazing piece of work and gives one everything they
> could possibly need for handling ACL tasks with a userbase.
It's more robust than you think: you can completely replace the default
SOProvider with one of your own - there's some discussion going right now about
just that. I, however, took the middleground. The SOProvider allows you to
define the tables you want to use. Here are my tables:
class Account(SQLObject):
class sqlmeta:
table = "accounts"
registry = "content"
Username = UnicodeCol(length=64, alternateID=True, title="User Name")
FullName = UnicodeCol(length=255, title="Full Name")
Password = UnicodeCol(length=48, default=None, title="Password")
EMail = UnicodeCol(length=255, alternateID=True, title="E-Mail
Address")
Location = UnicodeCol(length=255, default=None, title="Physical
Location")
Language = ForeignKey('Language', default=None)
Biography = UnicodeCol(default=None, title="Short Biography")
Searchable = BoolCol(default=True, title="Include in searches?")
Portrait = BoolCol(default=False, title="User Portrait")
Roles = RelatedJoin('Role')
Groups = RelatedJoin('Group')
Created = DateTimeCol(default=datetime.now, title="Date Created")
# ... A LOT more stuff is in here.
def byUserId(id): return Account.byUsername(id)
byUserId = staticmethod(byUserId)
def _get_userId(self): return self.Username
def _get_permissions(self): return self.Roles
def _get_groups(self): return list()
def _get_password(self): return self.Password
class Role(SQLObject):
class sqlmeta:
table = "roles"
registry = "content"
Role = UnicodeCol(length=64, alternateID=True)
Description = UnicodeCol()
Users = RelatedJoin('Account')
def _get_permissionId(self): return self.Role
In essence I define my complete own data structure and provide SOProvider with
what it wants to see, which just loads the equivalent. This works well,
because I can also easily change how SOProvider works by changing byUserId and
_get_userId to use the e-mail address, for example. If you want to use numeric
IDs, return the .id.
That was my solution. Unfortunately SOProvider does not allow you to omit (set
as None) anything, so I also had to provide a duplicate Group class which is
never used. (As far as I know, a display name is not required.)
I can make Account an InheritableSQLObject, and SOProvider doesn't mind. I can
then have User, Administrator, and Provider accounts, etc. My code would
recognize these as such, while SOProvide would just ignore the differences.
(Looking up a root inheritable object returns the sub-type.)
> thoughts? or am i going to rewrite this myself and be the only one who
> uses it?
Why rewrite, just write tables that are -compatible- with the default ones. ;^D
- Matthew
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
