On Tue, Sep 07, 2004 at 03:22:16AM +0000, Mark Stosberg wrote:
> 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');
Yes, it is easy to read the config file using Config::Auto. Lately, I've
been working on making installers for my applications so that I can
package and install them just like a CPAN module. Have you tried doing
this?
If you have or are thinking about it, I've found that it requires some
knowledge of the install path in order for the config file, templates,
etc to be found. Following the practices of Apache::Test, I have created
a few *.in files which get processed by Build.PL, have placeholders
replaced, and the .in file ending removed.
This could become cumbersome if I had to process all of my instance
scripts in order to declare the paths to the config file. I know that
Config::Auto does some automatic searches, but it wouldn't find my config
files which are in '[ProjectDir]/conf/*.conf'. Depending on where I call
Config::Auto::parse(), I may need to use different relative paths which
makes absolute paths more attractive. Any ideas would be appreciated.
> > 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.
OK, good example but here's a countercase for illustration.
I have an application that runs an entire website. It contains many
instance scripts which all need access to some parts of the
configuration. Having a separate config file for each instance script
would add unnecessary redundancy. Calling the cfg_file() method would
introduce the problems I describe above as well as add more code to my
simple instance scripts. Putting the cfg_file() into setup simplifies
configuring the system for all instance scripts.
I think that both cases are valid and that simply rewording the text
to explain that it can be used in both ways would be sufficient. I've
attached a diff with my attempt at rewording (and a few minor mods).
> 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');
This is a great example. Question: Where do you store your config files?
> 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.
This is another good example.
> 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.
Precisely.
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- ConfigAuto.pm.orig 2004-09-07 09:45:57.000000000 -0400
+++ ConfigAuto.pm 2004-09-07 09:58:30.000000000 -0400
@@ -48,19 +48,29 @@
to your L<CGI::Application|CGI::Application> modules. Lazy loading is used to
prevent the config file from being parsed if no configuration variables are
accessed during the request. In other words, the config file is not parsed
-until it is actually needed.
+until it is actually needed. The L<Config::Auto|Config::Auto> package provides
+the framework for this plugin.
=head1 RATIONALE
C<CGI::Application> promotes re-usable applications by moving a maximal amount
of code into modules. For an application to be fully re-usable without code changes,
-it is also necessary to store configurations variables in a separate file.
+it is also necessary to store configuration variables in a separate file.
+
+This plugin supports multiple config files for a single application, allowing
+config files to override each other in a particular order. This covers even
+complex cases, where you have a global config file, and second local config
+file which overrides a few variables.
+
+This plugin can be called in either the instance script or the setup method.
+It is recommended that you to declare your config file locations in the
+instance scripts, where it will have minimum impact on your application. This
+technique is ideal when you intend to reuse your module to support multiple
+configuration files. If you have an application with multiple instance scripts
+which share a single config file, you may prefer to call the plugin from the
+setup() method.
+
-This plugin asks you to declare your config file locations in the instance scripts,
-where it will have minimum impact on your application. It supports multiple config
-files for a single application, allowing config files to override each other in a
particular
-order. This covers even complex cases, where you have a global config file, and second
-local config file which overrides a few variables.
=head1 DECLARING CONFIG FILE LOCATIONS
---------------------------------------------------------------------
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]
