Peter,
When we use global configuration files we use Config::General from CPAN to
manage Apache style config files. We normally do this for applications we
expect to install more than once. We store database access information (i.e.
username, password, database name, server info), the install path, etc.
In regard to CGI::App, We load the returned config::general hash into
param() via setup in our CGI::App superclass to pass the info down to inherited
classes. We often setup a DBI connection with the params from the config file
and pass the DBI object into param(). As a general rule we never put things
that change after the install in a config file.
Sincerely,
Kenny Pyatt
President
Venzia
http://www.venzia.com
---------- Original Message -----------
From: "Jesse Erlbaum" <[EMAIL PROTECTED]>
To: "'Peter Masiar'" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Sent: Thu, 2 Jan 2003 16:11:48 -0500
Subject: RE: [cgiapp] Global configuration
> Hey Peter --
>
> > I recently found interesting initiative, p5ee, which wants to be
> > enterprise-approved perl, like j2ee is.
> > They have list of CPAN modules they approve:
> > http://www.officevision.com/pub/p5ee/component> s.html
>
> Maybe they should list modules they *don't* approve. It might be a
> shorter list!
>
> Do they have marketing $$$ behind this idea? Without the bucks, J2EE
> wouldn't exist. There is no Temple of the Enterprise Engineers to whom
> to appeal for "approval".
>
> >From my brief glance, "P5EE" seems like YAPPO -- Yet Another Perl
> Programming Opinion. Maybe we should have a new CPAN hierarchy --
> YAPPOx::, anybody?
>
> > Config::IniFiles is THE way for config, by p5ee guys. ;-)
>
> On the subject of "config files" -- I've mostly used two techniques
> for configuration data:
>
> 1. In the *.pl|cgi instance script.
> 2. In a Perl module.
>
> (For the purpose of discussion, let's assume "configuration" refers to
> key => value pairs, consisting of scalar values. After all, that's
> what is stored in an "*.ini" file.)
>
> The two techniques above are the ones I use most often. I generally
> avoid "*.ini" type files as they are just another asset which has to be
> managed. They're marginally easier to edit than Perl, but way too hard
> to manage for most non-techie users without a GUI interface.
>
> I have used databases to store this information on occasion, however.
> There are some tremendous advantages to doing so. Primarily, once it's
> in a database the task of managing run-time settings can be pushed out
> to a user-friendly application. The database handles all the issues of
> distribution, access and concurrency.
>
> Here's a MySQL-style table DDL:
>
> CREATE TABLE SiteSettings (
> setting_name varchar(64) NOT NULL default '',
> setting_value_int int(11) default NULL,
> setting_value_char varchar(255) default NULL,
> PRIMARY KEY (setting_name)
> )
>
> All you have to do now is assign particular "Keys" to various system
> settings. For example:
>
> INSERT INTO SiteSettings (setting_name, setting_value_char)
> VALUES ('SMTP_SERVER', 'mail.erlbaum.net');
>
> ...Or...
>
> INSERT INTO SiteSettings (setting_name, setting_value_int)
> VALUES ('ADMIN_USER_ID', 23);
>
> This system now allows you to use some RDBMS cleverness to smooth your
> application code. For example, imagine you wanted to get the email
> address of the "Admin User":
>
> SELECT
> email_address
> FROM
> SiteSettings LEFT JOIN Users
> ON SiteSettings.setting_value_int = Users.user_id
> WHERE
> SiteSettings.setting_name = 'ADMIN_USER_ID';
>
> If you were using an "INI" file you would have to first read the data
> from that source and then select from the database. This way you can
> perform the same task in a single operation.
>
> > And CGI::Application is one of approved Application Frameworks.
>
> I feel so.... Validated! Heh...
>
> TTYL,
>
> -Jesse-
>
> --
>
> Jesse Erlbaum
> The Erlbaum Group
> [EMAIL PROTECTED]
> Phone: 212-684-6161
> Fax: 212-684-6226
>
> ---------------------------------------------------------------------
> Web Archive: http://www.mail-archive.com/[email protected]/
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
------- End of Original Message -------
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
