On Fri, 2003-02-28 at 03:56, Chuck Esterbrook wrote:
> 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.
But it's harder than reimplementing all of UserKit! Especially in terms
of understanding other non-trivial code.
> 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
Registration and profile editing are both usually application-specific.
I *would* like to have a login built into Webware (WebKit, actually),
and password management would be easy enough too.
> > 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"
A sample implementation isn't the same as reusable code. There'd be no
expectation that people would all use those sample classes -- the
classes would suffice for applications with simple user requirements,
and they wouldn't try to include the flexibility to be appropriate for
all people.
> > 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)
Well, I wasn't here for that discussion, so I'm not bound ;-)
> 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?
It would be a standard interface, with hooks included in *WebKit* to
handle that interface.
All we need to standardize users is make a simple interface
description. For instance, a user object should have these methods:
userID, username, setUsername (but userID can't be changed), email,
setEmail, firstName, setFirstName, lastName, setLastName,
verifyPassword, setPassword
There may also be some functions, like verifyUsernameAndPassword,
UsernameInvalid exception... probably some others that I'm forgetting.
That could be implemented by any class with any implementation. People
could provide implementations or frameworks for several backends, but
the only requirement is the interface.
Maybe we could provide a base class that has some helper methods for
these. It would be one module, but I suppose you could call it UserKit.
Then we add some stuff to WebKit -- I think it should be added directly
to Page -- to set up a good login system, as well as some hooks for
permission. I'd say we should do this by putting in more support for
exceptions, and catching HTTPAuthorizationRequired and HTTPForbidden,
and turning these into login screens or permission denied screens.
I don't think it should be part of a separate SecurePage class, because
everyone adds this functionality to their application eventually.
Ian
|