I've been staring at identity for the past few hours, and I can't find
a way to resolve some issues with it.
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.
But then come my issues with it. In a nutshell, identity seems to have
been created for a very specific type of webapp -- which would be fine
if it were a plugin, but because this is to tightly integrated into TG
and the visitor tracking/sessions, its really troublesome.
Right now, Identity requires me to have more informatation than I want
to collect from a user -- and not the smallest subset of information
needed to differentiate a use from another , which is what it should
require.
Here's what I mean:
Stabbing at Identity/sopprovider.py, we see:
class TG_User(InheritableSQLObject):
'''
Reasonably basic User definition. Probably would want additional
attributes.
'''
class sqlmeta:
table="tg_user"
userId= UnicodeCol( length=16, alternateID=True )
emailAddress= UnicodeCol( length=255, alternateID=True )
displayName= UnicodeCol( length=255 )
password= UnicodeCol( length=40 )
created= DateTimeCol( default=datetime.now )
The default SQLobject behavior translates that class into this
structure
Table "public.tg_user"
Column | Type |
Modifiers
---------------+-----------------------------+------------------------------------------------------
id | integer | not null default
nextval('tg_user_id_seq'::regclass)
child_name | text |
user_id | character varying(16) | not null
email_address | character varying(255) | not null
display_name | character varying(255) |
password | character varying(40) |
created | timestamp without time zone |
that kills me for these reasons:
a- user_id
b- display_name
In production , I'm finding this both useless and annoying.
in the wiki example on the current wiki we have
displayName : Jane Doe
userId : jdoe
Now consder these 2 points:
1 - While lets me specify display_name as be null, TG is now forcing me
to have both a unique user_id and a unique email address for this user.
what if i dont want or need a user specified userId ? or even an
email attached to this user? do I just
md5(emailAddress).substring(0,16) one or the other, and pray that i
dont get a possible but improbable collision?
2 - why are we doing joins on the user submitted user_id ? why aren't
we joining on the 'id' serial that SQLobject automagically creates for
us? the only reason for this i can think of, is that SQLalchemy looks
like it doesn't create that automagic serial. but if thats the case,
why not specify a serial ID ?
considering that most people would want additional attributes in their
user classes via a subclass, i think identity would be much better
served and more extensible with something like this:
class TG_User(InheritableSQLObject):
password= UnicodeCol( length=40 )
created= DateTimeCol( default=datetime.now )
Then either put
emailAddress= UnicodeCol( length=255, alternateID=True )
namedId = UnicodeCol( length=255, alternateID=True )
in derived classes, or make 2 default options for people to subclass
from
class TG_User__named(InheritableSQLObject):
namedId = UnicodeCol( length=255, alternateID=True )
class TG_User__named(InheritableSQLObject):
emailAddress= UnicodeCol( length=255, alternateID=True )
toss 'display_name' into an inheritable class if needed, along with any
other fields. keep the joins on the id field SQL object makes for
joining, or add a serial_id field if SQLalchemy won't create one by
default and join on that. then let someone inherit from TG_User__email
if they want an email indexed class, and TG_User__named if they want a
nameId style user (as some apps out there seem to not want any email
address ). if someone wants both? choose one and toss the other fields
in the subclass (or make an even more confusing 3rd option)
then we either create functions that would do:
visitor.identity_from_form__userEmail
visitor.identity_from_form__namedId
or
visitor.identity_from_serial(
myApplication.userserial_from_form(form) )
My point however is this: identity - right now - is too good and too
restrictive to implement in 'larger' or more 'public web' oriented
projects. it looks like it completely kicks ass in an intranet / small
setting - and i'm guessing thats where a lot of the ideas for it came
from. But it would either require me to collect more information from
a user than necessary to uniquely identify them (which means people
don't fill out the registration form and close their browser) , or
forces me to make stuff up so I can try and fit things into the model
(which means i get annoyed).
thoughts? or am i going to rewrite this myself and be the only one who
uses it?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
