【精品】zencart完整的API开发参考手册.docVIP

Zen Cart API开发指南 1.1 InitSystem 1.1.1 initSystem 介绍 为什么是 initSystem？ initSystem 原来是指一个用在把一定 PHP 文件组合在一起的标签，在新的 Zen Cart 文献中，initSystem 这个短语，是指在任何 ‘命令’脚本运行之前被自动包括或初始化的全部文件。 Zen Cart 使用一个（非面向对象）页面控制器模式，以 HTTP_GET 参数为基础，决定需要运行的脚本。其中最重要的是 main_page 这个 HTTP_GET 参数。取决于该参数，一个命令脚本然后运行。每个命令脚本位于 /includes/modules/pages 目录中。 例如，如果 main_page=login 那么将会从 /includes/modules/pages/login/ 目录提取命令脚本。然而每一个命令脚本要做的第一件事是 require() /includes/application_top.php 文件。这个文件是 initSystem 的核心。 application_top.php 文件负责初始化基本的子系统（数据库抽象/sessions/语言等等）以及加载全局配置数据。在以前这些是通过一个硬编码（hard-coded）脚本 来实现的。从 v1.3.0 开始，Zen Cart 现在使用了一个控制数组来决定哪些函数/类/数据 文件被包括和初始化。这将允许开发者和贡献者访问和扩展 initSystem 而不受升级影响。 在下面的几个章节，我们将会探讨 Zen Cart 引擎是如何使用 application_top.php 来初始化系统的。 1.1.2 application_top.php － 一点历史 按照 osCommerce 的定义，application_top.php 是被每一个“唤起和处理基础核心子系统所必须的”页面或脚本所包括的文件。任何被页面所需要的全局函数或类必须在这里被初始化。 从一个定制角度而言这糟糕透了。如果第三方代码（贡献者）需要访问一个新的全局函数或类，那么 application_top.php 需要被破解。这显然会引发升级问题：当 application_top.php 被重写（在升级过程中），任何定制的代码将会丢失。 Zen Cart 试图减轻这个痛苦，办法是通过提供一定的重写目录，来放置额外的数据或函数文件，当 application_top.php 运行的时候可以自动包括进这些额外文件。 这个系统的问题是：在 application_top.php 运行顺序中，只提供了很少的空间来引入新的代码。它同时也没有提供引入新类的功能。需求是：一个 application_top.php 文件应该允许放置由开发者完全掌控的任意新函数、类或者脚本。更进一步，还应该允许放置一些加载和唤起类的方法。 自从 v1.3，Zen Cart 通过把由 application_top.php 运行的代码抽象进一个控制数组，来实现这个目标。这个数组存储了需要运行的函数、类、初始化脚本的细节，以及它们（函数、类、初始化脚本）的运行顺序。由 此，现在第三方开发者可以 hook （挂勾）到 application_top.php，同时可以确信将来任何的代码升级（系统升级）一般不会覆盖他们自己的代码。 1.1.3 application_top.php - 断点 在 Zen Cart，application_top.php 文件中现在几乎没有过程代码。很少的一部分过程代码将会稍后探讨。以前大量存在于 application_top.php 文件中的过程代码现在让位给处理断点。断点可以简单的描述为重要的节点。在 application_top.php 文件中我们现在有差不多20个断点。在每一个断点，一些重要的事情发生了。- 我们可以加载一个函数或者类，初始化一个类，加载一个脚本片断，诸如此类。重要的节点用来识别在每个断点，第三方代码（通过添加到控制数组的方式）也能加 载函数，加载类，初始化类，运行一个类的方法或者加载（require）一个脚本片断。 1.1.4 控制数组 控制数组会从 /includes/auto_loaders 目录中被自动加载。在那个目录中的每一个 *.php 文件预计拥有一定的结构。在 v1.3 我们使用一个名为 config.core.php 的文件作为控制 application_top.php 的主要文件。第三方开发者可添加他们自己的控制数组文件。每个文件的结构看起来应该是这样的： 在 $autoLoadConfig 后面的值（本例中是[0]）代表动作发生的顺序（也就是断点），这样一来 $autoLoadConfig[