On 2004-09-06, William McKee <[EMAIL PROTECTED]> wrote:
>
> I think that I'm going to like Config::Auto. One problem I have with the
> plugin is that there are places (e.g., tests and the Build.PL) where I
> need data in the config file. What I've done is modify my subroutine
> that retrieves the configuration data to check whether webapp is set. If
> it is, then we use the plugin; if it isn't, then I use Config::Auto. I'm
> sure this isn't ideal but I'm trying to refactor as little code as
> possible while I get comfortable with this new system.
I also expect to need access to the config file from outside of my
CGI::App modules. In that case I would just access Config::Auto
directly, which is very easy:
my $cfg = Config::Auto::parse('file.pl');
> Also, your pod mentions that the cfg_file method should be called in the
> instance script. All 674 of my tests are still passing even though I
> don't call cfg_file until my setup() method is called. What are your
> reasons for making the following statement:
>
> This plugin asks you to declare your config file locations in the
> instance scripts, where it will have minimum impact on your
> application.
>
> What impact could it have that I may be overlooking? I've had no problem
> loading my config file in the setup method so far.
'Should' probably isn't the right word. There is no technical reason why
it has to be in the instance script (as you discovered). My feeling is that
this design follows the CGI::App philosophy of maximal re-use. Here's
a "use case" to illustrate the example.
Let's say that you developed a project that is actually directly
re-usable for multiple clients. Using just a different config file,
you can specify a different set of templates and a different database,
making a totally distinct application for the second client.
To minimize sys-admin time, you have just one copy of the applications
modules on the server, just as if they were CPAN modules.
The only thing you need to provide for each client is a different instance
script, which provides the location of their config file. The only
difference would be something like:
$app->cfg_file('first_client.pl');
vs:
$app->cfg_file('second_client.pl');
If you call "cfg_file()" in setup() (or anywhere in the module), you are stuck here,
in terms of direct code re-use.
If there is an alternative that makes sense to me, it's to also allow
setting the config file location via an environment variable. Then I
suppose you could set this in an Apache config file, and even use the
exact same instance script for multiple projects as well.
OTOH, if you are writing code you don't expect to be re-used, it hardly
matters, and it's easy to refactor later if that case arises
unexpectedly.
Mark
>
>
> Thanks,
> William
>
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
