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

Dear all, Not being an expert in new-fangled technology ("what do you mean, I'm not allowed to use assembly code?") I am trying to write a .cgi module to handle a form's data. (Primarily using a perl reference book, but that is by the by). My understanding is that I can write a cgi module to create AND handle data from a form. So I did, but I am having trouble making the (software) decision as to how to progress upon code execution. Please note that it is for historical reasons that I use HTML::Tiny and not CGI but that is not part of the problem, unless corrected here 


# Start the page and form creation process as required
$co = HTML::Tiny->new( mode => 'html' );


if ($co->param())
{

    #data returned from the form submission
    print "data present - to be analysed\n";
    $buffer = "";
    if($ENV{'REQUEST_METHOD'} eq "POST")
    {
        # POST method retrieves data by the READ command
        print "POST read\n";
        read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    }
    else
    {
        # GET method retrieves by accessing the relevant environment v
+ariable
        print "Query String\n";
        $buffer = $ENV{'QUERY_STRING'};
    }

    print ("buffer=<p>$buffer</p>");


    if (length ($buffer) > 0)
    {
       # Analyse the form data ....
    }
    else
    {
        print "<p>buffer size is zero<p>";
        exit;
    }
}
else
{
    # No data passed to here by a submit - create the display form tha
+t is required to do so
    print "no data present -to display form\n";
    displayForm();

}

[download]

When I run this code (on a server) I get the diagnostics saying that there is "data present - to be analysed" (as if this call is to handle the form data) but then in the next breath the diagnostics say that the "buffer size is zero". I had a minor thought that the data was somehow being 'retained' somewhere and each time that I ran the script, the 'retained' data was being retested. SO I shut everything down overnight, re-running in the morning, but the same 'problem' presents itself

Q: What is the failing in my software logic here? Have I misread/misunderstood/misinterpreted what I have read in my perl book? As always any help from the monastery would be gratefully received.

Regards ADB

Replies are listed 'Best First'.
Re: CGI simple but frustrating fault
by 1nickt (Canon) on Mar 09, 2025 at 15:28 UTC

    Hi, where did you get the idea that HTML::Tiny processes form input? There's nothing in the documentation or examples to suggest that.

    The param() method simply prints the string <param>.

    I think you may be confusing the functionality of this module with that of very old ways of using CGI. How old is your book? You probably would be better served with using something like Dancer2 or even sticking with HTML::Tiny for your form generation and CGI::Tiny for the form handling.

    Hope this helps!


    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]

      Thanks for the input but I do realise that HTML::Tiny does NOT process form input - what my OP was trying to say was that I use HTML::Tiny to do the form generation (hidden in the code not shown here) and not the CGI functionality to do the same. I'll see about using CGI to do the form interpretation but, as per the OP, my problem is the logic of deciding what dictates that the cgi code decides that the form data is to be processed (as a result of the user pressing the 'SUBMIT' button (again, not shown)) against the initial first-time entry to the code where the form is to be generated prior to the user interaction. That is the part that I cannot seem to fathom.

      BTW - the print statements are used purely for my own debugging purposes to try and find out where I am going wrong by tracing the path through the code

      ADB
[reply]

        You are calling the param method on an HTML::Tiny object as your test but this will always return true. Instead you should be performing a param-like test on your CGI object.

        Suppose the submit input field of your form is called "foo". Then your code might be:

        my $cgi = CGI->new;
if ($cgi->param ('foo') {
  # have data to process
} else {
  # no data, so print an empty form
}

        [download]

        If you have an aversion to using CGI (or any of the smaller, lighter CGI modules) and want to do it by hand then you can test the 2 things you've already identified but in the outer test. eg.

        if ($ENV{QUERY_STRING} || 'POST' eq $ENV{REQUEST_METHOD}) {
  # have data to process
} else {
  # no data, so print an empty form
}

        [download]

        🦛

[reply]
[d/l]
[select]

        An IDE like Komodo will get you there a lot faster than trying to debug using print statements.

        Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]
Re: CGI simple but frustrating fault
by NERDVANA (Priest) on Mar 11, 2025 at 23:33 UTC
    Not being an expert in new-fangled technology ("what do you mean, I'm not allowed to use assembly code?")

    Actually you can use assembly in your perl CGI if you want to...

[reply]

      Dear all,

      Thanks you for your assistance in this matter and yes, it was a case of reorganising the sequence of statements.

      HOWEVER, the most salient piece of advice that I came across was on another posting elsewhere (sorry, haven't got the link) where it was mentioned that "use CGI" causes all sorts of problems with the POST method and effectively clears the POST buffer before it is referenced. The workaround is to check the buffer via the ENV statements BEFORE implementing the "use CGI" statement. This is now how I do the checks which allow some progress for me. Again, many thanks for the advice and observations

      regards, ADB

[reply]
        another posting elsewhere (sorry, haven't got the link) where it was mentioned that "use CGI" causes all sorts of problems with the POST method

        That has not been my experience. CGI.pm has caused me a grand total of zero problems with POST requests in the quarter century or so that I have used it. Perhaps if you were to provide an SSCCE to demonstrate, someone here could steer you right.

        CGI.pm has its flaws but it certainly beats trying to parse parameters or uploaded files by hand from first principles every time.

        🦛

[reply]

        I've literally never seen this happen, nor have I seen anyone suggest this course of action. You've posted code your aren't running, you've not posted a self contained example to replicate the issues. How do I post a question effectively?.

[reply]

Back to Seekers of Perl Wisdom