Perl v5.6.0 for Apache/1.3.29 (Unix)
mod_perl/1.29
CGI::Application 3.1
Apache::Reload 0.07
Before I send it to mod_perl list I put it here because the problem
mainly concerns C::A.
There is a testing environment:
tester.cgi:
==
#!/usr/local/bin/perl -w
use Tester;
my $webapp =
Before I send it to mod_perl list I put it here because the problem
mainly concerns C::A.
No, not really. To the degree that you are having problems with
Apache::Reload, this is a mod_perl/Apache::Reload problem.
But the problem that the error message you gave us pertains to a basic
Perl
Richard Dice wrote:
Apart from that, to use Apache::Reload, you need to put a reference to
it in *every* file that you want to have reloaded.
And I've found you have to restart Apache anyway, since it doesn't -- in
my installation at least -- seem to do very much except generate gobs of
error
On 2004-01-27, Cees Hek [EMAIL PROTECTED] wrote:
Mark Stosberg wrote:
I highly agree that something like ::Variant would be useful. For my own
case, I might try to break the changes in my sub-class into several
pieces, each of which would be separate from the others. I think that
would make
I think Domizio's case is similar, even though it's not a sub-class,
because it passes all the current CGI::App tests.
I would be careful about stating that it passes all the tests, because I
don't believe it does. The failures seem to be minimal but they are
there.
it's not a matter of
Domizio Demichelis wrote:
I think Domizio's case is similar, even though it's not a sub-class,
because it passes all the current CGI::App tests.
I would be careful about stating that it passes all the tests, because I
don't believe it does. The failures seem to be minimal but they are
there.
Is there a problem with CGI-Application and the latest download from
ActiveState? I can run a regular CGI script from the same
folder/directory that my CGI-App index.cgi is in. The CGI-App doesn't
work. The only change (it was working before) was updating to the latest
AS distro.
Robert
I have 5.8.2.808 and I am only using CGI-Application and HTML-Template.
I am going to do a reinstall of Apache to see if that is a problem as
well.
Ah! From the log:
[Mon Jan 26 14:12:29 2004] [error] [client 127.0.0.1] Premature end of
script headers: c:/apache/users/webapp/index.cgi
[Mon Jan
Bob Hicks wrote:
I have 5.8.2.808 and I am only using CGI-Application and HTML-Template.
I am going to do a reinstall of Apache to see if that is a problem as
well.
I should have reread the Subject and I would have realized you were
using 5.8.2...
Ah! From the log:
[Mon Jan 26 14:12:29 2004]
Ugh. I am the idiot here. I was testing CGI vs. CGI::Simple and then got
sidetracked for a month or so. I had even forgot I subclassed it!
Serves me right!
Thank you for helping.
-Original Message-
From: Cees Hek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 5:19 PM
To:
thank you for your detailed answer:
I missed that part of the documentation. It is a bit confusing because
in one sentance you say this module pass all the tests of
CGI::Application 3.1, but then later on you say, This module implements
on purpose a little but useful difference that should
On 2004-01-23, Bill Moseley [EMAIL PROTECTED] wrote:
Yesterday Mark Stosberg wrote:
However, I think some people here will agree that CGI::App/H::T is a
popular alternative to the server-page paradigm that TT is built on.
That caught my attention as I'm missing the distinction. Isn't
However, I think some people here will agree that CGI::App/H::T is a
popular alternative to the server-page paradigm that TT is built on.
That caught my attention as I'm missing the distinction. Isn't
server-page more Mason/PHP/JSP? TT and H::T are in the same camp, seems
to me.
On 2004-01-28, Brett Sanger [EMAIL PROTECTED] wrote:
I have to agree with the other poster that C::A/TT is far more like
C::A/H::T than a server-page paradigm.
TT does have a lot more processing features, and some people do put the
application into the page, but a good many of us (and I know
On 2004-01-23, petersm [EMAIL PROTECTED] wrote:
Not to keep harping on the subject, but this is also possible with
CheesePizaa::TemplateLoader.
Would it possible to abstract this module so it's useful with DBI and
H::T, without using the rest of the CheesePizza framework? It seems
useful and I
What are other specific features that would make TT attractive to an
H::T user? Someone already mentioned the ability to more easily
reference objects. What are some other favorite features that get used
frequently?
For me, referencing objects is useful. The biggest draw, however, is
Mark Stosberg wrote:
What are other specific features that would make TT attractive to an
H::T user? Someone already mentioned the ability to more easily
reference objects. What are some other favorite features that get used
frequently?
Like I have mentioned in a previous email, my main reason for
William McKee wrote:
After initial joy of abstracting my
SQL, I grew to hate the DBIx::Recordset API because I couldn't
understand my own code when I went back to code after several months.
1 - if your recordset calls were wrapped in a descriptive function name,
perhaps the inability to
Mark Stosberg wrote:
Could you say more about this William? I usually inline my SQL. The one
time I tried to abstract out of the code, I felt like it was an extra
layer of abstraction that made the code harder to understand and debug
without benefits that exceeded that. What specific benefits do
NAME
Config::DBI - database connection support via Config::ApacheFormat files
SYNOPSIS
In .cshrc:
setenv DBI_CONF dbi.conf
In dbi.conf:
# Pass may be a password, or STDIN in which case, the password is
# is prompted for:
PassSTDIN
# Connect attribute
# dbi_connect_method
20 matches
Mail list logo
