Registry Pattern Access Methods
Posted: Wed Aug 09, 2006 7:50 pm
I've been using the registry pattern recently. I draw upon patterns for php's very nice article about them.
It has occurred to me that it might be nice to be able to store registries inside registries of course I realized this was entirely possible but then I considered how one my get data in and out of such a structure:
The pattern that "patterns for php" described has the methods, register, unregister, has and get. But I thought why use register after set? Afterall set is more commonly known for setting things which is indeed what is happening when we register(). What is wrong in fact with, set, unset, isset and get? Or indeed __set(), __unset, __isset(), and __get()?
Of course this is making the registry appear to be like a stdClass and now you can access data like this:
But is it still a registry? I say yes because my originial purpose for creating one is still valid. Here's an explaination of the purpose and extra features I have added to my registry:
What I am saying is all that nice stuff I can do ^ up there ^ can be achieved with __set(), __get(), isset() and __unset(). So why for heavens sake weren't these magic methods used in the pattern in that article?
Oh and also do you like the sound of what I am doing?
It has occurred to me that it might be nice to be able to store registries inside registries of course I realized this was entirely possible but then I considered how one my get data in and out of such a structure:
Code: Select all
OF::$registry->get('stdClasses')->register('blank', new stdClass());
OF::$registry->get('stdClasses')->get('blank');Of course this is making the registry appear to be like a stdClass and now you can access data like this:
Code: Select all
OF::$registry->stdClasses->blank = new stdClass();
OF::$registry->stdClasses->blank;Code: Select all
* OF_Registry can be used for two things. Its primary purpose is to faciliate
* the storage of something, usually an object, under a label for later
* retrieval. This is then improved by means of the has() method, a customizible
* type limitation allow you to limit what enters the registry, and also checks
* to prevent overrides/duplications of existing registry entries. OF_Registry's
* primary purpose can be applied by the framework's user via a static instance
* of OF_Registry in the OF class called, funnily enough, $registry.
*
* The idea is that she/he may create an entities modify and then modify them in
* some way by means of their public properties/methods and then store that
* modified version for later. This can then be retreived and cloned as required
* ensuring that those changes you made don't have to be repeated or extended,
* by means of a class, every time you require them.
*
* Don't forget, if you need to structure your registrations, that you can store
* registries within a registry. Retrieval looks slightly odd but it does the
* job:
* OF::$registry->get('fields')->set('txtFoo', new OF_TextSmall('txtFoo'));
* OF::$registry->get('fields')->get('txtFoo');
*
* The secondry purpose of the registry exploits its duplication checks. As it
* is illegial (in HTML) and poteniually problematic (for client side scripting)
* to create fields with the same id I wanted to enforce a way be which this
* could not occur. I am able to use the registry as a means of storing labels
* alone and use its duplication checks to throw an exception when a duplication
* is created.Oh and also do you like the sound of what I am doing?