Problems? Is your data what you think it is? | |
PerlMonks |
Re: Constant Variablesby dga (Hermit) |
on Mar 28, 2003 at 16:44 UTC ( [id://246509]=note: print w/replies, xml ) | Need Help?? |
Storing preferences in the database might be done like so.
Later in Perl
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.
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.
Then prefs can be added as desired to the database and the perl code pick them up next time through.
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.
In Section
Seekers of Perl Wisdom
|
|