say, rfc's are good for something after all ;) ok, form_data() it is!
At 12:16 PM 5/17/00 -0600, Bruce W. Hoylman wrote:
Ciao!
I am searching for the makings of a framework built around or within
mod_perl/Apache::DBI that supports the consistent update of a record
within a database. Primarily I am wanting to ensure read/write
integrity between database accesses
On Wed, 17 May 2000, Doug MacEachern wrote:
On Wed, 17 May 2000, Dave DeMaagd wrote:
I'm in the midst of converting a script I wrote in a CGI environment
to mod_perl (using Apache::Registry). The scripts are running fine
(after a little tweaking to get rid of globals and whatnot), but
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
if i don't do so,
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r =
arggg... i was sticked to "use" instead of "require"...
but how about if i've to import something?
Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines
i know that, but it doesn't work if i use "use", since the block
will be eval()'d at compile time:
eval {
die unless $ENV{MOD_PERL};
use Apache::Constants qw(:common);
...
};
it complains if Apache::Constants is not installed.
Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth
On Thu, 18 May 2000, Kenneth Lee wrote:
i know that, but it doesn't work if i use "use", since the block
will be eval()'d at compile time:
eval {
die unless $ENV{MOD_PERL};
use Apache::Constants qw(:common);
...
};
it complains if Apache::Constants is not installed.
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the
I am testing the use of Apache::PerlVINC but I think I must
do something wrong because I get an error on the PerlRequire
statement in the following bit of httpd.conf when starting
apache:
-
PerlModule Apache::PerlVINC
VirtualHost _default_:8443
Doug MacEachern wrote:
personally, i'd like to see Apache::HTML for generating html, written in
c. something simple along the lines of HTML::AsSubs, then another class
to glues it and Apache::Request together that provides CGI.pm features,
like 'sticky forms'. but, i haven't given that
On Thu, 18 May 2000, Drew Taylor wrote:
Doug MacEachern wrote:
personally, i'd like to see Apache::HTML for generating html, written in
c. something simple along the lines of HTML::AsSubs, then another class
to glues it and Apache::Request together that provides CGI.pm features,
Drew Taylor wrote:
Doug MacEachern wrote:
personally, i'd like to see Apache::HTML for generating html, written in
c. something simple along the lines of HTML::AsSubs, then another class
to glues it and Apache::Request together that provides CGI.pm features,
like 'sticky forms'.
On Thu, 18 May 2000, Peter Haworth wrote:
I'm getting more confident about calling it
Apache::Request::Form (no "s", for name similarity with
CGI::Form) now. It is dependent on Apache::Request,
after all, and reusing the CGI::Form name makes it look
more general than it really is, not to
brian moseley wrote:
On Thu, 18 May 2000, Peter Haworth wrote:
I'm getting more confident about calling it
Apache::Request::Form (no "s", for name similarity with
CGI::Form) now. It is dependent on Apache::Request,
after all, and reusing the CGI::Form name makes it look
more
brian moseley wrote:
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')'
On Wed, 17 May 2000, Doug MacEachern wrote:
personally, i'd like to see Apache::HTML for generating html, written in
c. something simple along the lines of HTML::AsSubs, then another class
to glues it and Apache::Request together that provides CGI.pm features,
like 'sticky forms'. but, i
"Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes:
Gunther This first criteria seems a tad odd to me. What business
Gunther scenario is there for this?
Gunther To me, when a user issues an update they expect that the
Gunther record exists. In a way, if the record does
On Thu, 18 May 2000, Drew Taylor wrote:
No, my /CURRENT/ setup uses CGI.pm. I want to eliminate
it entirely in this new module, while not having to
change any of my existing application code. I would like
to not change any lines like the ones above when
switching to the new module.
ah, ok.
brian moseley wrote:
i suggest that instead of subclassing Apache::Request, you
write the following set of classes:
1) html widget class
2) sticky forms class - use html widget class, take $r or $q
as param
3) "wrapper" class - gives you the CGI.pm interface, uses
sticky forms
brian moseley wrote:
On Thu, 18 May 2000, Autarch wrote:
C seems like serious overkill for something to simply
generate plain text output. How slow is making a string
in perl compared to doing it in C? I can't imagine
there's to much of a difference.
pretty slow if you build a
On Thu, 18 May 2000, Drew Taylor wrote:
What do you define the difference to be between #1 and
#2? All I need is sticky forms - primarily the
popup_menu(). If HTML widgets are b(), td(), etc, then
we didn't plan on creating those. Forms is the main
point of this module.
well the function
On Thu, 18 May 2000, brian moseley wrote:
i suggest that instead of subclassing Apache::Request, you
write the following set of classes:
1) html widget class
2) sticky forms class - use html widget class, take $r or $q
as param
3) "wrapper" class - gives you the CGI.pm interface, uses
INTERNET DEVELOPER
If you like the idea of working with unique, talented people and wearing
jeans and a t-shirt to work, you're just the person we're looking for.
Origin is a long-standing leader in the PC-gaming industry, and an acclaimed
pioneer in the online gaming genre. We create Virtual
Is this the proper forum for this posting?
"Graf, Chris" wrote:
INTERNET DEVELOPER
If you like the idea of working with unique, talented people and wearing
jeans and a t-shirt to work, you're just the person we're looking for.
Origin is a long-standing leader in the PC-gaming industry,
Yes it is. Doug has always encouraged mod_perl related jobs to be posted to
this list.
On 18-May-2000 Buddy Lee Haystack wrote:
Is this the proper forum for this posting?
"Graf, Chris" wrote:
INTERNET DEVELOPER
If you like the idea of working with unique, talented people and wearing
This was the default posting from HR. I should have thrown in the mod_perl
requirement when sending to this list. All of our Perl is mod_perl, but HR
didn't want to scare anyone away who might have been a good Perl programmer,
but had never used mod_perl before (if it's possible to be good
All,
Sorry if this question sounds stupid.. but I am new to mod_perl and
Apache::DBI.. I have successfully installed Apache Server 1.3.12 and
mod_perl 1.24 and Apache::DBI 0.87 on Solaris 2.7.
And I have tested all successfully... But confusion arised when I
created a startup.pl file and tried
-Original Message-
From: Graf, Chris [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 1:09 PM
To: [EMAIL PROTECTED]
Subject: RE: Want to work at a Game company?
This was the default posting from HR. I should have thrown
in the mod_perl
requirement when sending to this
Hi,
We're looking for people interested in developing and running fantasy
sports and videogame websites using mod_perl, HTML::Mason, MySQL, Linux.
We developed this season's official UEFA Champions League game
(http://www.uefagames.com), which had over 80,000 players, and have a
lot of cool work
I don't think an apology is in order. According to Jason's reply, you did the right
thing!
IMHO, it would be really nice if there were a separate list [or website] tailored for
mod_perl job opportunities. I know that I would subscribe / visit. ;-)
Have a GREAT day!
"Graf, Chris" wrote:
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Autarch wrote:
C seems like serious overkill for something to simply
generate plain text output. How slow is making a string
in perl compared to doing it in C? I can't imagine
there's to much of a difference.
pretty
-Original Message-
From: Niral Trivedi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 1:11 PM
To: '[EMAIL PROTECTED]'
Subject: Confusion on Apache::DBI
All,
Sorry if this question sounds stupid.. but I am new to mod_perl and
Apache::DBI.. I have successfully
-Original Message-
From: Buddy Lee Haystack [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 1:23 PM
To: Graf, Chris
Cc: [EMAIL PROTECTED]
Subject: Re: Want to work at a Game company?
I don't think an apology is in order. According to Jason's
reply, you did the right
Autarch wrote:
I really don't think we need yet another module doing what CGI does. The
people who've worked on the new version have done a very good job of
addressing the memory and speed concerns people had about the current
monolothic version. I think its much better to extend their
legitimate job offers from a reputable company are never spam.
--
___cliff [EMAIL PROTECTED]
"Graf, Chris" wrote:
This was the default posting from HR. I should have thrown in the mod_perl
requirement when sending to this list. All of our Perl is mod_perl, but HR
didn't want to scare
hi,
Sitting here trying to get 1.24 to compile with VC6,
but keep getting stuck with the following linking error;
mod_perl.obj : error LNK2001: unresolved external symbol _ap_configtestonly
the symbol responsible for the error is in a condition at mod_perl.c line 738.
-- mod_perl.c
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
.= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
I've been using Apache::AuthDBI (and earlier, Apache::AuthenDBI) for a
while, but never before have I used groups.
I recently started trying to use groups, and with Apache::AuthDBI::DEBUG
set to 2, I can get something like this in my error_log...
22310 Apache::AuthDBI::authz request type =
Sitting here trying to get 1.24 to compile with VC6,
but keep getting stuck with the following linking error;
mod_perl.obj : error LNK2001: unresolved external symbol
_ap_configtestonly
the symbol responsible for the error is in a condition at mod_perl.c line
738.
--
mod_perl.c
We're upgrading from an NCSA only server to DigiCerts using Apache
w/modperl modssl. We have *lots* of scripts in various languages
expecting the company-specific ID code in REMOTE_USER, so I'm hacking
it in with Perl*Handlers.
Is there a way (such as with $c-user) to get the *browser* to
Thanks Geoff,
You were right... I was using "DBI:mysql:DBNAME::localhost" as connect
string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl
script.. I have changed that and it worked...
Now, another question.. As we agreed, we can have as many db handle
available as server processes
-Original Message-
From: Niral Trivedi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 3:15 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: Confusion on Apache::DBI
Thanks Geoff,
You were right... I was using "DBI:mysql:DBNAME::localhost" as connect
-Original Message-
From: Niral Trivedi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 3:57 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: Re: Confusion on Apache::DBI
Geoff,
I know, once child dies, db handle goes out of scope and DBI cleans up
the
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if you reply to me in person, make
sure you keep Randy CC'ed -- all the kudos should go his
On Thu, 18 May 2000, Buddy Lee Haystack wrote:
I don't think an apology is in order. According to Jason's reply, you did the right
thing!
IMHO, it would be really nice if there were a separate list [or website] tailored
for mod_perl job opportunities. I know that I would subscribe / visit.
On Fri, 19 May 2000, Stas Bekman wrote:
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if you reply to me in person, make
sure you
On Fri, 19 May 2000, Stas Bekman wrote:
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if you reply to me in person, make
sure you
On Thu, 18 May 2000, Niral Trivedi wrote:
Now, with Apache::DBI, we'll have one DBI handle per child process
during the server startup. Now, let's say one child has started its
processing and hasn't served any request yet. Now, first request comes
in and it will look for DB handle, which is
On Thu, 18 May 2000, Matt Sergeant wrote:
Looks cool, except can we take the guide splitting back 1 level? It
seems to be split on =head2's, and should be split (IMO) on =head1's.
The reason for splitting on any =head level lies in fact that there are
huge sections under =head1 which have
I understood now...
Thank you all for your responses..
Niral
Perrin Harkins wrote:
On Thu, 18 May 2000, Niral Trivedi wrote:
Now, with Apache::DBI, we'll have one DBI handle per child process
during the server startup. Now, let's say one child has started its
processing and hasn't
On Fri, 19 May 2000, Stas Bekman wrote:
On Thu, 18 May 2000, Matt Sergeant wrote:
One more point... The indexer or the searcher (or both) has a broken
tokenizer for anything involving perl. Try searching for
Apache::Constants, for example.
That's right. It's broken :( After searching
Stas Bekman [EMAIL PROTECTED] wrote:
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if you reply to me in person, make
sure you
At 09:14 AM 5/18/00 -0700, Paul wrote:
We're upgrading from an NCSA only server to DigiCerts using Apache
w/modperl modssl. We have *lots* of scripts in various languages
expecting the company-specific ID code in REMOTE_USER, so I'm hacking
it in with Perl*Handlers.
Is there a way (such as with
At 10:53 AM 5/18/00 -0700, brian moseley wrote:
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
.= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
You
On Thu, 18 May 2000, Jeremy Howard wrote:
Stas Bekman [EMAIL PROTECTED] wrote:
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if
Well, that subject line looks a bit odd, doesn't it? What I mean is that with Perl
5.6.0, Apache::DB is broken, because it doesn't break... Er, that is, you can add
breakpoints, but Apache::DB never actually breaks on them.
Is anyone else having this problem? Is there a new version in the
At 19:26 09/05/00 -0700, Tom Mornini wrote:
On Tue, 9 May 2000, Tobias Hoellrich wrote:
and what happens when somebody bookmarks a URL with the session-id
prepended and comes back a week later with an invalid session-id in the
URL?
They get a screen that asks them to fix their bookmark, and
Well, that subject line looks a bit odd, doesn't it? What I mean is that
with Perl 5.6.0, Apache::DB is broken, because it doesn't break... Er,
that is, you can add breakpoints, but Apache::DB never actually breaks on
them.
Is anyone else having this problem? Is there a new version in
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')' as well as 'my $form =
62 matches
Mail list logo
