mod_perl, OO and Globals

[M2]

Hi,
I'm looking for a way to store some common objects (e.g. a database handle)
in such a way that it may be accessed from anywhere within an OO based
mod_perl application.

My first attempt used the UNIVERSAL package to stash it but that felt
clunky, not to mention risky. For my second attempt I made all objects
inherit from a single object which returned them from a global. Of course
this has the potential for some dire issues under mod_perl even though
they're reset on each execution.

Outside of this I cannot seem to find a way to get the data accessible
without passing it around all over the place which I would dearly like to
avoid.

Am I missing something?

Matt.

 

[M2]

Post having written this I am pondering about the use of class variables. If
you have a class variable in an object that is inherited by all objects
would you have only a single instance of that variable? Would mod_perl cause
any issue?

 

[James Willmore]

Hi,
I'm looking for a way to store some common objects (e.g. a database handle)
in such a way that it may be accessed from anywhere within an OO based
mod_perl application.

My first attempt used the UNIVERSAL package to stash it but that felt
clunky, not to mention risky. For my second attempt I made all objects
inherit from a single object which returned them from a global. Of course
this has the potential for some dire issues under mod_perl even though
they're reset on each execution.

Outside of this I cannot seem to find a way to get the data accessible
without passing it around all over the place which I would dearly like to
avoid.

Am I missing something?

A couple of suggestions:

1) _Don't_ use UNIVERSAL unless you know what you're doing. It is my
understanding that it makes all objects available to all classes - and
that _may_ not be what you want to do. It can create inheirtance
issues, as well as overwriting methods and attributes. I could be
wrong about this, but (as of today) that's my understanding.

2) read the documentation on OO: perltoot, perlboot, perlbot.

3) As silly as this may sound, try mapping out what you want to do
first. During this exercise, you may find an easier, faster way to do
things. Redundancy can be eliminated and cleaner code could be
written - just by putting pencil to paper.

4) Get familiar with Data:umper. It's a great tool to see where
your values are and how they're being handled.

5) You could investigate some of the DBIx modules (yes, x at the end).
Some of them _may_ deal with what you want to do already.
Persistance with DBI is sometimes a pain. These modules may have
addressed this issue for you.

HTH

Jim

 

[pkent]

I'm looking for a way to store some common objects (e.g. a database handle)
in such a way that it may be accessed from anywhere within an OO based
mod_perl application.

Just keep the data in package globals, and it can persist as long as the
mod_perl child exists. It also doesn't matter that your application is
OO, or not, or only partly, if you were wondering.

Don't forget you can also tie hashes to DBMs, or serialize data
structures to disk if you want disk-backed caching.

P