[LiveUser] Avoiding multiple objects with the same handle?

From: Date: Tue, 23 Mar 2004 16:57:54 +0000
Subject: [LiveUser] Avoiding multiple objects with the same handle?
Groups: php.pear.general 
Request: Send a blank email to pear-general+get-11456@lists.php.net to get a copy of this message
Hello, Couple of questions/suggestions. I'm creating a php file whose purpose is to setup/reset my administrative user (to initially create it, and should I ever forget my password, would allow me to reset my password). My script is setup following the model presented in the LiveUser tutorial at projects.21st-hq.de. It instantiates two objects: one instance of LiveUser_Admin_Auth_Container_DB, and one of LiveUser_Admin_Perm_Container_DB_Medium. The basic problem I had, is that my script needs to be able to check for the existance of the user that I want to create, or reset the password if it already exists. Similarly, I need to check for the existence of the application, the existence of the area, and the existence of the group, that I am initializing with the script. I found a method that is part of the LU_Perm/Auth_Common classes, called usersExists(), that lets me check for the user in the Auth and Perm tables respectively. It seems like functionality to check for the existence of objects in the database that you want to manage with the Admin classes would be part of the Admin classes, either directly, or through inheritance from the Auth/Perm_Common classes. But it doesn't. This leaves me in the situation, it seems, that I have to instantiate both objects for both the Admin classes, as well as the non-admin perm/auth classes? Not a problem, I guess. But, as I was looking at the API Documentation, have you guys ever considered just having the Admin_Perm/Auth_Common classes inherit from the regular Common classes? I admit that I don't necessarily fully understand the relationship between the Admin classes, and the 'regular' classes. As far as I can grok, it appears the admin classes are just supposed to provide additional functionality like creating users and groups, adding users to groups, creating rights, etc, that would only be used for administrative purposes. And the non-admin classes are 'read-only' - that is, they let you query the container class for information about what objects are already in it. However, like I said above, it would seem that, quite often, when you are writing scripts/pages that do administrative functions, you need to find out about the current state of the containers before you make any administrative changes. So it would seem to make sense to me that the Admin classes should inherit from the non-admin classes. The other main problem I am having - I found userExists(), but I can't seem to locate any groupExists(), applicationExists(), or areaExists(). Do you guys plan to implement this functionality? Or is there another way to accomplish what I want (namely, to avoid creating additional objects in the container that have the same name as existing objects)? Jeff Schmidt

« previous php.pear.general (#11456) next »