use My::Subclass qw( connection args );

###

package My::Subclass;
use base 'SuperClass';

sub import {
  my $class = shift;
  SuperClass->db_connect(@_);
}

###

package SuperClass;

sub db_connect {
  my $class = shift;
  # use @_ to make the DB connection
}
[download]

I don't like doing things other than importing with the import method, but that's a side issue. The real issue is that, as you guessed, putting this info in all the subclasses is even worse. The goal is to keep this database connection info somewhere outside of these classes entirely, and to do it with some indirection so that the classes themselves don't have to know the name of my config class, just the interface.

Ok, so let me see if I understand the issue:

You have a base class that is responsible for creating a database connection.

It creates that based on configuration arguments, thus making this base class extensible -- you can use it for a variety of database instances.

You have a sub class that uses the base class.

This class needs to use the base class's database connection, but you don't want this sub class to send config data to the base class.

Is that an adequate description? You want to use the sub classes, which implicitly use the base class? Would it be too much to add

use BaseClass;
BaseClass->connect(args...);
[download]

to the code that uses the sub-classes (that is, the main application)? It sounds like you're trying to give it configuration values without ever giving them. In that case, perhaps you should just use environment variables and be done with it.

package BaseClass;

sub connect {
  ...
  $dbh = DBI->connect($ENV{PERRIN_DBI}, $ENV{PERRIN_USR}, $ENV{PERRIN_
+PWD});
  ...
}
[download]

Then you'd set those environment variables in your program (via BEGIN) or beforehand in your shell. It's basically the same as using globals, so if you're allergic to that, then this isn't for you either. ;)
_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

That means your script is free to do however much processing it needs to do before you set up the connection.

Like this:

use Music::DBI;
use Music::Artist;

yadda(); yadda(); yadda(); # where yadda does not touch the database
Music::DBI->connection('dbi:mysql:$dbname,$user,$pass);

$art=Music::Artist->create(.....) # etc
[download]

I have to set it before the subclasses get compiled, because it's inheriting from Class::DBI::mysql and using the setup_table method, which requires a database connection to run.

You could make your installation scheme try methods (ordered from most preferred) until the correct one is found, or optionally ask, then hardwire it to the installation. Not as elegant or flexible as some design pattern acting whenever the module is used or run, but robust. ExtUtils::MakeMaker can handle that nicely.

I have a Class::DBI base class and some objects that inherit from it. In the base class, I need to set up the database connection. However, I want to keep these classes independent of the actual method of finding that config data.

You're right, I meant classes there. Fixed.

The only published example of it at this point is the test file located here. I should have more examples available over the next couple of weeks.

Also, I'm only supporting creation inject at the moment, but setter injection should be along soon. A file based configuration container, along with several other additional features and more tests, should be available this weekend barring any unforeseen honey do's.

Cheers,

John