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