On Fri, 2006-03-03 at 16:19 -0500, tedd wrote: > Perhaps I'm fortunate, but I usually find a way around using Globals. > And since I've been coding in PHP, I've never been forced to use them. > Just my 2c... In our framework, I use globals as well, although I do tend to agree with Tedd regarding workarounds rather... :) Something like so: I create a global to hold the db object (in my case MDB2 or PEAR DB) and then use a loadclass function to get the dbconfig from another module. This creates a nice way to easily pick it up wherever its needed. I then use the factory method to instantiate the db abstraction layer and pass it, through my "engine class" to an "object class" where I further abstract the db functions through a central db class. All of the modules in the system that have database derived classes extend my dbTable class, thereby keeping everything centralised. In dbTable class, I evaluate if the db object exists, and if it *really* doesn't, I create it through the engine. This makes for "lazy" evaluation of the db object, so that it works kinda on demand, rather than on every request. Using this method, I can also use a global error callback method to handle _all_ database errors gracefully, using PEAR_Error. I do think that there may be a slight performance hit doing it this way, but in an app with over 180 000 lines of code (so far) I find it works just fine... --Paul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
