I'm planning on reimplementing an old program, and I thought "oh, I'll use users, maybe I'll play around with generalizing the user management." Just the words going through my mind, yep...
Then I thought about how I'd implement it, and I quickly realized that I'd implement it as a wrapper around a database row. I'd wrap it in SQLObject so that it would interact well with my other database objects -- if I was using MK I'd want it to be an MK object, or a ZODB object, or whatever. This is *very* important to me, I don't want some crappy user object that's so generic it doesn't work well with my other objects. Users are usually closely tied to everything else in the application. Okay, so we have different backends, like UserKit does currently. So, what does the frontend do? And I realized... almost nothing. Users have an ID, and they probably have a username, password, email, and name. Not complex stuff. My user objects *will* be complicated, but they will be complicated by all sorts of stuff that is application-specific. And what would I gain by using a user framework? I guess I'd save about 10 lines of code for the username and such... at the expense of 15 lines of code for the glue. Maybe some reusable pages could be made... but what, a login, password change, forgotten password, user profile editing... not big stuff. So I've pretty much entirely unsold myself on doing a UserKit, or fleshing UserKit, or pushing its use. That said, there's some useful stuff we can do to make users easier to implement. Particularly making logins and authentication easier. A sample implementation of users would also probably be helpful. Some conventions for accessing the logged-in user would be good. Lots of little details. Ian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
