[Zope-dev] ZUserFolder usage and development

[Tim McLaughlin]

Dave,
1.  I say sync because UserFolder keeps its objects in an attribute called
"data" (list of Users) whereas ObjectManager does not.  The 'name' attribute
is no longer necessary because I usee the id of the object and allowing it
to be specified presents potential discord.

2.  Correct, you're supposed to check for that in your constructor, but this
is a new Product and could obviously be changed.  In fact, I'm thinking of
eliminating the constructor params altogether and allowing them to be set
later.  manage_editUser does check that password and confirm match since in
fact it calls the Super.

3.  I'm gonna pitch this out.  say it all to the benefit of all.

Incidentally, great working with you on this.  Excellent feedback, and your
catchin' on quickly (hooray!  another infected by the Zope bug).

Tim

-----Original Message-----
From: David Hassalevris
To: Tim McLaughlin
Sent: 4/9/01 4:20 PM
Subject: Re: More progress - ignore last message

Tim,
(1)
I notice that in zUserBase you omit "name" from 

def __init__   Your comment says
# name parameter allows for id and name to unsync
# so it is no longer

Can you clarify this?
Note: I noticed that the standard acl-user folder throws an error if
duplicate name is added.  Wouldnt that "default" behavior protect the
linkage (or sync) between your class and its related user object?  

(2) I also notice that while I can sucessfully add a new user via z User
Folder ... it omits password and confirmation checking.  Is this me or
is this in your code?

(3) Trying to solved problems like this raises alot of interesting Zope
questions.
Do you mind if I throw some of the issues that occur to me out to the
zope list?  
Best,
David

Tim McLaughlin wrote:
> 
> cool.  I was just about to form some vague conjectures as to what your
> problem was... but good luck and lemme know if issues come up.
> 
> incidentally, don't use 'name', 'roles', 'domains', or 'authenticate'
as
> property names or methods (clash with base class).
> 
> Thanks,
> Tim
> 
> -----Original Message-----
> From: David Hassalevris [mailto:bluepaul@earthlink.net]
> Sent: Sunday, April 08, 2001 1:21 PM
> To: Tim McLaughlin
> Subject: More progress - ignore last message
> 
> Tim,
> It finally occured to me that in order to obtain User attributes not
> stored in a "property sheet" I simply had to use things like
> "getUserName()"
> Ring! methods from the base classes are available!
> 
> Ill update you as things progress.
> David
> 
> Tim McLaughlin wrote:
> >
> > David,
> >
> > Try it again if you have previously (0.8.0).  Includes more
instructions
> > (thanks to some testing of my collegues) and fixes.
> >