Thanks for a very useful and generous response. I do have a few more questions/comments... At 05:08 PM 11/23/99 +1100, Stuart 'Zen' Bishop wrote:
On Mon, 22 Nov 1999, Ross Boylan wrote:
I notice that a lot of products redefine class variables (e.g., GenericUserFolder has isPrincipiaFolderish=1 isAUserFolder=1 ) which are already in the superclass. Is this because: * it's more readable
Because it is more readable, and ensures that nothing wierd goes on with multiple inheritance. For example, in GenericUserFolder, I inherit from both Folder and BasicUserFolder. Now, since only BasicUserFolder defined isAUserFolder, then I could have left it out and things would work happily. However, if in a future revision, someone moved isAUserFolder to SimpleItem or other subclass of Folder and defined it as false, my product would break. I used to like multiple inheritance until I saw a real product using it (Zope), and now I appreciate Java more :-)
I have a smalltalk background, so single inheritance always seemed fine to me. I think strong typing makes it much more essential than otherwise (I've done quite a bit of C++ too), and of course Python is not strongly typed).
1) Let new users define themselves on a new user screen (not a Zope management console). I've been hung up on the architectural points of where such a screen should go, how it is to refer to the acl_users folder, and how to set permissions.
You need a form, accessible to the Anonymous role, that will let a user setup an account. You also need a DTML method to act as the action of this form. This DTML method would insert the releveant data into a TinyTable,SQL table, whatever. It would probably need a proxy role defined so that the method has rights to add the data (since the anonymous user shouldn't have rights). You could then use GenericUserFolder to authenticate users from this TinyTable,SQL table,whatever.
How does one setup a proxy role? I was thinking of a much different approach, namely that I would create an OrgUser (my subclass of User) on the spot, and shove it into the acl_users. I understood that python, rather than dtml, was the way to go for that. So I thought it would look like this: form dispatches to python method (and I wasn't sure how to get the form and python namespaces together) python method creates OrgUser and puts it in acl_users (rasing both a namespace and permissioning issue) using existing methods where possible. I recall reading that permissions only inhibit the ORB and dtml, but not python. Is that accurate?