> 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.
> > 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 s
> 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 execu
> 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
> 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:
Content-Di
> 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
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
>
I don't have specific help for your problem, but I have noticed that
package-scoped lexicals can be somewhat unpredictable under mod_perl.
1) If at startup time (pre-fork) you use a function within a package
to set a lexical variable that is scoped to that package, that
variable may or may not
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
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 timin
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;
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 mod_per
> 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 al
14 matches
Mail list logo
