RJ Herrick am Sonntag, 5. Februar 2006 01.03:
> Thanks to the Johns for their responses, but I believe perhaps I was
> unclear about my intent.
>
> In validating my form input I look at my DB tables to see what types of
> input they will accept (valid values, maxlength, NULL ok, etc). This
> data is about the database, not the values coming in off the forms. It
> will stay the same until I alter my tables, which I won't be doing very
> often (in production at least :) ). So I'm looking to avoid gathering
> this metadata via DB calls every time I need to validate a form by
> instead using the cached metadata, stored somewhere by mod_perl. My
> thought was to put it into it's own namespace and have it available
> globally, loaded from one of my modules at startup.
> Does anyone else understand what I'm trying to say? I apologize if I'm
> not expressing myself in the right vernacular.
> Thanks,
> RJ Herrick
You could have a Cfg.pm module with a
my %Cache
variable. The new() method of the module fills the created object once into
this hash (keyed by the form name in your case). On further invocations of
new(), it returns the cached object from %Cache.
### The module also contains a sub
sub preload_cache {
my ($class, @formnames)[EMAIL PROTECTED];
my $dummy=__PACKAGE__->new($_)
for @formnames;
}
### Then, in the startup.pl:
use Cfg;
Cfg::preload_cache(qw / formname1 formname2 ... /);
### and somewhere else in the app:
my $cfg=Cfg->new($formname);
###
I have such a module in production and, since I was not sure if the config
objects stay shared (not very important in my case), I checked the addresses
on different usage. They seem to be always the same.
But I'm confused: The config objects are hold in object attributes of other
objects. This means, the config objects reference counts increase - and I
thought that this is an occasion where the object does not stay shared?!?
I can post the module if anybody wishes (good occasion for a code review).
hth, joe
