Terrance,

On Dec 28, 2004, at 11:50 AM, Terrence Brannon wrote:
and so I developed Config::DBI based on Config::ApacheFormat

http://search.cpan.org/~tbone/Config-DBI-1.8/lib/Config/DBI.pm

I see where you are passing the code ref in the example, but it seems to be all on one line, which is not good for me as sometimes IOC::Service sub-refs can get quite large.


Is the single line a restriction? Or do you end up having to use \ characters to span multiple lines (which is just nasty).

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.

IOC actually aims to be not provide any more structure than the Registry->Container->Service hierarchy, and allow you to structure your database info in any way you like from there. My example is just how we do it here (actually it's simplified from how we actually do it, but why bother you all with the details), but it is by no means how I would expect others to do it, nor is it the only way you can do it with IOC.


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).

Amen to that!!

        </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.

Nice, I did not see that in the docs.


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:

You can use any of these with IOC (I assume). IOC's main goal is to manage the configuration information and (if needed) the components lifecycle. IOC does somewhat conflict with modules which have their own complex, but for the most part they are still useable with it.


- Steve






_______________________________________________ sw-design mailing list [email protected] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design

Reply via email to