I’m building a class or two based on StdRegProv to handle Windows Registry via PHP’s COM class. For reference to all known StdRegProv methods and types, see: http://msdn.microsoft.com/en-us/library/aa393664%28v=VS.85%29.aspx. (Don’t even get me started on the fact that I have to know what Reg type a named value is just to get or set its value. I’ve already found workarounds for this problem, but it takes Enuming through the entire parent key.)
I’m assigning each key or named value to a PHP object with its own unique properties and methods meant to handle common registry functions – list named values in a key, list sub keys, add/update keys and named values, etc. A problem I foresee is if while my script is running, another process or an action of my code could change registry paths of keys or all named values or delete them all completely, thereby screwing up any existing objects based on them – a problem similar to what one might encounter when working with actual file system objects. Except with the Registry, there is no locking.
For example, if I delete a registry named value that was previously listed in a Key Contents object I created earlier, that Key Contents object might lie and still tell me that named value existed. Or, if if I changed the value of something which another process already deleted or moved, it would create or overwrite something in the registry, thus potentially screwing up my OS.
The question is, knowing that keys and named values can change without notice, what OO design pattern is best for working with the Registry (or filesystem objects for that matter)?
Edit: I think I’m going to change it up a bit. Instead of having stray named values as separate objects everywhere, I’m going to instead make them as properties of their parent key object. Each named value will have an internal reference to it’s parent key object to get it’s current path (crossing fingers this won’t cause memory leaks or infinite recursion problems). Here’s the basic idea…
$key->value($name_or_index)->name; // get or set name
$key->value($name_or_index)->type; // get or set type
$key->value($name_or_index)->value; // get or set value
$key->value($name_or_index)->delete(); // delete this value, then destroys itself
$key->add_value($new_name, $reg_type, $value);
$key->parent; // get or set parent key path
$key->name; // get or set name
$key->delete(); // deletes key, unsets all child objects, nulls itself out
Reg::add_key($path); // abstract factory API returning new key as object
Reg::get_key($path); // abstract factory API returning existing key as object
Reg master class also holds the single static COM interface accessed by all other objects, and is what all other classes are derived from. I guess it can also hold all methods for interacting directly with the Registry, and all logging/fail-safe methods. In that sense, it would be a abstract factory API, and let me keep the other derived classes pretty small.
As MainMa suggested below, any access of a key or value will get values straight from the Registry to avoid any unwanted “cache” behavior. And, I’ll have a fail-safe .reg file set on WIN startup to role back any incomplete transactions written by my script. If my script completes successfully, it will delete this .reg file and startup entry on end. Otherwise, if the power goes out mid-run, I should be safe.
I guess this is the best design…?
Why not loading data “on demand”? Access a list of children nodes or a single node when you need to. Avoiding preloaded data or data loaded too soon will reduce the number of obsolete entries.
Since the obsolete entries may still exist (ie. if you loaded the list of children nodes 1 ms. ago, there is no guarantee that every child is still there), recheck the validity of data at each modification. For example, if you are:
you may not check for valid data at the second state, but you MUST check if the node exists at the third state, before replacing a value. If the check fails, then throw an exception.
There is no such a thing as transactions for Registry. But you may try to make something similar, much more basic, depending on the context. If you are saving some keys to registry and must be sure that those keys are not modified meanwhile, save the existing values, start saving, and when finished, recheck the values. If they are wrong, revert to previous state (thus keeping the values modified by another program during transaction).
You may also want to search for other strategies, again depending on the context. For example, if you are moving a bunch of registry keys from one place to another and you know that those keys may be modified or deleted meanwhile or new ones may be created, move them, checking one by one, then recheck if there are still keys to move (ie. the new ones), move the new ones, recheck, etc.