On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
> Stut wrote:
>
> > I couldn't care less what your domain name is, you're still advocating
> > a poor choice IMHO.
> >
>
> I have been trying hard not to join this thread, but ... apart from the
> principle, what's _really_ so poor about it? Having to write
> application code that needs to work with two different APIs is poor
> enough, using a session variable for keeping a status won't make it
> much worse. So what if the status is server-scope, yet kept in
> user-scope. In particular if the app already uses session storage.
It's bad because it places data in a storage area not related to the
kind of configuration being tracked. Sessions are for managing user and
user related data. This particular value is related to the server in
general. It places a large WTF factor on the code for anyone down the
road maintaining it. It may be true that nobody else will ever manage
this code, but it's unlikely. I absolutely agree with you though, the
whole design is off. The best way to do this IMHO is to use a singleton
class that only loads the appropriate library type. Then the interface
would be generic and no extension switching would occur once the library
is loaded. Functional equivalents can be used to facilitate the same
design pattern as the singleton... such as a stub library containing one
function:
File: db.stub.php
<?
function getConnection( $dbConnectionParams )
{
if( extension_loaded( 'mysqli' ) )
{
require_once( 'db.layer.mysql.php' );
}
else
if( extension_loaded( 'mysql' ) )
{
require_once( 'db.layer.mysqli.php' );
}
else
{
die( 'No appropriate database library installed' );
}
}
?>
Then only the necessary code would be loaded and all db function (or
method) requests would execute only the appropriate code without
run-time switching. This is not only fairly optimal, but simpler,
cleaner, and much more maintainable.
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
