in reply to Re: CGI simple but frustrating fault
in thread CGI simple but frustrating fault

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

Replies are listed 'Best First'.
Re^3: CGI simple but frustrating fault
by hippo (Archbishop) on Mar 10, 2025 at 12:26 UTC

    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]
Re^3: CGI simple but frustrating fault
by GrandFather (Saint) on Mar 10, 2025 at 23:55 UTC

    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]
      I use Komodo IDE and Uniserver but I have always (in more than 40 years of software) used print statements as a help
[reply]

        Setting breakpoints and inspecting the current state of any or all variables is a much more powerful tool for understanding how code is behaving than printing stuff out. Especially as you can update variable contents to test out ideas about what might be going wrong as well!

        I figured out more than 40 years ago that trying to untangle problems using print as my sole tool was like trying to do gymnastics in a straight suit.

        Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]

In Section Seekers of Perl Wisdom