编写 Perl CGI 应用程序的最佳方式是什么？答案

【问题标题】：What's the best way to write a Perl CGI application?编写 Perl CGI 应用程序的最佳方式是什么？
【发布时间】：2010-09-23 19:12:23
【问题描述】：

我看到的每个 CGI/Perl 示例基本上都是一堆包含 HTML 的打印语句，这似乎不是编写 CGI 应用程序的最佳方式。有一个更好的方法吗？谢谢。

编辑：我决定使用 CGI::Application 和 HTML::Template，并使用以下教程：http://docs.google.com/View?docid=dd363fg9_77gb4hdh7b。谢谢！

【问题讨论】：

标签： perl cgi

【解决方案1】：

当然（您可能正在查看 90 年代的教程）。你会想要选择一个框架。在 Perl 领域，这些是最受欢迎的选择：

CGI::Application - 非常轻量级，有很多社区插件
Catalyst - 更重，更多花里胡哨
Jifty - 比上面更神奇

【讨论】：

谢谢！当我有时间试用它们时，我会试用它们并接受您的回答（应该是下周，我要去度假:-)）
不知道Jifty是否仍然是一个不错的选择？有维护吗？我注意到它正在从 Debian 中删除，因为它没有被广泛使用。 Jifty 对 CPAN 的最后一次更新是在 2011 年。
是的，Jifty 可能应该从该列表中删除。但其他人肯定已经站起来取代它。我现在将 Dancer 和 Mojolicious 添加到该列表中。

【解决方案2】：

这是一个非常非常大的问题。简而言之，更好的方法称为Model/View/Controller（又名MVC）。使用 MVC，您的应用程序分为三部分。

模型是您的数据和业务逻辑。它是构成应用程序核心的东西。

视图是向用户展示事物的代码。在 Web 应用程序中，这通常是某种模板系统，但也可以是 PDF 或 Excel 电子表格。基本上就是输出。

最后，你有了控制器。这负责将模型和视图放在一起。它接受用户的请求，获取相关的模型对象，并调用适当的视图。

mpeters 已经提到了几个用于 Perl 的 MVC 框架。您还需要选择一个模板引擎。最受欢迎的两个是Template Toolkit 和Mason。

【讨论】：

【解决方案3】：

暂时离开 CGI 与 MVC 框架的问题，您需要的是 CPAN 的输出模板模块之一。

模板工具包非常受欢迎（CPAN 上的Template.pm） Text::Template、HTML::Template 和 HTML::Mason 也很流行。

HTML::Mason 不仅仅是一个模板模块，因此对于一个简单的 CGI 应用程序来说可能有点过于繁重，但在您决定哪个最适合您时值得研究一下。

Text::Template 相当简单，并且在模板中使用 Perl，因此您可以循环数据并在 Perl 中执行显示逻辑。人们认为这既有利也有弊。

HTML::Template 也小而简单。它实现了自己的一组标签，用于 if/then/else 处理、变量设置和循环。而已。由于与 Text::Template 完全相反的原因，这被视为优点和缺点。

模板工具包 (TT) 实现了一种非常庞大的 perlish 模板语言，其中包括循环和逻辑等等。

我使用了 HTML::Template 之一，发现我想要更多的功能。然后我成功地使用了 Text::Template，但发现它想要玩弄命名空间有点烦人。我开始了解并喜欢 Template Toolkit。对我来说，感觉是对的。您的里程可能会有所不同。

当然，仍然有旧的“打印 HTML”方法，有时几个打印语句就足够了。但是您已经想到了将显示与主要逻辑分开的想法。这是一件好事。

这是通往模型/视图/控制器 (MVC) 之路的第一步，您可以在其中将数据模型和业务逻辑（您的代码接受输入、对其进行处理并决定需要输出的内容）分开，您的输入/输出（模板或打印语句 - HTML、PDF 等），以及连接两者的代码（CGI、CGI::Application、Catalyst MVC 框架等）。这个想法是改变你的数据结构（在模型中）不应该需要改变你的输出例程（视图）。

