[Zope-PTK] Stability rule-of-thumb (fwd)

[Mike Pelletier]

    I'll fill in the cool details I don't want to get forgot, and quibble
over a few points.

On Thu, 3 Feb 2000, Phillip J. Eby wrote:

> UniversalUserFolder:
> 
> 	* UUF has a UserSource object which implements addUser, getUser,
> and deleteUser as a minimum (although these methods may be null or
> raise NotImplemented.)  The UserSource is passed to each validator so
> that the validator can find users.

    I could use a way of determining the validity of these methods
without having to actually call them.  A companion set of testing methods
(hasAdd, hasDelete, I think hasGet aught to be required) would work.

> 	* UUF is an objectManager, so arbitrary DTML or other methods
> can be added to it.  This allows sensible placement of a variety of UI
> stuff (e.g. an "add user" form, "member roster", "search users", etc.)
> as well as things like SQL or LDAP connection objects.

    Additionally, UUF has the __bobo_traverse__ method which makes User
objects available.  This will allow the user editing UI to be much
simpler, as the UI and management methods can be called _on_ the user
object, instead of passing around a 'username' arg all the time and avoids
littering the UserFolder with a bunch of user editing methods.  Also, it
allows me to CATALOG users, which is an insanely cool and powerful tool.
(or will at least make the equivalent of Zope.org's /Members more
bareable...)

> 	* is responsible for having a loginForm method, which will be
> called, not raised as an error.  The method can and should use
> <dtml-raise> to determine the type of error it will raise.  (There
> should probably also be a method for telling somebody they don't have
> permission to do something, even though they *are* logged in and a
> valid user.)

    Quibble:  I wonder if 'loginForm' has become a misnomer.  It's very
likely not to be a login form at all.  'validatorsFailed'?

    Hmm, on the subject of 'things that make you log in', a common problem
with a lot of authentication schemes is revealed when you change your
password.  The 'Password changed' page will make it appear that you are
still logged in, but when you ask for the next page your password won't
match and you get the login form.  I imagine using a token-based
authentication scheme solves this problem, but is there anything that can
be done for non-token using validators?

> Validator:
> 
> 	* has manage_afterAdd and manage_beforeDelete which call
> registerValidator and unregisterValidator on the UUF.

    If Users get these hooks called too, some PTK logic gets much simpler.

> 	* has a "priority" value (distinct from the validate() return priority)
> which is used by the UUF to set the query order for all the validators

    So, once you find a Validator that says, "Heck yeah, I know this guy",
you still continue on asking the rest?  Then what do you do with your two
priority values?

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434