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 :-)
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. [root] +- createAccount_form (DTML Method) +- createAccount_submit (DTML Method) +- secured +- acl_users (GenericUserFolder) +- UserTable (TinyTable) +- userAuthenticate +- [ other GUF hooks] createAccount_submit would be given a proxy role of Manager, and would insert a row into UserTable with all the relevant information (username, sha.new(password).digest(), possibly roles). userAuthenticate would generate sha.new(password).digest() and compare this to the stored SHA password hash in UserTable. the other GUF hooks could calculate their return values, suck them out of UserTable or just return fixed strings depending on your environment.
2) Have User objects which are subclasses of user, for extra data and functionality. I've been trying to avoid modifying the code in AccessControl/ directly, since that's cheating (and not robust against Zope system changes).
I think if you took the class as a variable, or took a factory object as an optional argument to your stuff, it would meet 2) without much trouble.
Its on my todo list, but it won't be there until I get the basics released. Similar functionality can be done right now. For example, I have a DTML method userEmail high up in my tree which takes a username and returns that users email address. It just means I have to do userEmail(this(),REQUEST,username=AUTHENTICATED_USER.getUserName()) instead of AUTHENTICATED_USER.getEmail(). Note that your pluggable brain would have to be a subclass of GenericUserFolder.User, and not AccessControl.BasicUser. The method described in the previous paragraph could also work for users authenticated through other mechanisms besides GenericUserFolder provided by DTML code was intelligent enough. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen