Allen Allen - 2 months ago 9
Perl Question

How to decide whether or not use Perl CGI vs regular HTML output

I've discovered that CGI is no longer recommended when it comes to creating HTML pages, but my search for answers as to where the use of

is appropriate has caused more confusion than answers.

I apologise if my question is basic, but I'm hoping that an answer to my question will help to clarify some things.

I'm being told not to create a form like this:

sub output_form {
my ($q) = @_;


print $q->start_form(
-name => 'main',
-method => 'POST',
);

print $q->start_table;

print $q->Tr(
$q->td('Update#:'),
$q->td(
$q->textfield(-name => "update_num", -size => 02)
)
);

print $q->Tr(
$q->td('Date:'),
$q->td(
$q->textfield(-name => "date",-id => "datepicker")
)
);

print $q->Tr(
$q->td('Location:'),
$q->td(
$q->textfield(-name => "location", -size => 50)
)
);

print $q->Tr(
$q->td('Queue:'),
$q->td(
$q->textfield(-name => "queue", -size => 50)
)
);

print $q->Tr(
$q->td('ETO:'),
$q->td(
$q->textfield(-name => "eto", -size => 50)
)
);

print $q->Tr(
$q->td('CAD#:'),
$q->td(
$q->textfield(-name => "cad", -size => 50)
)
);

print $q->Tr(
$q->td('Remarks:'),
$q->td(
$q->textfield(-name => "remarks", -size => 50)
)


But if I create such a form using a regular HTML page, will I be able to interact with user input from a Perl script?

Answer

Update

I've looked at your question again, and it seems like you've become so entrenched in what CGI offers that you've got yourself lost

But if create such a form using a regular HTML page, will I be able to interact with user input from a Perl script?

Whatever your program does, and however it does it, it must send an ordinary HTML page back to the browser that made the original request. There is nothing magical about the various start_form, start_table, Tr, td etc. functions that CGI makes available: it is supposed to be a more convenient way of generating HTML using Perl syntax

Generating HTML is nothing to do with the CGI protocol, and many people felt that it was inappropriate to include that sort of functionality in a module called CGI. That lead to things such as HTML::Tiny, which provides HTML construction functions similar to CGI

Other functions grew to provide just support for the CGI protocol, such as CGI::Minimal

There are many more examples of the separate implementation of both aspects of the original CGI.pm, but you are concerned about whether you can interact with a use via HTTP

Once again, there is nothing special about the functions that CGI.pm makes available. You should run an old CGI program from the command line to see that it just generates the string of HTML that you have prescribed in your calls, and you could have created that in any way that was convenient

Once the HTML has been built and sent to the client, it makes no difference how the message was built. The page will be displayed on the browser and it will offer the user the chance to request more information

I hope that's clearer for you?



Take a look at CGI::Alternatives for options other than CGI

But you're talking about constructing HTML, which is nothing to do with CGI, and one of the main criticisms of the module was that it wrapped too much functionality into a single box

You should focus on using a template package to build your HTML, and one of the most popular is Template::Toolkit

You probably have additional CSS styling and JavaScript intelligence, which should be linked from your HTML as separate files