在与Paul和Mike交谈后，最近几个月我意识到，虽然我经常宣布Cgiapp的新版本，但我很少解释它是什么或开发它的原因。
~~当我试图提议将它包含在那个项目中时，我在PEAR列表上遇到了麻烦，当时我错误地将它描述为一个框架。（这是在框架在PHP领域风靡一时之前；显然，PEAR开发人员不会审查任何可能被解释或解释为框架的东西，即使它不是。）~~我错误地将Cgiapp称为框架在考虑向PEAR提出建议时有一次。但如果不是框架，那Cgiapp又是什么？简单地说：
Cgiapp是模型-视图-控制器(MVC)模式的控制器。它可以是前端控制器或应用程序控制器，但通常用作后者。
Cgiapp是模型-视图-控制器(MVC)模式的控制器。它可以是前端控制器或应用程序控制器，但通常用作后者。
作为一个控制器，它提供了一些基本的、可配置的路由机制来确定应该为给定的请求显示什么，一个用于配置变量的简单注册表以及用于在方法调用之间传递变量、错误处理、模板引擎的挂钩，并挂钩到前/后应用程序和请求操作。
在使用Cgiapp开发应用程序时，您的操作理念是一个屏幕，一种方法。您定义一个将显示屏幕映射到方法的哈希表，并指示查询参数或指示请求显示的请求URI段；当请求进来时，适当的方法被调用。在Cgiapp术语中，这些称为“运行模式”。
是什么让Cgiapp对我这个开发者如此有吸引力？
- 面向对象。Cgiapp本质上是面向对象的；要使用它，您必须创建一个扩展Cgiapp（或Cgiapp2！）的类，并将方法映射到操作。没有办法绕过它。因此，应用程序具有命名空间、可移植性和可测试性。
- 可重用性。因为每个应用程序都是一个类，并且每个应用程序实例都是从实例脚本触发的，并且因为您可以将配置变量从实例脚本传递给类，基于Cgiapp的应用程序本质上是可重用的。这使得分发应用程序以及在多个站点位置重用它们变得容易。例如，我在多个位置使用文章应用程序，访问不同的文章商店——但使用相同的文章应用程序类。每个都有不同的外观和感觉，有时在同一站点中，有时在不同站点中，但我只需要更改数据存储和模板即可实现差异化。
- 可扩展性
- 开发人员的自由。因为Cgiapp不是一个框架，而且实际上只有一个类(这在Cgiapp2中发生了变化，但这只是因为Cgiapp2有一些辅助类），它为开发人员提供了很大的自由度。您可以选择要使用的模板系统。或者你想使用什么数据存储机制。或者你将如何处理会话。或者您是否将使用漂亮的url或GET参数（或允许一个，但默认为另一个）。简而言之，它允许开发人员挑选他们想要在其应用程序中使用的库和组件。
曾经编写过一些代码，然后需要一个应用程序来复制大部分功能，但又添加了一些曲折吗？一个这样的例子：我有一个小型画廊应用程序，后来需要一个电子贺卡应用程序。后者基本上是一个图库类型的应用程序，但在选择图像时，需要显示电子贺卡表单，还需要处理该表单的结果。我只是让电子贺卡类扩展了画廊类，添加了一个方法，并为图像视图创建了一个新的视图模板。总的额外工作：大约一个小时左右。
这是上面的最后一点，它真正将Cgiapp与我审查过的大多数其他MVC框架区分开来。大多数框架倾向于为您提供一切，将其打包，并尝试将其作为开发人员出售给您：“仅使用我们解决方案中集成的工具，否则我们无法保证最佳性能。”Cgiapp不会那样做。Cgiapp让开发人员做主并说，“我熟悉某某库，想在我的MVC应用程序中使用它”，或者，“我喜欢某某模板引擎，并想使用它那，”或者，“无论mod_rewrite是否可用，我都需要我的应用程序正常工作。”例如，我使用Smarty和PEAR::DB对Cgiapp进行了广泛的开发；我还使用过Savant和Zend_Db。我有一些用户报告说他们喜欢ADODB。我使用过漂亮的URL，但我也经常使用GET或POST来确定当前的运行模式。重点是，Cgiapp仅提供一个易于使用的控制器，您可以将您选择的模型和视图插入其中。
对我来说，Cgiapp的另一个非常重要的方面是应用程序的可重用性。使用Cgiapp2，这甚至成为一项功能，因为可以通过实例脚本中的运行时插件自定义应用程序。如果应用程序必须绑定到特定站点结构，则它永远无法完全重用。但是，当它可以通过模板、数据存储和/或操作前/后操作对每个实例进行配置时，它就变得可分发和可插入了。这意味着可以将论坛、图库、联系表、文章系统等应用程序放置在站点的任何位置，并轻松配置以匹配该站点的外观和感觉。对我来说，这是无价的。
有了对Cgiapp的解释，我打算开始写关于Cgiapp和Cgiapp2的使用的博客，以展示如何以最佳方式使用它。同时，请随时发表评论并提出问题！
更新：更改了第三段中的语言以强调Cgiapp不是框架而不是反PEAR倾向。
