Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: Constant Variables

by dga (Hermit)
on Mar 28, 2003 at 16:44 UTC ( [id://246509]=note: print w/replies, xml ) Need Help??


in reply to Constant Variables

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) );

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"; }

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";

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) );

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": }

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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://246509]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2024-03-29 01:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found