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]
