Martin A. Langhoff wrote:
> Now I'm trying to go one step further and make the code ready to be
> implemented in a few more sites. The problem is that both the code and
> static varibles remain there in memory-space in a 'shared package'. And
> this 'shared package' model blocks me from having many sites with
> a] different 'configuration related' static variables
> b] different code versions
(a) keep from putting your 'configuration related' static variables in the
code. Either user a PerlSetVar configuraton or a package with just
configuration information, I'd say.
(b) for the different code versions, don't set the package using an eval.
Perhaps do something like setting up a hash with values which are references to
subs
perhaps $MyCalendar::handlers->{$code_version}{$functions_name} could be how
you reference all of your functions for all of your code versions. Each code
version is in a package like MyCalendar::vTwo and it's smart enough to setup
it's own $MyCalendar::vTwo->{$function_name} hash and create a reference to it
in $MyCalendar->{$code_version}. You can then pass the $code_version to your
front end embperl code as a string in a PerlSetVar config.
If you pass which code version in a PerlSetVar, you can probably have the same
embperl code referenced from different virtual hosts with different
configuration values
Now, this is not the only way to do it.. and it's probably not the best. I'm
sure the OO people will say, "setup a hash of constructors for all your code
versions." But it's just here to give you some ideas.
- David Harris
Principal Engineer, DRH Internet Services
