我发现在创建HTML页面时不再推荐使用CGI,但我搜索CGI
适当位置的答案却引起了比答案更多的混淆。
如果我的问题是基本的,我道歉,但我希望我的问题的答案有助于澄清一些事情。
我被告知不要创建这样的表格:
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)
)
但是如果我使用常规HTML页面创建这样的表单,我是否可以与Perl脚本中的用户输入进行交互?
答案 0 :(得分:5)
我再次看了你的问题,看来你已经变得如此根深蒂固CGI
提供了你自己迷失的东西
但是如果使用常规HTML页面创建这样的表单,我是否能够与Perl脚本中的用户输入进行交互?
无论您的程序是什么,无论它做什么, 必须 将普通的HTML页面发送回发出原始请求的浏览器。 start_form
提供的各种start_table
,Tr
,td
,CGI
等功能并不神奇:它应该更方便使用Perl语法生成HTML的方法
生成HTML与CGI协议无关,许多人认为在名为CGI
的模块中包含这种功能是不合适的。这会导致诸如HTML::Tiny
之类的内容,它提供类似于CGI
其他功能越来越多,为CGI协议提供 支持,例如CGI::Minimal
原始CGI.pm
的两个方面的单独实现还有更多示例,但您担心是否可以通过HTTP与用户进行交互
对于CGI.pm
提供的功能,没有什么特别的。您应该从命令行运行一个旧的CGI程序,看它是否只生成您在调用中规定的HTML字符串,并且您可以以任何方便的方式创建它
构建HTML并将其发送到客户端之后,如何构建消息没有任何区别。该页面将显示在浏览器上,它将为用户提供请求更多信息的机会
我希望你更清楚?
查看CGI::Alternatives
以了解CGI以外的选项
但是你在谈论构建HTML,这与CGI无关,而且该模块的一个主要批评是它将太多功能包装在一个盒子中
您应该专注于使用模板包来构建HTML,其中最受欢迎的是Template::Toolkit
您可能还有其他CSS样式和JavaScript智能,应该从HTML链接到单独的文件
答案 1 :(得分:1)
对于向用户显示HTML页面的浏览器,Web服务器必须返回包含正文中所需HTML的HTTP响应。有时,HTML是从静态文件返回的,有时它是由某个服务器端应用程序生成的。
浏览器不关心(实际上,不太可能知道)HTML是如何生成的。它所知道的是它收到了一个带有Content-Type of text / html的HTTP响应和一个由HTML组成的正文,它需要解析和渲染。
所以你有几个选择。您可以编写包含表单的静态HTML文件。或者你可以编写一个生成它的Perl程序。这些选项中的任何一个对浏览器都没有影响。您已选择编写Perl程序。您可以使用各种技术来实现此目的。这些天我不会推荐CGI(请参阅CGI:Alternatives了解一些建议),但我们假设我们会继续这样做。
(这里也值得指出,CGI - 协议 - 与CGI.pm不同,它通常用于编写在协议下运行的Perl程序。您不需要使用CGI。下午写一个CGI程序。)
CGI.pm曾经包含用于生成HTML的辅助函数。这些现已弃用,已移至单独的模块。他们的弃用有很多原因。最明显的可能是在许多项目中,设计和实现站点前端的人员与编写后端代码的人员不同。如果一个前端开发人员已经需要知道HTML,CSS和Javascript,那么期望他们将Perl知道为 - 他们需要使用HTML生成函数来编辑网页,这有点不公平。即使在我是唯一一个在网站上工作的人的情况下,我发现在前端和后端技术之间实施严格的分离有助于保持代码更清晰。
所以我真的不建议使用这些功能。据我所见,没有人愿意。代替。我会使用模板系统。特别是,我使用Template Toolkit(这是个人偏好,但是I'm slightly biased)。
使用模板引擎,您可以将所有HTML代码放在一个完全独立的文件中,您的前端团队可以以他们选择的任何方式拥有和编辑这些文件。然后,当您的后端代码需要显示HTML页面时,它可以使用模板处理函数来执行此操作。一个(非常!)简单的例子可能如下所示:
在template.cgi中:
#!/usr/bin/perl
use strict;
use warnings;
use Template;
use CGI qw[header param]; # Only use two functions from CGI.pm
print header;
my $tt = Template->new;
if (my $name = param('name')) {
$tt->process('output.tt', { name => $name })
or die $tt->error;
} else {
$tt->process('form.tt')
or die $tt->error;
}
form.tt
看起来像这样:
<html>
<head><title>What's your name?</title></head>
<body>
<form enctype="multipart/form-data">
Enter name: <input name="name" />
</form>
</body>
</html>
output.tt
看起来像这样:
<html>
<head><title>Welcome [% name %]</title></head>
<body>
<h1>Hello [% name %]</h1>
<p>Pleased to meet you.</p>
</body>
</html>
答案 2 :(得分:-1)
CGI.pm的下降来自两个方向。 HTML构建方法总是一个丑小鸭,首选某种形式的模板。在另一方面,处理与客户端(CGI)交互的方法首先被mod_perl(它有自己的库用于此类事物)取代,后来被Dancer和Mojolicious等框架取代。
这些框架还包含模板。除非你维护旧代码,否则没有理由再学习旧式CGI了。舞者和Mojo阵营之间也存在很多争论;我建议选择一个,在一个项目上学习它,然后在另一个项目中学习另一个。