Re: passing CGI paramters
Hi, There's no need to post your question four times. I'm trying to bring my application up using ModPerl::PerlRun. I have anchors at places in my code like I can't tell what you're doing from this description. Can you show us some of your code? Additionally, if I execute the same anchor twice in a row, changing the data the paramters are composed from between the 2 executions, the paramters do not change on the second execution under PerlRun but do under CGI. It sounds like your code has a scoping bug, probably an unintentional closure. Can you show us the code where you get the CGI parameters? - Perrin
Re: passing CGI paramters
Perrin, Thanks for responding. I'm not sure why it posted four times. I'm new here. I posted the original request Sunday morning I think.I didn't get any responses, so early this morning I registered as 'cliff' with perl monks and made a similiar request. Clinton responded and worked with me for about an hour in the chatterbox. I put a lot of stuff in my (cliff) scratchpad like the ENV values, the relevant Apache httpd entries, a dump, the Apache error log, and code examples. Would it be possible for you to review the stuff I put there? Clinton didn't spot anything. But the MOD_PERL ENV variable is not getting set and this variable controls the release of globals in the beginning of CGI.pm. I don't know how this variable gets established, but I think its an important clue. My environment is Windows XP Home/Apache 2/Perl 5.8/mod_perl 2. I can execute my application under PerlRun (perl-run). It executes. But when I click on anchors that pass CGI paramters using the same ?str variable to pass the paramters, the parameter values passed in ?str when I execute the first anchor (regardless of which one I execute first) persist. These values get passed to subsequent anchor executions passing the paramters values in ?str. The initial value of ?str persists until I recycle the server. The application does execute and operate correctly under CGI. The 2 URLs for these execution environments are: http://steepusa.no-ip.info/cgi-bin/m3.cgi http://steepusa.no-ip.info/perl-run/m3.cgi I use strict everywhere and all Perl variables are declared with my. I have verified that the values of the varaiables I assign to ?str in the anchors are correct in all anchor executions. Thanks again Perrin. I appreciate any help. CraigT (or Cliff in Perl Monks) Perrin Harkins wrote: > > Hi, > > There's no need to post your question four times. > >> I'm trying to bring my application up using ModPerl::PerlRun. I have >> anchors at places in my code like >> HREF='vumenu.cgi?str=$govlevel~$vufiles' where I'm passing parameters to >> the HREF. I use the ?str part of HREF in other anchor invocations. >> However the first anchor execution ?str definition persists so that the >> next >> anchor executed using ?str has the ?str defintion of the first anchor >> executed. I'm guessing that str is a global and persists. > > I can't tell what you're doing from this description. Can you show us > some of your code? > >> Additionally, if I execute the same anchor twice in a >> row, changing the data the paramters are composed from between the 2 >> executions, the paramters do not change on the second execution under >> PerlRun but do under CGI. > > It sounds like your code has a scoping bug, probably an unintentional > closure. Can you show us the code where you get the CGI parameters? > > - Perrin > > -- View this message in context: http://www.nabble.com/passing-CGI-paramters-tf4008753.html#a11416640 Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: passing CGI paramters
On 7/3/07, CraigT <[EMAIL PROTECTED]> wrote:
I put a lot of stuff in my (cliff) scratchpad like the ENV values, the
relevant Apache httpd entries, a dump, the Apache error log, and code
examples. Would it be possible for you to review the stuff I put there?
Maybe later. Do you have a link for it?
Clinton didn't spot anything. But the MOD_PERL ENV variable is not getting
set and this variable controls the release of globals in the beginning of
CGI.pm. I don't know how this variable gets established, but I think its
an important clue.
If $ENV{'MOD_PERL'} is empty, you are running under CGI, not mod_perl.
Maybe you have a typo in your code that checks it?
- Perrin
Re: passing CGI paramters
[Please keep it on the list]
On 7/3/07, Craig Tussey <[EMAIL PROTECTED]> wrote:
Thanks again for responding. Here is the link to my
scratchpad. Keep in mind that I was making entries
to the scratchpad in response to Clintons questions.
http://www.perlmonks.org/?viewmode=public;node_id=624649
Okay, you really aren't showing much code here. From what you did
show, I'm guessing you're doing this:
my $govlevel = $page->param("str");
print_html();
sub print_html {
print "blah blah $govlevel blah blah";
}
That doesn't work because the sub becomes a closure and never notices
when you create new versions of $govlevel. The fix is to pass
$govlevel to the sub as a parameter.
- Perrin
Re: passing CGI paramters
Perrin,
I'm not sure I'm communicating very well. And I'm not sure I understand what
you said. Let me outline what I'm experiencing again. I have a page with
multiple anchors.I saw this problem immediately with 3 of these anchors
when I invoked the page under perl-run (PerlRun). The 3 anchors follow.
I've left the off on purpose so the anchor will show.
CLASS='zzz tn' HREF='dashboard.cgi?str=$govlevel:3'
ONMOUSEOVER=\"window.status='$glines[2] Key Indicators';return true\"
ONMOUSEOUT=\"window.status=' ';return true\">DashboardSights/SoundsSpecial Viewsparam("str") assigning the paramter values to a declared Perl
variable. And I do use strict everywhere. I then work with those
paramters in the module invoked by the anchor. But the issue isn't about
working with what gets passed into the module invoked by the anchor. I
don't get that far. The problem is that what is coming across from the
invoking module to the invoked module is incorrect.
Notice that the paramters being passed to each of the 3 different physical
modules are passed after being assigned to the variable 'str'. If I execute
any of the 3 anchors first, setting and passing 'str', and then invoke any
of the other 2 anchors, the value of 'str' set in the first invocation
persists such that the invocation of the other 2 anchors has the 'str'
values from the first invocation. The value of 'str' will not change after
that first anchor execution until I recycle the server. The first anchor I
executed keeps working and the other 2 keep getting passed the 'str' values
from the first anchor execution and don't work.
Also, I changed the name of 'str' to something unique in each of the 3
anchors and anchor modules. When I do this, regardless of which one I
execute first, the first one works and then the other 2 pass nothing. And
again, it works fine under CGI.
This code has worked correctly under CGI ever since it was written. I've
verified that under the perl-run execution the Perl variables assigned to
'str' in all 3 anchors have the correct values before I execute the anchors.
And I've verified the values in 'str' that come across when I invoke the
anchors right after the $somevar = $page->param("str") line in each of the
physical modules. Regardless of which of these anchors I invoke first,
invoking either of the remaining 2 anchors results in the values of 'str'
set in the 1st anchor executed being passed to the modules that the
remaining 2 anchors execute.
Also, the ENV variables I had in my scratchpad where mistakenly executed
under CGI. When I printed the ENV stuff executed under perl-run (PerlRun),
MOD_PERL is there. You can see the perl-run ENV stuff by invoking the
following URL.
http://steepusa.no-ip.info/perl-run/stuff/prtenv.cgi
I would like to understand better the 'no longer shared' message in the
error log.
I hope this is clearer. I am sort of at a loss here. I live in a small
rural town in the foothills of the Appalachian Mountains and I have found no
community here to bounce these kinds of things off of.
I've dealt with a lot of bugs over the years in a variety of languages and
this one seems strange. Can you make any suggestions on how I might proceed
here. The Apache 'ab' modules tells me I can improve the # of request per
second that my server can server by a facor of 3 and I would like to do it
if I can.
CraigT
Perrin Harkins wrote:
>
> [Please keep it on the list]
>
> On 7/3/07, Craig Tussey <[EMAIL PROTECTED]> wrote:
>> Thanks again for responding. Here is the link to my
>> scratchpad. Keep in mind that I was making entries
>> to the scratchpad in response to Clintons questions.
>>
>> http://www.perlmonks.org/?viewmode=public;node_id=624649
>
> Okay, you really aren't showing much code here. From what you did
> show, I'm guessing you're doing this:
>
> my $govlevel = $page->param("str");
> print_html();
>
> sub print_html {
> print "blah blah $govlevel blah blah";
> }
>
> That doesn't work because the sub becomes a closure and never notices
> when you create new versions of $govlevel. The fix is to pass
> $govlevel to the sub as a parameter.
>
> - Perrin
>
>
--
View this message in context:
http://www.nabble.com/passing-CGI-paramters-tf4008753.html#a11432833
Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: passing CGI paramters
Have a look at this:
http://www.perl.com/pub/a/2002/05/07/mod_perl.html
Perrin is probably right that it's a closure issue. Take a good look at
your code.
Incidentally, I've found it useful to do a Google search on
incomprehensible error messages ..:)
d
CraigT wrote:
Perrin,
I'm not sure I'm communicating very well. And I'm not sure I understand what
you said. Let me outline what I'm experiencing again. I have a page with
multiple anchors.I saw this problem immediately with 3 of these anchors
when I invoked the page under perl-run (PerlRun). The 3 anchors follow.
I've left the off on purpose so the anchor will show.
CLASS='zzz tn' HREF='dashboard.cgi?str=$govlevel:3'
ONMOUSEOVER=\"window.status='$glines[2] Key Indicators';return true\"
ONMOUSEOUT=\"window.status=' ';return true\">Dashboard
values passed = $govlevel:3 = SKY:3
CLASS='l2' HREF='ss.cgi?str=$govlevel' ONMOUSEOVER=\"window.status='Sights
And Sounds Of $glines[0]';return true\" ONMOUSEOUT=\"window.status='
';return true\">Sights/Sounds
values passed = $govlevel = SKY
CLASS='l2' HREF='vumenu.cgi?str=$govlevel~$vufiles'
ONMOUSEOVER=\"window.status='Special Interest, Measure Views';return true\"
ONMOUSEOUT=\"window.status=' ';return true\">Special Viewsparam("str") assigning the paramter values to a declared Perl
variable. And I do use strict everywhere. I then work with those
paramters in the module invoked by the anchor. But the issue isn't about
working with what gets passed into the module invoked by the anchor. I
don't get that far. The problem is that what is coming across from the
invoking module to the invoked module is incorrect.
Notice that the paramters being passed to each of the 3 different physical
modules are passed after being assigned to the variable 'str'. If I execute
any of the 3 anchors first, setting and passing 'str', and then invoke any
of the other 2 anchors, the value of 'str' set in the first invocation
persists such that the invocation of the other 2 anchors has the 'str'
values from the first invocation. The value of 'str' will not change after
that first anchor execution until I recycle the server. The first anchor I
executed keeps working and the other 2 keep getting passed the 'str' values
from the first anchor execution and don't work.
Also, I changed the name of 'str' to something unique in each of the 3
anchors and anchor modules. When I do this, regardless of which one I
execute first, the first one works and then the other 2 pass nothing. And
again, it works fine under CGI.
This code has worked correctly under CGI ever since it was written. I've
verified that under the perl-run execution the Perl variables assigned to
'str' in all 3 anchors have the correct values before I execute the anchors.
And I've verified the values in 'str' that come across when I invoke the
anchors right after the $somevar = $page->param("str") line in each of the
physical modules. Regardless of which of these anchors I invoke first,
invoking either of the remaining 2 anchors results in the values of 'str'
set in the 1st anchor executed being passed to the modules that the
remaining 2 anchors execute.
Also, the ENV variables I had in my scratchpad where mistakenly executed
under CGI. When I printed the ENV stuff executed under perl-run (PerlRun),
MOD_PERL is there. You can see the perl-run ENV stuff by invoking the
following URL.
http://steepusa.no-ip.info/perl-run/stuff/prtenv.cgi
I would like to understand better the 'no longer shared' message in the
error log.
I hope this is clearer. I am sort of at a loss here. I live in a small
rural town in the foothills of the Appalachian Mountains and I have found no
community here to bounce these kinds of things off of.
I've dealt with a lot of bugs over the years in a variety of languages and
this one seems strange. Can you make any suggestions on how I might proceed
here. The Apache 'ab' modules tells me I can improve the # of request per
second that my server can server by a facor of 3 and I would like to do it
if I can.
CraigT
Perrin Harkins wrote:
[Please keep it on the list]
On 7/3/07, Craig Tussey <[EMAIL PROTECTED]> wrote:
Thanks again for responding. Here is the link to my
scratchpad. Keep in mind that I was making entries
to the scratchpad in response to Clintons questions.
http://www.perlmonks.org/?viewmode=public;node_id=624649
Okay, you really aren't showing much code here. From what you did
show, I'm guessing you're doing this:
my $govlevel = $page->param("str");
print_html();
sub print_html {
print "blah blah $govlevel blah blah";
}
That doesn't work because the sub becomes a closure and never notices
when you create new versions of $govlevel. The fix is to pass
$govlevel to the sub as a parameter.
- Perrin
Re: passing CGI paramters
I'm not even getting into any subroutines in the modules that the other 2
anchors invoke after the first anchor is executed. Coming into the
modules, the 'str' values are wrong. The modules that the anchors execute
are 3 different physical modules in contrast to logical subroutines in the
same physical module. Maybe I'm just not really understanding what you all
are say to me.
CraigT
David Scott-2 wrote:
>
> Have a look at this:
>
> http://www.perl.com/pub/a/2002/05/07/mod_perl.html
>
> Perrin is probably right that it's a closure issue. Take a good look at
> your code.
>
> Incidentally, I've found it useful to do a Google search on
> incomprehensible error messages ..:)
>
> d
>
> CraigT wrote:
>> Perrin,
>>
>> I'm not sure I'm communicating very well. And I'm not sure I understand
>> what
>> you said. Let me outline what I'm experiencing again. I have a page
>> with
>> multiple anchors.I saw this problem immediately with 3 of these
>> anchors
>> when I invoked the page under perl-run (PerlRun). The 3 anchors follow.
>> I've left the off on purpose so the anchor will show.
>>
>> CLASS='zzz tn' HREF='dashboard.cgi?str=$govlevel:3'
>> ONMOUSEOVER=\"window.status='$glines[2] Key Indicators';return true\"
>> ONMOUSEOUT=\"window.status=' ';return true\">Dashboard>
>> values passed = $govlevel:3 = SKY:3
>>
>> CLASS='l2' HREF='ss.cgi?str=$govlevel'
>> ONMOUSEOVER=\"window.status='Sights
>> And Sounds Of $glines[0]';return true\" ONMOUSEOUT=\"window.status='
>> ';return true\">Sights/Sounds>
>> values passed = $govlevel = SKY
>>
>> CLASS='l2' HREF='vumenu.cgi?str=$govlevel~$vufiles'
>> ONMOUSEOVER=\"window.status='Special Interest, Measure Views';return
>> true\"
>> ONMOUSEOUT=\"window.status=' ';return true\">Special Views>
>> values passed = $govlevel~$vufiles = SKY~C:/Steep/USA
>> Data/State/KY/birth.view!C:/Steep/USA
>> Data/State/KY/children.view!C:/Steep/USA
>> Data/State/KY/children2.view!C:/Steep/USA
>> Data/State/KY/children3.view!C:/Steep/USA
>> Data/State/KY/children4.view!C:/Steep/USA
>> Data/State/KY/healthybirths.view!C:/Steep/USA
>> Data/State/KY/healthybirths2.view!C:/Steep/USA
>> Data/State/KY/infantdeaths.view!C:/Steep/USA
>> Data/State/KY/infantdeathsin3counties.view!C:/Steep/USA
>> Data/State/KY/infantsmothers.view
>>
>> In each of the modules, I bring 'str' across with something like my
>> $somevar
>> = $page->param("str") assigning the paramter values to a declared Perl
>> variable. And I do use strict everywhere. I then work with those
>> paramters in the module invoked by the anchor. But the issue isn't
>> about
>> working with what gets passed into the module invoked by the anchor. I
>> don't get that far. The problem is that what is coming across from the
>> invoking module to the invoked module is incorrect.
>>
>> Notice that the paramters being passed to each of the 3 different
>> physical
>> modules are passed after being assigned to the variable 'str'. If I
>> execute
>> any of the 3 anchors first, setting and passing 'str', and then invoke
>> any
>> of the other 2 anchors, the value of 'str' set in the first invocation
>> persists such that the invocation of the other 2 anchors has the 'str'
>> values from the first invocation. The value of 'str' will not change
>> after
>> that first anchor execution until I recycle the server. The first
>> anchor I
>> executed keeps working and the other 2 keep getting passed the 'str'
>> values
>> from the first anchor execution and don't work.
>>
>> Also, I changed the name of 'str' to something unique in each of the 3
>> anchors and anchor modules. When I do this, regardless of which one I
>> execute first, the first one works and then the other 2 pass nothing.
>> And
>> again, it works fine under CGI.
>>
>> This code has worked correctly under CGI ever since it was written.
>> I've
>> verified that under the perl-run execution the Perl variables assigned to
>> 'str' in all 3 anchors have the correct values before I execute the
>> anchors.
>> And I've verified the values in 'str' that come across when I invoke the
>> anchors right after the $somevar = $page->param("str") line in each of
>> the
>> physical modules. Regardless of which of these anchors I invoke first,
>> invoking either of the remaining 2 anchors results in the values of 'str'
>> set in the 1st anchor executed being passed to the modules that the
>> remaining 2 anchors execute.
>>
>> Also, the ENV variables I had in my scratchpad where mistakenly executed
>> under CGI. When I printed the ENV stuff executed under perl-run
>> (PerlRun),
>> MOD_PERL is there. You can see the perl-run ENV stuff by invoking the
>> following URL.
>>
>> http://steepusa.no-ip.info/perl-run/stuff/prtenv.cgi
>>
>> I would like to understand better the 'no longer shared' message in the
>> error log.
>>
>> I hope this is clearer. I am sort of at a loss here. I live in a small
>> rural town in the foothills of the Appalachian Mountains and I ha
Re: passing CGI paramters
On 7/4/07, CraigT <[EMAIL PROTECTED]> wrote:
In each of the modules, I bring 'str' across with something like my $somevar
= $page->param("str") assigning the paramter values to a declared Perl
variable.
Okay, but do you pass $page explicitly to the sub, or do you just
define it outside the sub and use it? If it's the latter, you have a
closure problem.
The problem is that what is coming across from the
invoking module to the invoked module is incorrect.
That sounds like a closure problem, where the sub can only see the
original version of $page.
the value of 'str' set in the first invocation
persists such that the invocation of the other 2 anchors has the 'str'
values from the first invocation.
That sounds like a closure problem too.
And
again, it works fine under CGI.
That sounds like a closure problem too. You never notice that your
code has a scoping bug (which is what a closure problem is) in CGI
because the process exits immediately, and the cached value never gets
used again.
Also, the ENV variables I had in my scratchpad where mistakenly executed
under CGI.
Good, then I think all the mysteries are solved.
I would like to understand better the 'no longer shared' message in the
error log.
That's a message that you get when you have closure problem. It means
the variable will be cached the first time through and never change
again.
All that you need to do to fix this problem is to pass all of the
variables that your sub needs to the sub when you call it. If you
don't understand what I mean, post one of your subs and we'll show you
how to change it.
- Perrin
Re: passing CGI paramters
Perrin,
Is what I'm hearing you say is that in the PerlRun environment (and I'm
guessing the mod_perl environment too), anything that a subroutine uses
coming from outside that code must be passed as a parameter like
'&sub($paramter)'. Am I correct in this.
Associating the words scope and closure helped. I know scope well although
different languages implement the idea differently. I had not heard the
word closure before or had not understood it as scope.
CraigT
Perrin Harkins wrote:
>
> On 7/4/07, CraigT <[EMAIL PROTECTED]> wrote:
>> In each of the modules, I bring 'str' across with something like my
>> $somevar
>> = $page->param("str") assigning the paramter values to a declared Perl
>> variable.
>
> Okay, but do you pass $page explicitly to the sub, or do you just
> define it outside the sub and use it? If it's the latter, you have a
> closure problem.
>
>> The problem is that what is coming across from the
>> invoking module to the invoked module is incorrect.
>
> That sounds like a closure problem, where the sub can only see the
> original version of $page.
>
>> the value of 'str' set in the first invocation
>> persists such that the invocation of the other 2 anchors has the 'str'
>> values from the first invocation.
>
> That sounds like a closure problem too.
>
>> And
>> again, it works fine under CGI.
>
> That sounds like a closure problem too. You never notice that your
> code has a scoping bug (which is what a closure problem is) in CGI
> because the process exits immediately, and the cached value never gets
> used again.
>
>> Also, the ENV variables I had in my scratchpad where mistakenly executed
>> under CGI.
>
> Good, then I think all the mysteries are solved.
>
>> I would like to understand better the 'no longer shared' message in the
>> error log.
>
> That's a message that you get when you have closure problem. It means
> the variable will be cached the first time through and never change
> again.
>
> All that you need to do to fix this problem is to pass all of the
> variables that your sub needs to the sub when you call it. If you
> don't understand what I mean, post one of your subs and we'll show you
> how to change it.
>
> - Perrin
>
>
--
View this message in context:
http://www.nabble.com/passing-CGI-paramters-tf4008753.html#a11448994
Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: passing CGI paramters
CraigT wrote: > Perrin, > > Is what I'm hearing you say is that in the PerlRun environment (and I'm > guessing the mod_perl environment too), anything that a subroutine uses > coming from outside that code must be passed as a parameter like > '&sub($paramter)'. Am I correct in this. Yes and no. The key to understanding this under mod_perl is that global variables and packaged scoped variables do not get reinitialized for each request like they do under normal CGI. So if you are using a global var that should retain state between requests, then no you don't need to pass it to each subroutine. But if you're not, then yes you do. And btw, you don't need the '&' in front of the the sub. sub($paramter) is the proper way to do it. > Associating the words scope and closure helped. I know scope well although > different languages implement the idea differently. I had not heard the > word closure before or had not understood it as scope. While related, they aren't the same thing. A closure is a function that "remembers" it's lexical environment when compiled. So it can reference things that were declared in the same scope as it self. http://en.wikipedia.org/wiki/Closure_%28computer_science%29 and in Perl http://www.perl.com/pub/a/2002/05/29/closure.html Depending on the other languages you know, you might never have encountered a closure before since they don't exist in languages like C, C++ or Java. -- Michael Peters Developer Plus Three, LP
Re: passing CGI paramters
A few more questions please. Am I passing the paramters in the anchor
examples I presented earlier as I should using PerlRun or mod_perl? Should
I be able to see the correct passed parameters when I pull them across to
the module invoked by the anchor prior to entering a sub in that module (my
$page = new CGI;$params = $page->param("str");)? If a subroutine needs many
parameters, how would you recommend they be passed? After simply installing
mod_perl, am I using the Apache embedded Perl interpreter or do I have to
make the transition to PerlRun or mod_perl for this to occur?
CraigT
Michael Peters wrote:
>
> CraigT wrote:
>> Perrin,
>>
>> Is what I'm hearing you say is that in the PerlRun environment (and I'm
>> guessing the mod_perl environment too), anything that a subroutine uses
>> coming from outside that code must be passed as a parameter like
>> '&sub($paramter)'. Am I correct in this.
>
> Yes and no. The key to understanding this under mod_perl is that global
> variables and packaged scoped variables do not get reinitialized for each
> request like they do under normal CGI.
>
> So if you are using a global var that should retain state between
> requests, then
> no you don't need to pass it to each subroutine. But if you're not, then
> yes you do.
>
> And btw, you don't need the '&' in front of the the sub.
>
> sub($paramter)
>
> is the proper way to do it.
>
>> Associating the words scope and closure helped. I know scope well
>> although
>> different languages implement the idea differently. I had not heard the
>> word closure before or had not understood it as scope.
>
> While related, they aren't the same thing. A closure is a function that
> "remembers" it's lexical environment when compiled. So it can reference
> things
> that were declared in the same scope as it self.
>
> http://en.wikipedia.org/wiki/Closure_%28computer_science%29
> and in Perl
> http://www.perl.com/pub/a/2002/05/29/closure.html
>
> Depending on the other languages you know, you might never have
> encountered a
> closure before since they don't exist in languages like C, C++ or Java.
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
>
--
View this message in context:
http://www.nabble.com/passing-CGI-paramters-tf4008753.html#a11465053
Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: passing CGI paramters
On 7/5/07, CraigT <[EMAIL PROTECTED]> wrote: Is what I'm hearing you say is that in the PerlRun environment (and I'm guessing the mod_perl environment too), anything that a subroutine uses coming from outside that code must be passed as a parameter like '&sub($paramter)'. Am I correct in this. Unless you are trying to create a variable that never changes, yes. This is true in all perl code, not just mod_perl. You don't notice the effect in CGI because the interpreter exits. This is a general good practice for programming -- you want subroutines to be independent and have no side effects on variables that are not passed to them. - Perrin
Re: passing CGI paramters
On 7/6/07, CraigT <[EMAIL PROTECTED]> wrote:
Am I passing the paramters in the anchor
examples I presented earlier as I should using PerlRun or mod_perl?
I don't think you ever showed us the code. You just showed the code
where you print the HTML. If you can show us a complete sub and how
you call it, we can tell you if it looks right.
Should
I be able to see the correct passed parameters when I pull them across to
the module invoked by the anchor prior to entering a sub in that module (my
$page = new CGI;$params = $page->param("str");)?
Yes, even if y ou have a scoping problem, code that is in the "main"
part of your script, outside of subs, should be able to see the
correct values.
If a subroutine needs many
parameters, how would you recommend they be passed?
Use a hash:
foo(x => 1, y => 2);
sub foo {
my %args = @_;
print $args{x}, $args{y};
After simply installing
mod_perl, am I using the Apache embedded Perl interpreter or do I have to
make the transition to PerlRun or mod_perl for this to occur?
You have to use PerlRun or some other mod_perl handler.
- Perrin
Re: passing CGI paramters
I realize that I have some redoing to do in relation to the scope/closure
stuff to make the PerlRun/mod_perl transition, and thanks to you all I have
a pretty good idea of what I have to do. In this regard though, I would
like to ask what you recommend to pass back several paramters from a sub
(question 1)?
What I would like to focus on is the problem I'm havin passing paramters
between programs (question 2). I asked before if I should be able to see
the correct passed parameters when I pull them across to the module invoked
by the anchor prior to entering a sub in that module (my > $page = new
CGI;$params = $page->param("str");)? Perrin said Yes, even if y ou have a
scoping problem, code that is in the "main" part of your script, outside of
subs, should be able to see the correct values.
But the stuff is not coming across correctly. I've verified that the stuff
I pass from m3 is correct. But if I click on the ss.cgi or vumenu.cgi
anchor 1st and then the other, the other gets passed the paramters of the
first. The 'str' variable, used to pass the paramters to both, persists
until I recycle the server. I changed the name of 'str' in the anchors and
each invoked module to make it unique for each module to see if this would
help. When I did this, the anchor I hit first worked and the second got no
paramters at all. And the code works right under CGI.
I'd like to focus on this problem here because I don't feel like I have much
control between the anchor click and the retrival of the paramters in the
invoked module.
I haven't shown the code because I'm not quite sure how.That code I
posted before was an atempt to show what I thought might be enough.The
whole modules are alot to show here. But I'll give it a 2nd try by posting
more but not all.
The first module presented is m3.cgi. I've included the code for this
module down to the anchors that execute ss.cgi and vumenu.cgi at the bottom
of what I've presented for the m3.cgi program. I've included code from the
2nd module (ss.cgi) down to where the parameters are brought across. The
code I've included for both modules is in the main portion of each. The
code for the 2 programs follows.
#Beginning of m3.cgi
#!C:/PERL/bin/perl.exe -w
# Show Model 3 (top level - 1 application installation - copy of level3i)
# Bring in resources.
use strict;
use CGI;
use Getopt::Std;
use File::Copy;
use File::Basename;
use Fcntl qw(:flock);
use Time::Local;
use MongerFile;
use Image::Size;
# Bring client data in.
my $page = new CGI;
# Data space declarations.
# Set to enable/disable totaling calculations.
my $shototltots = 1;
my $shocoltots = 1;
my $shorowtots = 1;
my $shocelltots = 1;
my $celsz = 6; # Number of efforts per cell allowed.
my $county = 0; # 1=county level implementation/0=other
my $databasedir = "C:/Steep/USA Data/"; # Base data directory.
(my $ai, my $row, my $r, my $col, my $c, my $cpos, my $blankx, my $lstr, my
$xlnklen, my $zzx, my $firstcpos) = "";
(my $idesc, my $imeas, my $cnd, my $chg, my $iline, my $xstr, my $xstr2, my
$xs, my $xs2, my $xss2, my $xss3) = "";
(my $dval, my $cmpval, my $pfn, my $pline, my $pnm, my $expd, my $itok, my
$expdem, my $xxfn1, my $xxfn2) = "";
(my $alltots, my $xlnk, my $cnum, my $hdr, my $pic, my $yr, my $mess, my
$viewflg, my $vufiles, my $iferrmsg) = "";
(my $gov, my $govcat, my $govlevel, my $exlevel, my @glines, my $gstr, my
$bogie, my $xcho, my $gotcpos1, my $dn) = "";
(my $sta, my $stri, my $inv, my $tmp, my $match, my $l, my $thedem, my
$orgidfn, my $idlfn, my $govfn, my $dn1) = "";
(my $cname, my $ctitle, my $cphone, my $cemail, my $dirx, my $oid, my
$docroot, my $servname, my $key, my $dn2) = "";
# Default colors - see custom.parms for color explanations.
my $appbgcolr = 'E6ECFF'; # Screen colors.
my $banrcolr = '809FFF';
my $ltappbgcolr = 'F8F8FF';
my $whitetext = 'FF';
my $darkbluetext = '99';
my $inputupdfieldbg = '99CCFF'; # Input/update content entry field
background.
my $anchorcolr = '99';
my $anchorhovercolr = 'FF';
my $m3boundrycellbg = '809FFF';
my $m3row1 = 'Sociocultural'; # Model 3 effort row headers.
my $m3row2 = 'Technological';
my $m3row3 = 'Economic';
my $m3row4 = 'Environmental';
my $m3row5 = 'Political';
my $m3row6 = 'Organizational'; # Optional model 3 row.
(my $sec,my $min,my $hour,my $mday,my $mon,my $year,my $wday,my $yday,my
$isdst,my $cntxx,my $capsx,my $smlsx) = 0;
(my $i, my $j, my $icnt, my $jcnt, my $celcnt, my $snum, my $dolrdem, my
$cmpdolr, my $cordolr, my $celpos) = 0;
(my $totcnd, my $totchg, my $totexp, my $cndacc, my $chgacc, my $expacc, my
$t1, my $t2, my $t3, my $padlen) = 0;
(my $wid, my $ht, my $wid1, my $ht1, my $wid2, my $ht2, my $didit) = 0;
(my $thou, my $mil, my $bil, my $tril) = (1000, 100, 10,
1);
my @caps =
('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z');
my @smls =
('a','b','c','d','e','f',
Re: passing CGI paramters
On 7/6/07, CraigT <[EMAIL PROTECTED]> wrote:
In this regard though, I would
like to ask what you recommend to pass back several paramters from a sub
The usual way to do it is to accept a list of return values:
my ($foo, $bar) = sub_call($param);
I'd like to focus on this problem here because I don't feel like I have much
control between the anchor click and the retrival of the paramters in the
invoked module.
You don't have any control of that. That's handled by the web browser
and your operating system. We just assume that part works. I don't
think the problem is there.
I haven't shown the code because I'm not quite sure how.
The best thing to do is to try to make a small example program that
shows the problem. Sometimes, just by trying to make a small example
of it, you fix the problem.
The first module presented is m3.cgi.
This code has some problems. This isn't a general Perl help mailing
list, but I'll point out a couple of quick things. I also recommend
that you buy a copy of "Perl Best Practices" and join
http://perlmonks.org/ in order to have a community of people to help
you with general Perl questions.
use strict;
Use warnings too.
(my $ai, my $row, my $r, my $col, my $c, my $cpos, my $blankx, my $lstr, my
$xlnklen, my $zzx, my $firstcpos) = "";
This kind of initialization isn't necessary. It's better to declare
your variables right before you use them, to keep the scope as small
as possible. The way you're initializing them here won't work anyway,
since you only have one empty string, and a list of variables on the
left.
# Get document root and server name.
foreach $key (sort keys(%ENV)) {
if ($key eq 'DOCUMENT_ROOT') {
$docroot = $ENV{$key};
}
if ($key eq 'SERVER_NAME') {
$servname = $ENV{$key};
}
}
That should just be
$docroot = $ENV{DOCUMENT_ROOT};
$servername = $ENV{SERVER_NAME};
open(ORG,"<$orgidfn");
flock(ORG,LOCK_SH);
@glines = ;
close(ORG);
Any time you open, flock, or close, you must check for errors with the
usual "or die" construct.
print "Content-type: text/html\n\n";
Use $page->header() instead.
print "$gov Efforts
A templating system might make this HTML easier for you to deal with.
You could start with something simple, like Text::Template.
# Get the paramters from the calling program - shoidls.cgi.
$govlevel = $page->param("str");
I don't see anything wrong with this, or with the call where you
created $page, above. Put in a "warn $govlevel" there and see if it's
what you think it should be. If it is, manually change the value of
str in the URL in your browser and try it again, checking to see if
the variable changes too.
If I preload (compile) my application programs into the Apache registry as I
hope to, when I execute under CGI I'm thinking those copies will be used if
I have the correct handler (like the one below) in my Apache httpd?
Well, you won't be executing under CGI, but if you configure Registry
to handle your URLs and you preload scripts for those URLs, they will
be used. Your configuration is not correct though. Apache::Registry
is mod_perl 1. Maybe you meant to say ModPerl::Registry?
I
haven't found a package for Apache::RegistryLoader yet and may have to get
it form CPAN.
No, ModPerl::RegistryLoader comes with mod_perl 2.
And when I transition to PerlRun and mod_perl, my
understanding is that I should preload the application programs into the
ModPerl::Registry?
You don't really have to preload anything. It may save you some
memory, but it's not important at this point. Wait until your code is
working to worry about things like that.
If I preload the Perl modules I'm using, do I still need to 'Use' those
modules in my application programs?
You don't technically have to, but it's a good practice to do it
anyway, to make it clear which modules depend on which others and make
it easier to work with later.
- Perrin
Re: passing CGI paramters
I know I'm not supposed to say thanks here. But the open source/Perl
community has really impressed me with their willingness to help those less
knowledgeable. Its nothing short of amazing in my experience. When I first
started the prototype work I've been doing, I called the public U. of Ky
Computer Science Department and asked if I could get a little guidance as I
was just transitioning into the WWW world. The faculty I talked to ask me
if this was a consulting request. When I responded that I had hoped to just
be able to ask a couple of questions, the person told me that they weren't
in the business of answering questions from the public without remuneration.
I'm just an individual and could not afford their fees. What a contrast.
Thanks for the guidance and letting me learn from you all Perrin, Peter, and
Clinton over in Perl Monks, and everyone else that responded. CraigT
Perrin Harkins wrote:
>
> On 7/6/07, CraigT <[EMAIL PROTECTED]> wrote:
>> In this regard though, I would
>> like to ask what you recommend to pass back several paramters from a sub
>
> The usual way to do it is to accept a list of return values:
>
> my ($foo, $bar) = sub_call($param);
>
>> I'd like to focus on this problem here because I don't feel like I have
>> much
>> control between the anchor click and the retrival of the paramters in the
>> invoked module.
>
> You don't have any control of that. That's handled by the web browser
> and your operating system. We just assume that part works. I don't
> think the problem is there.
>
>> I haven't shown the code because I'm not quite sure how.
>
> The best thing to do is to try to make a small example program that
> shows the problem. Sometimes, just by trying to make a small example
> of it, you fix the problem.
>
>> The first module presented is m3.cgi.
>
> This code has some problems. This isn't a general Perl help mailing
> list, but I'll point out a couple of quick things. I also recommend
> that you buy a copy of "Perl Best Practices" and join
> http://perlmonks.org/ in order to have a community of people to help
> you with general Perl questions.
>
>> use strict;
>
> Use warnings too.
>
>> (my $ai, my $row, my $r, my $col, my $c, my $cpos, my $blankx, my $lstr,
>> my
>> $xlnklen, my $zzx, my $firstcpos) = "";
>
> This kind of initialization isn't necessary. It's better to declare
> your variables right before you use them, to keep the scope as small
> as possible. The way you're initializing them here won't work anyway,
> since you only have one empty string, and a list of variables on the
> left.
>
>> # Get document root and server name.
>>
>> foreach $key (sort keys(%ENV)) {
>> if ($key eq 'DOCUMENT_ROOT') {
>> $docroot = $ENV{$key};
>> }
>>
>> if ($key eq 'SERVER_NAME') {
>> $servname = $ENV{$key};
>> }
>> }
>
> That should just be
> $docroot = $ENV{DOCUMENT_ROOT};
> $servername = $ENV{SERVER_NAME};
>
>> open(ORG,"<$orgidfn");
>> flock(ORG,LOCK_SH);
>> @glines = ;
>> close(ORG);
>
> Any time you open, flock, or close, you must check for errors with the
> usual "or die" construct.
>
>> print "Content-type: text/html\n\n";
>
> Use $page->header() instead.
>
>> print "$gov Efforts
>
> A templating system might make this HTML easier for you to deal with.
> You could start with something simple, like Text::Template.
>
>> # Get the paramters from the calling program - shoidls.cgi.
>>
>> $govlevel = $page->param("str");
>
> I don't see anything wrong with this, or with the call where you
> created $page, above. Put in a "warn $govlevel" there and see if it's
> what you think it should be. If it is, manually change the value of
> str in the URL in your browser and try it again, checking to see if
> the variable changes too.
>
>> If I preload (compile) my application programs into the Apache registry
>> as I
>> hope to, when I execute under CGI I'm thinking those copies will be used
>> if
>> I have the correct handler (like the one below) in my Apache httpd?
>
> Well, you won't be executing under CGI, but if you configure Registry
> to handle your URLs and you preload scripts for those URLs, they will
> be used. Your configuration is not correct though. Apache::Registry
> is mod_perl 1. Maybe you meant to say ModPerl::Registry?
>
>> I
>> haven't found a package for Apache::RegistryLoader yet and may have to
>> get
>> it form CPAN.
>
> No, ModPerl::RegistryLoader comes with mod_perl 2.
>
>> And when I transition to PerlRun and mod_perl, my
>> understanding is that I should preload the application programs into the
>> ModPerl::Registry?
>
> You don't really have to preload anything. It may save you some
> memory, but it's not important at this point. Wait until your code is
> working to worry about things like that.
>
>> If I preload the Perl modules I'm using, do I still need to 'Use' those
>> modules in my application programs?
>
> You don't technically have to, but i
