[Catalyst] RE: Configuration Approach

[Stephen Adkins]

Hi,

My favorite configuration module is App::Options (p.s. I wrote it).

http://search.cpan.org/~spadkins/App-Options/lib/App/Options.pm
http://search.cpan.org/src/SPADKINS/App-Options-0.99/README

The documentation (above) includes the features list and comparison
to modules like AppConfig.

I use a two-level configuration strategy. I use App::Options for low-level
configuration of deployment-time values (i.e. Java's "deployment
descriptor").
This deployment information includes the name(s) of richer, higher-level
(YAML, etc.) configuration files which are almost like application source
files.

Stephen

P.S. App::Options is especially good at configuring web applications,
cron scripts, and other difficult-to-configure programs that don't have
access to user environment variables. It also manages the @INC variable
to facilitate multiple installations of software on the same server.

On 10/26/05, Christopher Hicks <chicks at chicks.net> wrote:
>
> On Wed, 26 Oct 2005, Dami Laurent (PJ) wrote:
> > Actually the places where I used AppConfig are not (yet!) on Catalyst.
> > However what I will most probably do when I port them to Catalyst is to
> > call AppConfig from MyApp->setup(), and insert the results into
> > $c->config(...) so that config data becomes available to all subsequent
> > requests.
>
> AppConfig is really slick and we've used it in a number of CGI's we've
> shipped to customers before we started using Catalyst extensively. I
> haven't used AppConfig with Catalyst either. Some of that is because of
> frustration with trying to help Andy move things along. He seemed too
> busy to try to deal with somebody "helping out" when I offered to submit
> patches to resolve some of the inconsitancies in AppConfig. A rewritten
> AppConfig that supported the full body of the AppConfig syntax across all
> the file formats with cleaner Catalyst integratin would be great. (If
> this is going over your head, AppConfig provides a few forms of
> substitution in the config files, but that substitution doesn't have any
> effect on the command line arguments which would often be quite handy.
> The failure here is that the individual drivers for the pulling stuff in
> from files, etc. are each built with these substitutions embedded in them
> instead of refactoring that to a higher level.)
>
> Even in its current form though its one of the handier Perl modules.
> Integrating the concept of command line arguments, config files, and
> internal program defaults into a signgle framework has been attempted on
> many occasions, but usually the results are much uglier than AppConfig.
>
> --
> </chris>
>
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/catalyst/attachments/20051026/b7ad94a4/attachment.htm