> Easy, but that doesn't go too far, and then you end up > with everyone rolling there own not-very-elegant > ones. It would be nice to have a more extensive > setup to subclass and take out what you don't need. > There are lots of issues regarding ACL's and resources, > hierarchical user management, password coordination > between different systems, automating/verifying user > addition, bulk adding/deleting users, etc. > > If you have something interesting, it might be good > to toss out as a next step, since the initial > documentation is pretty primitive. > This is exactly my problem. Each project has its own userManager and user class and they do not share any code. I just copy the userManager from the last site, edit the SQL as needed and add proerties to my user class. So if in one project I need a companyID, I just add a line to the effect - user.companyID = result['companyID']
The main thing that I dislike about userManager is that if I use it I have to store user settings seperately from this user object. Since you can add properties to classes at runtime its very convientient to use the user class and pull in the settings I need at the same time that I pull in the user object. Originally i was using UserManager to pull in the user, and then I manually pulled in the user settings on my login page. Once I wrote all the code, it was simpler to just add another login method and handle it all at once. The problem that I see is the logic and data layers are blended in the userManagers. I need to think about this for a while. I'll start working on this over the next week and let you know if anything works out. -Aaron _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
