Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Here is my dilemma. Im programming a system with multiple modules to help break up my code. Im access my modules through the "use" statement. My Modules, however has no access to the form data from the CGI Module
package development; use strict; use warnings; use CGI; my $forms = new CGI; print $forms->param("elementName");
The above code does absolutely nothing inside the module itself. It seems that my modules have no access to form data . If I try to do this

Main Script
use strict; use warnings; use CGI; my $forms = new CGI;
Module
use strict; use warnings; $main::forms->param("formElement");
This does nothing either. So thats my dilemma. How do I get my modules to beable to access GET and POST information. Thanks!

Replies are listed 'Best First'.
Re: CGI Module
by tlm (Prior) on Jun 05, 2005 at 03:38 UTC

    The problem with the code you posted is that my $forms is a completely different variable from $main::form. The former is a lexical variable, the latter a package variable. See perldoc -q lexical.

    Can you tell us more about the module you that you want to access CGI data from? Is it an OO class? If so, you could design the class so that it (or its instances) contain a reference to a CGI object (a has-a relationship). If it is not an OO class, you may have to pass the CGI object as an additional argument to the functions in the module, or else have a package-level configuration variable for the module to hold a reference to some CGI object, and provide a method to set this configuration variable from the calling code.

    the lowliest monk

      This is the entire code for my module. Yes I know I am reinventing the wheel a bit, but the purpose is to store all form elements in a standard location accessable from any of the other modules in the system that would be dependant. Instead of having to call the CGI module from each(which mind you doesnt work anyway.
      package forms; use strict; use warnings; use CGI; sub new { my ($class) = @_; my $self = {_form => undef}; bless $self,$class; return $self; } sub fetch { my ($self) = @_; $self->{_form} = new CGI; return $self->{_form}; } 1;

        What are you trying to do with this module, or why do you need a separate module? That's a lot of typing to simply do my $q = CGI->new.

        Remember that once you've created a CGI object, it reads STDIN, and you won't be able to read that again. If all of your form data is in the message body, only the first CGI object will have been able to see it.

        How are you using this module in your script?

        --
        brian d foy <brian@stonehenge.com>

        One potential problem I see is that, as you have it, the fetch method will return a different CGI object with each invocation. Also, it's not clear to me that a OO class is particularly useful here. (I mean, if you are going to pass an object of this class around so that you can access the CGI object through it, then you may as well pass around the CGI object in the first place.)

        I'm not entirely clear on what you're trying to do, but maybe this would do what you want:

        package forms; my $FORMS; sub fetch { $FORMS ||= CGI->new(); return $FORMS; } ## elsewhere use forms; my $q = forms::fetch();

        the lowliest monk

Re: CGI Module
by tilly (Archbishop) on Jun 05, 2005 at 06:08 UTC
    Just use the procedural interface everywhere and forget that the OO interface exists. Then the issue of how to make sure that the CGI object you have has the data goes away - everyone is using the default CGI object in the CGI module.
Re: CGI Module
by brian_d_foy (Abbot) on Jun 05, 2005 at 04:07 UTC

    Have you tried the usual debugging things, such as brian's Guide to Solving Any Perl Problem and Troubleshooting Perl CGI scripts?

    I'd like to see your real script along with the input that you are giving to it. Perhaps you are doing the bone-headed thing I tend to do: look for form values that aren't actually in the input. :)

    --
    brian d foy <brian@stonehenge.com>
A reply falls below the community's threshold of quality. You may see it by logging in.