I am new here and I don't really care if generic functions are more or less pytoninc. If this is the right, efficient, and more maintainable way to do things that's fine with me, I will do things this way. The main problem for me is I spend a lot of time trying to understand how to do things. I read a lot of code that I don't really understand, and I do things copying code snippets from what other people have done in the past without being sure of what I am really doing. I think this project is dead if you don't improve the documentation. TG can be a great entry point for people who want to learn python and work with a language with a great potential, but with no doc or out of sync documentation they will stay with asp or php and TG will be used by few guys with 15 year of experience in python.
-fred- On Apr 24, 2006, at 10:52 AM, [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..." > > 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. > > 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. 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. > > 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. > > 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 -~----------~----~----~----~------~----~------~--~---
