On Tue, 4 Sep 2001, darren chamberlain wrote:
> Hi folks,
>
> Though the current pod concentrates on %ENV, the "Env" the module
> is designed to work with An Environment, in the sense of "the
> stuff going on around your process that gets inherited and can
> hold relevent information to your process". %ENV just happens to
> be the default, because it makes the modules (and its tests) work
> out of the box. (I realize that only OO purists might actually
> use it to replace %ENV.)
>
> I just reread the pod I posted, and it does have place a very
> strong emphasis on being a wrapper around %ENV. I should
> definitely modify that, because %ENV is just one possibility,
> and, as Mark pointed out, not a particularly good one.
Ah, thanks for the clarification Darren.
> True. But, using the DBI::Env example from the SUBCLASSING
> section of the pod:
>
> use DBI::Env;
>
> my %CUSTOMER;
> tie %CUSTOMER, 'DBI::Env', $ENV{'REMOTE_USER'};
>
> print "Hello, $CUSTOMER{'Contact Name'}. Your company has a ",
> "balance of $CUSTOMER{'balance'}";
>
> does work; there is a tied interface, so that your environment
> (%DB_ENV in this case) can be treated exactly like %ENV.
>
> The module isn't designed to replace %ENV in things like CGI
> scripts, though; it's designed to complement it. When a customer
> logs in to the protected area of my website, that customer's
> environment is very different from Perl's environment.
That seems more familiar to me. I also use a hash to store session data
for web visits. To set up a tie interface seems like extra work to me
though, since I can already get a hashref back directly from DBI by using
selectrow_hashref() (and there already interfaces that "tie" databases
through the DBI). There's More than One Way To Do It, though-- perhaps
your method will be a better solution for some people in some
problemspace. :)
-mark
http://mark.stosberg.com/
