[TurboGears] Re: Is Identity too much? I think so.

Mon, 24 Apr 2006 12:48:09 -0700



On 4/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Ok, so I've read through this whole thread, and I see alot of people
talking about what's "easier for newer users". Since that describes me
very well, I thought I'd chime in on the subject. My experience in
getting pretty basic Identity stuff going went something like this:

-*uncoment magic stuff and import Identity stuff*, "Oh cool, that
works"
-"But I also need X,Y, and Z user info... Crap, how do I do that?"
*flounder around online, then dig though code, only half understanding*
-"Ok, that seems to work, but why do I have two tables now? Did I do it
right? Is this going to break horribly? Now, how do I manipulate user
information directly? Oh well, whatever, I'll fight with that later
once I have everything else working..."

yes you got it right you *need* two tables, as of now

All of my "steps of understanding" leave me with unanswered questions,
and I have been avoiding the identity portions of my application
because of it. (I can't do that much longer though, the rest of my app
is coming together nicely!) Presumably documentation would fix this.

Yes it isn't that hard It's harder to find where it  is then undestand it. And most of the code in the TG_* classes is like that so it wont collide with user defined classes, hence the TG_ names

As a newer user, I'm in favor of moving the "default" tg_users stuff to
model.py. It makes sense to have it there in the default cases since it
will all be SQLObject information. This also makes it more visible, and
clear that it is something that can be modified. It also forces the new
user to see a little bit of how it works, thereby eliminating several
of the questions I had before I had a chance to even think of them.
This is how I, as a new user, expected it to work, and when that wasn't
neccesary,I assumed there was some deep magic at work and that it
would be hard to understand. I don't mind having to add this to my
model as it makes it very clear what the capabilities are.

Your totally right about that I'm new to identity myself, and it was really amazing for me to dig up into that code ( i still don't undestand parts of it)

I am not
only new to TG, but also to OO Python practices, so having to extend
the class was not an obvious answer for me. I'm still not _sure_ I did
it right.

The "tg-admin quickstart identity" is also a good idea, but is there a
compelling reason to not have that just be normal behavior of
quickstart? I mean, most people who are writing webapps will need
identity of some level, won't they? Those that don't can leave the
pieces for identity commented or remove them. Actually, the more I
think about it, I can't imagine anything other than a tech demo that
wouldn't need Identity.

The issue here is not about if you need it or not, it is clear that you DO need it, that is why the default templates say uncomment this to get identity working. The issue here is what identity model to use, more on this below.

All that being said, if it breaks the ability to use other
authentication sources like LDAP (I have no idea if it would, but
several people in this thread mentioned that Identity is the way it is
so that it works with other uthentication sources), it shouldn't be
done. Barriers to entry be damned. I have an LDAP directory at my
organization that I store user information in, and I would like to
eventually be able to leverage that without huge re-writes.

The thing with having Identity as the other Jorge pointed out is that we have a saprovider.py a soprovider.py and there are supposed to be many more, where the first in line is LDAP. by the way sa and so stand for SQLAlchemy and SQLObject.

So the need for a tg-admin quickstart identity which difers on which provider to use is necesary,

Anyway, those are my grossly under-informed opinions on the subject.
Hopefully the "views of the noob" are somehow useful. :D

-Regards-
-Quentin Hartman-



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to