2. whois michaelpeacock.co.uk Experienced senior / lead web developer Web Systems Developer for SmithElectric Vehicles US Corp Author of 6 web development books Owner / CTO of CentralAppsLimitedJust launched first beta product: invoicecentral.co.uk Zend Certified Engineer
3. Commonly used objects and settings... Within Bespoke frameworks and large applications most of the code often needs access to core objects, settings and variables.
4. ...such as Database Access / Abstraction layers Template engines Object for the currently logged in user Objects which perform common tasks, such as email sending or data processing Site settings: path to uploads folder, cache folder, site URL, etc
5. The solution: Registry Create a registry to store these core objects and settings Provide methods to store and retrieve these objects and settings Pass this object around your application (e.g. To your models and controllers) –or- make it a singleton (yuk)
6. Registry: basics <?php class Registry { private $objects = array(); private $settings = array(); public function __construct(){} public function storeObject( $object, $key ){} public function getObject( $key ){} public function storeSetting( $setting, $key ){} public function getSetting( $key ){} } ?>
8. Registry: usage Make your code aware Public function __construct( Registry $registry) { $this->registry = $registry; } Store an object $this->registry->storeObject( $template, ‘template’ ); Access your objects $this->registry->getObject(‘template’)->output();
9. Registry: The good Keeps core objects and settings in one place Makes it easy to access and use these objects and the data or functionality they hold within Common interface for storing, retrieving and managing common objects and settings
10. Registry: The bad All aspects of your application need to be registry aware... ...though its easy to simply pass the registry via the constructor to other parts of your code Works best with a front controller / single entry point to your application, otherwise you need to duplicate your registry setup throughout your code
11. Registry: The ugly Bloat! If you rely on the registry too much, you end up with objects or settings which you only use some of the time This takes up additional resources, time and memory to setup and process the objects and settings for each page load, only for them to be used 50% of the time
12. Registry: de-uglification Make the registry lazy loading Registry is aware of all of its objects Objects are only instantiated and stored when they are first required, and not before Registry knows about core settings/data that is used frequently, and knows how to access other data if/when required
14. De-uglification If the object isn’t set, load it the lazy way /** * Get an object from the registry * - facilitates lazy loading, if we haven't used the object yet and it is part of the setup, then require and instantiate it! * @param String $key * @return Object */ public function getObject( $key ) { if( in_array( $key, array_keys( $this->objects ) ) ) { return $this->objects[$key]; } elseif( in_array( $key, array_keys( $this->objectSetup ) ) ) { if( ! is_null( $this->objectSetup[ $key ]['abstract'] ) ) { require_once( FRAMEWORK_PATH . 'registry/aspects/' . $this->objectSetup[ $key ]['folder'] . '/' . $this->objectSetup[ $key ]['abstract'] .'.abstract.php' ); } require_once( FRAMEWORK_PATH . 'registry/aspects/' . $this->objectSetup[ $key ]['folder'] . '/' . $this->objectSetup[ $key ]['file'] . '.class.php' ); $o = new $this->objectSetup[ $key ]['class']( $this ); $this->storeObject( $o, $key ); return $o; } }
15. De-uglification: settings Apply the same approach to settings / data Query your core settings If the setting requested hasn’t been loaded, load all related settings (works best if you prefix your keys with a group name)
16. Conclusion Easily access your core objects, functionality and data from anywhere in your application Apply some lazy loading to keep your application running lean Enjoy!
