RE: CGI Forms Problems (Getting Old Params)
It's CGI.pm
It caches your variables for your convenience/headaches.
Try this...
my $cgi = new CGI();
$cgi-textfield(-override=1,-name=namen,-value=priceless);
-Original Message-
From: Shannon Appelcline [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 28, 2002 3:03 PM
To: [EMAIL PROTECTED]
Subject: CGI Forms Problems (Getting Old Params)
Yesterday I ported a few thousand lines of code I'd been working on
over to Perl. It was quite a bit of work getting all of the strict
stuff correct and then fighting with the modules-do-not-reload
problem, but it's now mostly dealt with, and my code's much cleaner
and more modularized. (Huzzah.)
Unfortunately I've been continuing to have one program that I can't
figure out. Somehow, my information being submitted through forms
sometimes reverts to old data after I've clicked Submit and before
it's processed.
Now, I've read through much of the mod_perl documents, FAQs, etc.,
and I understand the general shape of *why* this happens. It's the
result of mod_perl keeping the perl modules, and thus the variables,
in memory. When I hit a server that's already been loaded, I get
incorrect results. What I don't understand is *how* it's happening in
this specific case, because I'm being very careful about clearly
setting my variables each time through.
There must be some aspect of how mod_perl works that I'm missing. I'm
hoping someone here can (1) tell me what I'm doing wrong in this
specific case and (2) tell me where my mental map is incorrect.
Anyway, here we go.
I start off with a simple index.cgi that I've made extremely short to
avoid the issue of nested subroutines. It has a require:
--
$main::filePath = /var/www/skotos/myskotos;
require ${main::filePath}/modules/lib/mylib.pm;
--
From that required library, I set my $cgi variable:
--
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
$mylib::cgi = new CGI;
--
It's a global variable, but that seems entirely appropriate for
something that's used in nearly every function. And, it gets
explicitly set every time the program is run.
Back in the original index.cgi, I have the problems when it's called
to process form information. Here's that particular segment of code:
--
require ${main::filePath}/modules/web/myedit.pm;
my $action = $mylib::cgi-param('action');
$main::pageNumber = $mylib::cgi-param('pageNumber');
$main::contentType = $mylib::cgi-param('contentType');
if ($action eq editpage) {
myedit::ProcessEditPage();
} elsif ($action eq editcontent) {
myedit::ProcessEditContent();
}
--
And, pretty much ANY of those parameters that I call in from $cgi can
come up wrong. Both the local variables defined by my ($action) and
the global variables set to $main ($pageNumber, $contentType) ...
which tells me that the problem is back in that $cgi reference.
But why?
Can I not set variables which might change down in modules? That
would seem grossly limiting if so, given that I've moved everything
to modules in order to avoid the nested subroutine problems.
Or am I missing something else?
I should mention, that out of extreme paranoia at this point I'm even
trying to undef $cgi when I'm done, to no effect.
--
END {
$mylib::dbh-disconnect if $mylib::dbh;
undef $mylib::cgi;
}
--
Help?
Shannon
--
Shannon
--
You met me at a very strange time in my life. --_Fight Club_
--
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
Re: CGI Forms Problems (Getting Old Params)
On Sat, 28 Sep 2002, Shannon Appelcline wrote:
[snip]
I start off with a simple index.cgi that I've made extremely short to
avoid the issue of nested subroutines. It has a require:
--
$main::filePath = /var/www/skotos/myskotos;
require ${main::filePath}/modules/lib/mylib.pm;
Shannon,
I'll make some suggestions about style that might help solve your
problems. First off, I wouldn't recommend explicitly including
package names with your variables ($main::foo, $bar::baz, etc.).
You mentioned getting things to work with strict, but the above does
not use my for $filePath, which leads me to believe you might be
declaring this as a global. And while your require is technically
fine, why not just set a use lib line for your custom library path
and then use your module? (Your library path doesn't need to be
variable, does it? Will this change dynamically at run-time?) I'd
recommend changing the above to:
use lib '/var/www/skotos/myskotos';
my $filePath = /var/www/skotos/myskotos;
use mylib;
From that required library, I set my $cgi variable:
--
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
$mylib::cgi = new CGI;
--
It's a global variable, but that seems entirely appropriate for
something that's used in nearly every function. And, it gets
explicitly set every time the program is run.
But this isn't a good way to set a global. Either use use vars or
our (depending on your version of Perl). And, stylistically, I
prefer to make globals and constants stand out with all-caps:
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
use vars '$CGI';
$CGI = CGI-new;
I don't necessarily agree with making this a global, though. I don't
use CGI (I usually use the faster and mod_perl-appropriate
Apache::Request), so I'd read up on the docs to see if making this a
persistent global isn't causing some of your headaches. Would it be
that bad to just have that be redeclared every time with a my?
Back in the original index.cgi, I have the problems when it's called
to process form information. Here's that particular segment of code:
--
require ${main::filePath}/modules/web/myedit.pm;
my $action = $mylib::cgi-param('action');
$main::pageNumber = $mylib::cgi-param('pageNumber');
$main::contentType = $mylib::cgi-param('contentType');
if ($action eq editpage) {
myedit::ProcessEditPage();
} elsif ($action eq editcontent) {
myedit::ProcessEditContent();
}
--
And, pretty much ANY of those parameters that I call in from $cgi can
come up wrong. Both the local variables defined by my ($action) and
the global variables set to $main ($pageNumber, $contentType) ...
which tells me that the problem is back in that $cgi reference.
But why?
Can I not set variables which might change down in modules? That
would seem grossly limiting if so, given that I've moved everything
to modules in order to avoid the nested subroutine problems.
Or am I missing something else?
I'm still on the style issue of explicitly manipulating another
package's variables. It really seems like you want to make those
extra modules of yours into real objects, and then call methods
against them:
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
sub new {
my $class = shift;
my $self = bless { cgi = CGI-new }, $class;
return $self;
}
sub cgi {
return shift-{'cgi'};
}
1;
---
use lib '/var/www/skotos/myskotos/modules/web/';
use myedit;
use mylib;
my $lib = mylib-new or die 'No mylib object';
my $edit= myedit-newor die 'No edit object';
my $cgi = $lib-cgi or die 'No CGI object';
my $action = $cgi-param('action') ||'editpage';
my $pageNumber = $cgi-param('pageNumber') || 0;
my $contentType = $cgi-param('contentType') || 'text/html';
if ( $action eq 'editpage' ) {
$edit-ProcessEditPage( $cgi );
}
elsif ( $action eq 'editcontent' ) {
myedit-ProcessEditContent( $cgi );
}
Of course, you should be writing code a lot more bullet-proof than the
above (what's going to catch the die, what happens in mylib if
CGI-new fails, taint checking, etc.). My guess is that in your
myedit package, you were explicitly referencing $mylib::cgi
because I see you weren't passing it (as I made sure to above).
Again, I differ with you on style, but I think this is part of your
problem.
I should mention, that out of extreme paranoia at this point I'm even
trying to undef $cgi when I'm done, to no effect.
--
END {
$mylib::dbh-disconnect if $mylib::dbh;
undef $mylib::cgi;
}
I don't think undefing your CGI object is the problem. I think it
probably never gets created anew as you expect it would. You've
declared it as a
CGI Forms Problems (Getting Old Params)
Yesterday I ported a few thousand lines of code I'd been working on
over to Perl. It was quite a bit of work getting all of the strict
stuff correct and then fighting with the modules-do-not-reload
problem, but it's now mostly dealt with, and my code's much cleaner
and more modularized. (Huzzah.)
Unfortunately I've been continuing to have one program that I can't
figure out. Somehow, my information being submitted through forms
sometimes reverts to old data after I've clicked Submit and before
it's processed.
Now, I've read through much of the mod_perl documents, FAQs, etc.,
and I understand the general shape of *why* this happens. It's the
result of mod_perl keeping the perl modules, and thus the variables,
in memory. When I hit a server that's already been loaded, I get
incorrect results. What I don't understand is *how* it's happening in
this specific case, because I'm being very careful about clearly
setting my variables each time through.
There must be some aspect of how mod_perl works that I'm missing. I'm
hoping someone here can (1) tell me what I'm doing wrong in this
specific case and (2) tell me where my mental map is incorrect.
Anyway, here we go.
I start off with a simple index.cgi that I've made extremely short to
avoid the issue of nested subroutines. It has a require:
--
$main::filePath = /var/www/skotos/myskotos;
require ${main::filePath}/modules/lib/mylib.pm;
--
From that required library, I set my $cgi variable:
--
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
$mylib::cgi = new CGI;
--
It's a global variable, but that seems entirely appropriate for
something that's used in nearly every function. And, it gets
explicitly set every time the program is run.
Back in the original index.cgi, I have the problems when it's called
to process form information. Here's that particular segment of code:
--
require ${main::filePath}/modules/web/myedit.pm;
my $action = $mylib::cgi-param('action');
$main::pageNumber = $mylib::cgi-param('pageNumber');
$main::contentType = $mylib::cgi-param('contentType');
if ($action eq editpage) {
myedit::ProcessEditPage();
} elsif ($action eq editcontent) {
myedit::ProcessEditContent();
}
--
And, pretty much ANY of those parameters that I call in from $cgi can
come up wrong. Both the local variables defined by my ($action) and
the global variables set to $main ($pageNumber, $contentType) ...
which tells me that the problem is back in that $cgi reference.
But why?
Can I not set variables which might change down in modules? That
would seem grossly limiting if so, given that I've moved everything
to modules in order to avoid the nested subroutine problems.
Or am I missing something else?
I should mention, that out of extreme paranoia at this point I'm even
trying to undef $cgi when I'm done, to no effect.
--
END {
$mylib::dbh-disconnect if $mylib::dbh;
undef $mylib::cgi;
}
--
Help?
Shannon
--
Shannon
--
You met me at a very strange time in my life. --_Fight Club_
