Brett Randall wrote:
On 11 Mar 2004, Perrin Harkins wrote:
As Skylos also pointed out, a common approach for handling these
things is to have a singleton class. If that sounds too confusingly
OO for you, just think of a simple utility function that you always
call to get a $dbh:
Wow... Perrin..
On 11 Mar 2004, Perrin Harkins wrote:
> As Skylos also pointed out, a common approach for handling these
> things is to have a singleton class. If that sounds too confusingly
> OO for you, just think of a simple utility function that you always
> call to get a $dbh:
Wow... Perrin... That seems to
Skylos the Doggie wrote:
On Thu, 11 Mar 2004, Perrin Harkins wrote:
Skylos was guessing you had closure problems from doing this. However,
if these are always globals, you will not get closures from this. What
you need to look for is some place where you are either using $dbstr and
friends as
On Thu, 11 Mar 2004, Perrin Harkins wrote:
> Skylos was guessing you had closure problems from doing this. However,
> if these are always globals, you will not get closures from this. What
> you need to look for is some place where you are either using $dbstr and
> friends as lexicals (my $dbstr
On Thu, 11 Mar 2004, Brett Randall wrote:
> On 11 Mar 2004, Skylos the Doggie wrote:
> > My solution to this problem is to pass EVERYTHING. I don't rely on
> > any subroutine to know Any data that isn't passed to it *explicitly*.
> > Using global or even local or even package variables is baad he
Brett Randall wrote:
My problem is that SOMETIMES while accessing one virtual host, it will
appear as though it is actually pulling data from the other virtual
host's database (each virtual host uses a different database as shown
below), however the URL does not change. All the links, etc, continue
Brett Randall wrote:
You are most likely running into name space conflicts.
That is what I *THOUGHT*, however this still shouldn't be
happening. The namespace should be based on the virtual host name, as
well as the path, shouldn't it?
It is for scripts handled by Apache::Registry, which don't de
On 11 Mar 2004, Skylos the Doggie wrote:
> My solution to this problem is to pass EVERYTHING. I don't rely on
> any subroutine to know Any data that isn't passed to it
> *explicitly*. Using global or even local or even package variables
> is baad here.
So if I want to have a database that is con
On 11 Mar 2004, Cees Hek wrote:
> Brett Randall wrote:
>> My problem is that SOMETIMES while accessing one virtual host, it
>> will appear as though it is actually pulling data from the other
>> virtual host's database (each virtual host uses a different
>> database as shown below), however the URL
Brett Randall wrote:
My problem is that SOMETIMES while accessing one virtual host, it will
appear as though it is actually pulling data from the other virtual
host's database (each virtual host uses a different database as shown
below), however the URL does not change. All the links, etc, continue
Ah, the closure problem.
Subroutines inside of your asp scripts behave as closures.
virtualhost A sets variables... and declares a subroutine that uses these
variables.
an access to virtualhost B accesses the same subroutine - which is already
loaded with variables per the virtualhost A in closu
11 matches
Mail list logo
