------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I like this method...
maybe in a table called constants with two columns - name and value (kinda like a hash).

That is what I'm doing, but how do I make it where the column "name" is like a variable, for instance if record 1 was this:


color1

red


How could I get it to have $color1 contain the value?

In other words, in case I did not make it clear...

$string1 = qq!Hello, my favorite color is $color1!;
How would I get using a database to do that, using Perl?
I don't see how the Export would do that, or the other things you showed.

thx,
Richard

It sounds as if you want to bind the variable $color1 to the value of a the corresponding column in the current row. Check out the bind_col and bind_columns methods of DBI.

Update: As CPAN appears to be down, here is the basic syntax (grabbed from perldoc DBI);

    $rc = $sth->bind_col($column_number, \$var_to_bind);

and

    $rc = $sth->bind_columns(@list_of_refs_to_vars_to_bind);
[download]

The variables pretty much explain themselves ;-), but if you don't get it, do a perldoc DBI (or equivalent) and find the complete doc.

I can't see how you can do well what you want; others more experienced may well have a trick to do it. Maybe something along the lines of:

my $x = "variable_name";
my $value = "value";
eval "\$$x = $value";
warn $@ if $@;
print $color1;
[download]

Which works, but not under use strict.

My suggestion would be to change your approach to use a hash. This would greatly simplify things.

my %config;

# use database (DBI) to read key / values into hash
# ...
$config{color1} = "red";

print $config{color1};
[download]

Update: Just re-read your question. You want a way to provide access to the %config hash on each page. You could use a module to do this, exporting the %config hash.

You don't want to do that. You want to have a hash of configuration values. That way, you do something like:

my $string1 = qq!Hello, my favorite color is $config{color1}!;
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Storing preferences in the database might be done like so.

create table prefs ( user_login text, color1 text, color2 text, fontsi
+ze text, ... , primary key (user_login) );
[download]

Later in Perl

use constant DS => 'my dsn here';

# later ...
my $dbh=DBI->connect(DS);
my($color1, $color2, $fontsize);
eval {
  my $sth=$dbh->prepare("SELECT color1, color2, fontsize, ... FROM pre
+fs WHERE user_login=?");
  $sth->execute($login);
  $sth->bind_columns( \( $color1, $color2, $fontsize ) );
  $sth->fetch;
  $sth->finish; # using primary key to only fetch 1 row
};

if($@)
{
  print STDERR "Informative error message goes here with $@ for good m
+easure\n";
}
[download]

This will bind color1 to $color1 etc. They will be undef if they aren't set in the database. Another option is to have a prefs hash so that you dont have a zillion named variables all floating around for a long time all doing the same thing. But if you ant to add a new preference type you need to alter the prefs table and change the code everywhere prefs are accessed.

#change lines from above
my($color1 ...); #becomes
my $prefs;
#bind_columns becomes
  $sth->bind_columns( \my( $c1, $c2, $fs ) );
  $prefs={ color1 => $c1, color2 => $c2, fontsize => $fs };
#later to get a pref
print "My favorite color is $prefs->{color1}\n";
[download]

The bind columns could be done other ways like binding directly into $prefs. This way makes the bind_columns short and makes the assignment to $prefs seperate so if it gets long it can be split over many lines for clarity. If you add a new preference this makes a new bind variable you have to add and also change the prefs assignment also which is a drawback. Another drawback is that a new preference type requires altering the prefs table in the database.

My preferred way to set up the table would be.

create table prefs ( user_login text, prefname text, prefvalue text, p
+rimary key ( user_login, prefname) );
[download]

Then prefs can be added as desired to the database and the perl code pick them up next time through.

my %prefs;
...
eval {
  my $sth=$dbh->prepare("SELECT prefname, prefvalue FROM prefs WHERE u
+ser_login=?";
  $sth->execute($login);
  $sth->bind_columns( \my( $n, $v ) );
  while($sth->fetch)
  {
    $prefs{$n}=$v;
  }
};

if($@)
{
  #as before
}
#later to use
print "My favorite color is $prefs{color1}\n";
# or even
foreach my $p ( keys %prefs )
{
  print "I like my $p to be $prefs{$p}\n":
}
[download]

Now adding a pref to the database will make it available in %prefs to your CGI programs. Any unset prefs in the database are not loaded into the hash at all and defaults could be used etc. This version only loads prefs which are defined for the current user into your address space and a new preference only needs to be referenced in the perl code and users which want that preference get it in the database and it magically is available in all scripts which access the prefs table to use as they wish. This method is very extensible and the primary key assures that each user has exactly 0 or 1 preference of each type.