in reply to CGI simple but frustrating fault

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.

Replies are listed 'Best First'.
Re^2: CGI simple but frustrating fault
by gsd4me (Beadle) on Mar 10, 2025 at 11:29 UTC

    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

      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 }

      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 }

      🦛

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