Re: module multi-config strategy
Perrin, you mean that I can actually set my environment per virtual-host? that's encouraging in the one-implementation per site scenario. Now I does block any use of persistent variables, unless I store them in a RDBMS or in the 'Globals' module you mentioned. It could really be a module that just exported references to internal hashes. I'm starting to like it. A module that exported persistent hashes (not across server restarts, just across requests ... short lived persistence). Maybe it could be loading the 'config' hashes from disk every once in a while, say every 10 seconds, to be able to reconfig without restarting. And the ability to commit a given hash ('config') to disk to make it permanent. mmmh. an idea is shaping here in my tiny head ... anyone care to comment? martin Perrin Harkins wrote: > > You can have a module full of globals that is different for each site (it > doesn't have to go in the same directory as your other shared code), or > you can put things in httpd.conf with PerlSetVar and read them with > $r->dir_config(), which allows a separate configuration for each virtual > host. > > - Perrin
Re: module multi-config strategy
On Mon, 24 Jul 2000, martin langhoff wrote: > Now, the idea is to have one codebase, written in a module that serves > all of our sites. Each site should have its own (rather complex) > config. Each and every subroutine must know in which context it's > being called, and I don't really want to pass the config as a > parameter to every damned sub. You can have a module full of globals that is different for each site (it doesn't have to go in the same directory as your other shared code), or you can put things in httpd.conf with PerlSetVar and read them with $r->dir_config(), which allows a separate configuration for each virtual host. - Perrin
module multi-config strategy
hi list, i'm about to start writing the first of a series of internal modules, aimed at handling common features among sites we develop. Like, let's say, a 'latest news' box or a product guide/database. Now, the idea is to have one codebase, written in a module that serves all of our sites. Each site should have its own (rather complex) config. Each and every subroutine must know in which context it's being called, and I don't really want to pass the config as a parameter to every damned sub. Currently, I keep the configs as a global hash inside the module, that's good when you've got one module per implementation. I won't scale further justlike that. Maybe I should have a hash inside the module, with the $ENV{HTTP_HOST} or $ENV{'SERVER_NAME'} as key and the configs as values. Maybe this same setup in a mysql table. But that'd allow only one implementation of each module per domain. And I think that maybe I'll someday need, say, 2 product guides (under different brands) in the same site / page. So that's not 'THE' way. Maybe something intermediate. But I don't really know how. Does anyone want to share his views on this? Maybe I could build a wrapper module, that manages the configs and sets them up in the environment. That'd be nice to post in CPAN. martin