At 7:43 AM +0200 5/16/02, Gerald Richter wrote:
> > use lib "$ENV{DOCUMENT_ROOT}/data/";
>> use lib "$ENV{DOCUMENT_ROOT}/data/SWC";
>> use SWC::Calendar;
>> use SWC::Commons;
>> use SWC::HashChain;
>>
>
>I would move this in a startup.pl file that is executed on server startup.
>This is more memory efficient and you have one central place to set it up.
I tend not to do that because I some of my sites are hosted at
hosting facilities where I don't have that level of control, and also
the "use lib" statements are per-virtual-host. (There are of course
problems if I'm running different versions of the software in such a
situation--that's a pain. It would really help if Apache had a
virtual-host option that would allow locking down certain processes
to certain virtual hosts.)
One other question, related to virtual hosting.
When I create an object that I want to make persistant across a
particular site, I just pick a name-space. E.g.
$IMH::MyData = some-init-routine;
However I'd like to package some of these modules up for general use,
and it would be nice if every HTML file file didn't have to be edited
to change the names each time. Is there any name-space available in
Embperl that I could use on a per-site basis with a single name? In
other words, something like:
$MySite::MyDate = some-init-routine;
where $MySite varied depending on the current web site being served.
If Embperl setup such a name space it would make my code much more
portable and reduce the risk of conflicts. In the mail from Luiz it
appears that he stores his information in a pointer off of the
request record, but that is going to be per-process, rather than per
site. I supposed I could make my object initializer do what his do
(cache the pointer and return it on new calls), but do so on a
per-site basis.
I need to sit back and think about isa and object. I hadn't looked
at them before and it's going to make me rethink how I've been doing
things.
You know, when you're at the O'Reilly conference, you should talk to
them about doing an Embperl book. There is so much buried in the doc
page that needs to be called out in a good book.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
