From: Chuck E. <Chu...@ya...> - 2003-02-28 09:56:56
|
On Friday 28 February 2003 12:48 am, Ian Bicking wrote: > 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. ...which would go in a subclass that inherits UserKit.User. It's okay to inherit a generic class and add app specifics. It's easy, too. > 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. Those starter pages can be a bore to trudge through when starting fresh projects. If UserKit provided out of the box: - login panel - registration - including optional required confirmation, or optional cancellation - password change - lost password (forgotten or reset) - profile editing then that gets the developer up and running that much quicker. UserKit could be a slice of "postnuke" without turning into a sprawling monolith of gadgets. > So I've pretty much entirely unsold myself on doing a UserKit, or > fleshing UserKit, or pushing its use. Awww. :-( > 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. Ahem. UserKit could itself be a sample implementation of users right? And we could put a little example application in there. "MiniBlogger" > Some conventions for accessing the logged-in user would be good. > Lots of little details. I intended the methods in UserKit, including their names, params and docstrings to provide those conventions. That was the point of making some of those abstract classes! (which passed through this list before going into cvs, btw) I was surprised by this last part that you wrote. If you plan on providing "some useful stuff...to make users easier to implement" what form would that take, if not a Kit? If a sample application, how about pushing most of the user management up into the Kit so that developers with similar requirements can hit the ground running? I'll do this myself someday if no one gets to it first, but I want to do it in the context of a new, real application. (I always end up with better frameworks that way.) BTW UserKit *is* used in a production application at HFD.com. Just in case anyone thought it was total vapor. :) Ian, for code slingers like us, cranking out users *is* pretty easy, but a finished UserKit would be faster still and benefit the Webware community. Of course, your time is your own as always. I'm just emphatic that there *are* good reasons to have a prod-quality, complete UserKit with sample app. -- Chuck http://ChuckEsterbrook.com |