【讨论】：

CGI 与 MVC 是荒谬的。 CGI（通用网关接口）是一个独立于平台的接口，用于在网络/信息服务器上运行外部程序、软件或网关。 MVC（模型-视图-控制器）是一种将应用程序划分为三个责任区域的设计模式。如果您使用 Perl 创建 Web 应用程序，那么您将使用 CGI 的一种或另一种方式。使用 MVC 设计模式是可选的和推荐的，但最终与 CGI 的使用无关。
如果你对术语学究气，坚持CGI和MVC的外延意义，而忽略它们的内涵意义，那才是荒谬的。虽然使用 MVC 模式构建 CGI 应用程序是完全合理的，但程序员从 CGI.pm、CGI::Application 等（随着进度创建自己的 MVC 结构并重构代码）演变为 MVC 框架的情况是这样的像 Catalyst 一样，在这一点上它们也倾向于演变成 FCGI 或 mod_perl。所以实用主义，不是废话。
言出必行。缩写词也是如此。当我们不再同意这一点时，我们又回到了树上互相咕哝的状态。 en.wikipedia.org/wiki/Common_Gateway_Interface
感谢您的同意。

【解决方案4】：

Perl5 Wiki 提供了一个很好的（虽然尚未完成）web frameworks 和 templates 的列表。

“模板”wiki 条目中链接的比较文章值得一读。我还建议阅读这篇关于 PerlMonks 的 push style templating systems 文章。

对于模板，Template Toolkit 是我使用最多的模板，强烈推荐它。还有一个O'Reilly book，它可能是 Perl 王国（在 Web 框架内部或外部）中使用最多的模板系统。

我越来越喜欢的另一种方法是非模板“构建器”解决方案。 Template::Declare 和 HTML::AsSubs 等模块符合此要求。

【讨论】：

【解决方案5】：

我觉得在 Framework/Roll-your-own 困境中取得适当平衡的一个解决方案是使用三个关键的 perl 模块：CGI.pm、Template Toolkit 和 DBI。通过这三个模块，您可以进行优雅的 MVC 编程，易于编写和维护。

所有三个模块都非常灵活，模板工具包 (TT) 允许您在需要时以 html、XML 甚至 pdf 格式输出数据。您还可以在 TT 中包含 perl 逻辑，甚至在其中添加您的数据库接口。这使您的 CGI 脚本非常小且易于维护，尤其是当您使用“标准”编译指示时。

它还允许您将 JavaScript 和 AJAXy 内容放入模板本身，从而模拟客户端和服务器之间的分离。

这三个模块是 CPAN 上最受欢迎的模块之一，拥有出色的文档和广泛的用户群。此外，使用这些进行开发意味着您可以在对代码进行原型设计后快速迁移到 mod_perl，从而快速过渡到 Apache 的嵌入式 perl 环境。

总之，一个紧凑而灵活的工具集。

【讨论】：

这是迄今为止所提问题的最佳答案。
我会更新我的答案以敦促考虑 Xslate，这是一种快速模板解决方案。它有一个 TT 语法选项，便于从 TT 迁移，并且它处于移植到 Golang 的早期阶段。

【解决方案6】：

您还可以将演示与代码分开，只使用模板系统，而无需引入成熟框架的所有开销。 Template Toolkit 可以以这种方式单独使用，Mason 也可以，尽管我倾向于认为它更像是一个伪装成模板系统的框架。

但是，如果您非常热衷于将代码与演示文稿分离，请注意 TT 和 Mason 都允许（甚至鼓励，取决于您阅读的文档）将可执行代码嵌入到模板中。就个人而言，我觉得在你的 HTML 中嵌入代码并不比在你的代码中嵌入 HTML 好，所以我倾向于选择HTML::Template。

【讨论】：