Stevan Little <[EMAIL PROTECTED]> writes:
> Rob,
>
> My problem is that I am not sure Config::ApacheFormat can handle some
> of the more complex IOC::Service configurations.
>
> <Registry MyApp>
> <Container DBI>
> dsn dbi:mysql:test
> username test
> password ****
> connect ??? << how to do this one
If you want evaluable code there, that is easy. My CPAN module
Config::DBI uses Config::ApacheFormat for just that reason. DBI takes
a HandleError attribute which is a routine which can be called when it
wants to throw an exception.
Here is how I built the HandleError attribute in the DBI handler to
pass to DBI->connect()
if (my $handler = $block->HandleError)
{
my $hardref = eval "\\&$handler" ;
$A{HandleError} = $hardref;
}
In fact, that Container block above looks just like the one in
Config::DBI.
Config::DBI was my 2nd module focused on storing DBI connection info
and providing $dbh via a simple API. The first was DBIx::Connect
http://search.cpan.org/~tbone/DBIx-Connect-1.13/lib/DBIx/Connect.pm
it was based on AppConfig. I found AppConfig difficult to deal with
for reasons discussed here:
http://perlmonks.org/index.pl?node_id=292455
and so I developed Config::DBI based on Config::ApacheFormat
http://search.cpan.org/~tbone/Config-DBI-1.8/lib/Config/DBI.pm
More recently, I realized that it was wrong of me to expect database
connection information to be structured in a certain
way. Organizations think about their database connection info in
different ways and they have their own preferenecs for which concfig
tool to use... your Registry and Container syntax is living proof of
that. A flexible database connection module should allow you to pass
your data to it but not put restrictions on how your data was
cataloged in your personal tech stack.
I realized that underlying all config representation was
a nested Perl data structure (isn't it great how hashes, arrays and
scalars are standard in Perl so that we dont have confusion over which
array package to use). So even more recently, I coded DBIx::DBH which
takes a hashref as it's argument. The distinctive features about
DBIx::DBH are:
1/ It forms the DSN string for you. DSN strings vary from db vendor to
vendor quite a bit. A DSN is a compound data type. A basic rule of
software design is to have simple elements formed into complex
entities via an API.
2/ It uses Params::Validate for rigourous input validation
> </Container>
> </Registry>
>
> I want to avoid doing things like this (which can start to get very
> verbose):
>
> <Service connect>
> class DBI
> constructor connect
> args @dsn @username @password
> </Service>
>
> or this (which I don't actually think would work since the tag name
> would be so arbitrary):
tag names can be "strict" or not-validated based on the constructor
call to Config::ApacheFormat.
In addition, there is an evaluate vars constructor parameter which
allows for evluation of defined vars.
I guess my question is: if there are Factories for creating $dbh, then
can you use one of these in IOC fashion? Here are the CPAN $dbh
factories:
# DBIx::DBH - the latest on CPAN. by me. uses perl hashrefs
http://cpan.uwinnipeg.ca/htdocs/DBIx-DBH/DBIx/DBH.html
# DBIx::Password - the oldest on CPAN, by Brian Aker. He refused my
patches to support Alzabo-style and DBIx:AnyDBD style DBI datbase
connections, so I had to write DBIx::Connect
http://cpan.uwinnipeg.ca/htdocs/DBIx-Password/DBIx/Password.html
# Config::DBI - Config::ApacheFormat based. written by me.
http://search.cpan.org/~tbone/Config-DBI-1.8/lib/Config/DBI.pm
# DBIx::Connect - AppConfig based. written by me.
http://search.cpan.org/~tbone/DBIx-Connect-1.13/lib/DBIx/Connect.pm
# Ima::DBI - the most widely used one because it is part of
Class::DBI. Originally by Mike Schwern, now maintained by T. Bowden.
http://cpan.uwinnipeg.ca/search?query=Ima%3A%3ADBI&mode=dist
--
_______________________________________________
sw-design mailing list
[email protected]
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
