Matthew Bevan Sat, Apr 22 2006 4:21 am
> 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.) Well, thats a problem for me. I dont want duplilcate info, I don't want empty info. Since most people will want to extend TG user with more info ( its even in the class docs ), I'm just completely puzzled why TGuser has so much info in it. It *should* be the most basic fundamentals of identity ( serial / password ) and then everything above that is extended. > Why rewrite, just write tables that are -compatible- with the default ones. > ;^D It wouldn't be a full rewrite, just dumbing down the default tables and replacing the hooks. Patrick Lewis > There is no rule saying you have to inherit from TG_User. It is > pretty easy to define your own base user class and link it into the > identity framework. I would agree with your general complaint that in > an ideal world, the base TG_User would be more lightweight. But, I > don't think it is that big of a burden really to set up a class that > does exactly what you would like, especially with the upcoming schema > changes. I'm not just saying this for my sake, but also for the adoption rate. This overcomplicates creating a user. In order to not use such tight restrictions you need to override and hook into the class (which would mean you have a better understanding of the TG internals / concepts behind ACLs ). Thats backwards and completely counterintuitive. You should have the most basic elements of identity , and just subclass from there. Jeff Watkins > If the feeling is that the tables have too much information, please feel free > to either change them or submit a ticket/patch with changes. I'll be submitting a patch. I was just hoping to get some ideas from here on how it could be more basic. Someone said that there are upcoming changes - are these in SVN trunk now, or are they forthcoming. I'm wondering what i should be patching against. Steve Bergman > The only thing about the default soprivider that troubles me at all is that > emailaddress is required and must be unique (It's an alternateId). > That's great for internet apps, but not so great for intranet apps, where > userId and password may be quite sufficient and all that is desired. Yeah, that killed me too. Jorge Godoy Sat, Apr 22 2006 10:10 am > Well, since my intranet and Internet systems both have options to send alerts > by email this is required to me :-) it seems to me like thats the thought process behind a lot of whats in Identity - its very much tailored to a specific app, and not abstracted enough into a general app Jorge Godoy Sat, Apr 22 2006 9:06 am > The idea is to use the base TG_User and *extend* it. To *reduce* you'd base > your own class on it. And what I'm saying is that we should reduce TG_User as much as possible, so everyone just extends it ( which 9/10 people will already do ) Steve Bergman > It just occurred to me... If I extend TG_User, will SQLObject's inheritance > allow me to actually override the emailaddress column definition, or can I > only add fields? > Jorge Godoy I haven't tried it... But since you'll end up with 2 classes and hence 2 tables, I believe it will still require that. What you may try is inheriting from TG_User and then writing a setter to duplicate some information -- such as user_name -- into this unwanted field... There's no validation at SQLObject level so if you respect the type of the field it all should be OK. You get 2 tables : your table - useraccount , and the default tg_user. to bypass the NotNulls, you can md5_hex(emailaddress)[0:16] into a userid , or "[EMAIL PROTECTED]" % (username) into an email. personally, i hate that. i just want to make this simple because right now, its not. identity should be as lightweight as possible then be extended. the current design basically says "either use this model or learn a whole lot about our internals to hook your own classes into 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 -~----------~----~----~----~------~----~------~--~---
