I swore there was yet a third candidate in this realm, but I
didn't see it on brief inspection.
Config::General also parses Apache-style config files, but I don't think it
handles Apache specific details like contexts.
Michael
Joe Breeden [mailto:[EMAIL PROTECTED]] wrote:
...
wondering about alternatives to embedding SQL in to the code
of a program.
...
It would be interesting to know how other people have solved
that problem.
One approach is to use something like Ima::DBI, which I'm currently toying
with.
This is a general Unix webserver issue and not specific to
mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism to start
And forking a new process under mod_perl
really defeats the purpose.
Does it?
Well I confess I just assumed.
I used to believe that too, but now that I've developed
applications that make rather extensive use of the Apache API, I would
actually love to have an environment similar
Andrew Ho [EMAIL PROTECTED] wrote:
I know how to use "package" in the normal case, where it's static.
However, you can't say "package $foo" or even "eval 'package
foo'" or even "BEGIN { eval 'package foo' }." I'm wondering
if there's any way short of hacking the Perl source itself
to
Thanks, I though it was going to be something STUPID, like
this. Is there a
header I can use that will tell IE another file name
'FIlename: xxx.pdf' or
something?
You can try:
Content-Disposition: attachment; filename=somefile.pdf
Or I think even this may work:
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be
I use the following (not sure about the actual content-type, but it
seems to work
Content-Type: text/x-csv
Content-Disposition: attachment; filename=somefile.csv
Michael
-Original Message-
From: Robert Friberg [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 10, 2000 4:17 PM
To:
There's a mailing list set up at sourceforge for discussing
object-persistence issues and tools for use with perl:
http://mail1.sourceforge.net/mailman/listinfo/poop-group
Michael
darren chamberlain wrote:
...Except that by calling Foo:load_var() you are setting
$PACKAGE_LEXICAL
to undef (by passing in an empty list via ()), rather than
retrieving it.
Well, actually, I was checking to see if it was set first:
sub load_var {
my $param = shift;
Perrin Harkins wrote:
This sounds like a bad interaction with PerlFreshRestart and closure
variables. Does it work if you turn off PerlFreshRestart?
Can you live
with that?
Yes! It works with PerlFreshRestart Off. I think you're right - it
probably has something to do with the timing
I'm experiencing a strange variable scope issue.
Normally, I expect that lexical 'my' vars declared at the package
scope (i.e. at the top of a file), should be visible to subroutines
declared in the same package, and should maintain their values between
calls to those subroutines.
Under
Andy Wardley wrote:
* The Template Toolkit is *ONLY* a template system. This is a Good
Thing. It processes text (HTML, Latex, POD, etc). You can use it
under Apache/mod_perl, in stand-alone CGI scripts, or in other
environments entirely unrelated to HTML or the web. This is also
a
13 matches
Mail list logo
