Background Running: current stable of mp2 and libapreq-devel
Problem:
I'm allowing GET style urls to forms for pre-population
If the POST action is dirty though, i get cross contamination of
vars IF there was a NULL action in the form
ie:
url:
[EMAIL PROTECTED]&su
typo. i'm not in good typing mode today - i strained something in my
neck, and have having trouble motivating myself to work, much less
perform correctly.
thanks for the note.
On Oct 31, 2005, at 6:18 PM, Philip M. Gollucci wrote:
I assume this is a typo, but that should be method="POST"
On Oct 31, 2005, at 6:29 PM, Joe Schaefer wrote:
pulling POST or GET data for a given fieldname
In place of param(), use the body() or args() methods, respectively.
Simple and stupid enough. Many thanks!
Jonathan <[EMAIL PROTECTED]> writes:
> but, can i hope (can i? seriously.) that there is some mechanism in
> mp2/libapreq that will let me explcitly choose whether param is
> pulling POST or GET data for a given fieldname
In place of param(), use the body() or args() methods, respectively.
-
Jonathan wrote:
{form action="" method=POST"}
I assume this is a typo, but that should be method="POST"
just to state the obvious. ^
--
END
What doesn't kill us can only make us stronger.
Background Running: current stable of mp2 and libapreq-devel
Problem:
I'm allowing GET style urls to forms for pre-population
If the POST action is dirty though, i get cross contamination of
vars IF there was a NULL action in the form
ie:
url:
[EMAIL PROTECTED]&s
Boysenberry Payne <[EMAIL PROTECTED]> wrote:
> I would like to do the "make uninstall" approach below first before
> going
> through reinstalling perl and MP2.
> Before I do this I want to make sure I have the right syntax first.
> would I just type 'make uninstall' in the source directory for MP2
I still have the original source.
But I think the reason this is happening is because I used
Darwin Port (a Darwin package installer) to install my original MP 2.
Then, when I installed MP2 RC5 from source I started getting the error.
I used the port uninstall the package first, but maybe it didn
On Mon, 2005-10-31 at 13:51 -0800, Tyler MacDonald wrote:
> "make uninstall" / ExtUtils::Install::uninstall(/path/to/.packlist)
> aren't official? I suppose you'd have to have the old pacakage's source tree
> still laying around...
Sure, if you have the .packlist for the old module, give tha
On Mon, 2005-10-31 at 15:01 -0600, Boysenberry Payne wrote:
> If it is "some old junk" left in the @INC how would I go about
> correcting it?
My approach would be to start with a new Perl install and a new
mod_perl. There is no official way to uninstall a Perl module, so it's
hard to be sure tha
Perrin Harkins wrote:
It seems
likely that you are either running a different version of Reload than
you think you are, or else have some old junk left in your @INC from a
previous installation of mod_perl.
Thats what I thought. Though there was a change relating to this in
2.0.2-dev now 2.0.2.
Actually someone sent me an off list message saying they had the same
problem after installing
the latest MP upgrade.
If it is "some old junk" left in the @INC how would I go about
correcting it?
If I'm not mistaken Apache2::Reload is a part of the MP2 install, so I
can't
just reinstall Apache
On Mon, 2005-10-31 at 14:44 -0600, Boysenberry Payne wrote:
> Should I just edit out the line in Apache2::Reload that checks for MP2?
The fact that you're having this problem and no one else is reporting it
probably means that something is wrong with your system, not with
Apache2::Reload. If poss
Should I just edit out the line in Apache2::Reload that checks for MP2?
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Oct 29, 2005, at 5:01 AM, Boysenberry Payne wrote:
I still haven't been able to get Apache2::Reload working after my MP
2.0.0 RC5
upgrade. I even tried
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > http://search.cpan.org/~CRAKRJACK/ModPerl-PackageRegistry-0.01/
> See also, Apache::Dispatch. Not ported to mp2 yet, I think.
Nice. :-) Geoffrey is using a slightly different model than me
(having multiple pages inside one class, different
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> That's pretty strange. I've only seen errors like this before once, and
> that was on a Win32 system running ActiveState's PerlEX on IIS. At the
> time, I thought it might be a threading issue. Are you using a threaded
> MPM? I see that your Perl was
On Mon, 2005-10-31 at 12:01 -0800, Tyler MacDonald wrote:
> The problem is with compiling code after the apache server has
> already started (ModPerl::Registry, maybe eval qq{} as well, not sure); if I
> compile everything during the startup phase, everything's happy.
That's pretty strange.
On Mon, 2005-10-31 at 11:57 -0800, Tyler MacDonald wrote:
> What a fun problem to solve. Instead of banging my head against the
> wall trying to get things to compile at runtime, I stopped using
> ModPerl::Registry entirely and switched to defining my own pacakges with
> handlers. Problem sol
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Well, we know there's nothing wrong with HTTP::Request on CPAN, so
> either you have a messed up copy of it there (no idea why this would
> happen), or something is wrong with your system at a pretty low level.
> Possible problems include compiling mod_pe
What a fun problem to solve. Instead of banging my head against the
wall trying to get things to compile at runtime, I stopped using
ModPerl::Registry entirely and switched to defining my own pacakges with
handlers. Problem solved. Of course, how do I map these things to URLs now?
I ended u
Balázs Szabó (dLux) wrote:
Hi,
I am the author of the Class::Date module, which can be found in CPAN,
and i had a complaint about timezone handling in perl.
I tried to debug it, and I have found that mod_perl uses the TZ
environment somehow differently.
What I did in my module is the following
Balázs Szabó (dLux) wrote:
Hi,
Hello,
I am the author of the Class::Date module, which can be found in CPAN,
and i had a complaint about timezone handling in perl.
I tried to debug it, and I have found that mod_perl uses the TZ
environment somehow differently.
What I did in my module is
Hi,
I am the author of the Class::Date module, which can be found in CPAN,
and i had a complaint about timezone handling in perl.
I tried to debug it, and I have found that mod_perl uses the TZ
environment somehow differently.
What I did in my module is the following:
delete $ENV{TZ};
tzset();
Tyler MacDonald wrote:
> Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>>>Disregard, I just searched the archives and apparently just before I
>>>subscribed to the list Phillippe announced the 'testcover' parameter...
>>>which is documented in Apache::TestMB, but not yet in Apache::TestMM :-/
>>
>
On Thu, 2005-10-27 at 15:10 -0700, Tyler MacDonald wrote:
> Today, I'm getting registry errors on my friend's virtual host using
> ModPerl::Registry on mod_perl 2.0.2:
>
> [Thu Oct 27 14:59:44 2005] [error] Global symbol "$class" requires explicit
> package name at /usr/share/perl5/HTTP/Request.pm
25 matches
Mail list logo
