zencart完整的API开发参考手册 - 图文

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[0] 将会在 $autoLoadConfig[1] 之前发生。同时注意断点相同的任意两个条目将会以它们在文件中出现的先后顺序发生。array() 部分的内容取决于需要达到的效果。让我们设想一些不同的场景。

首先，我只想包括一个需要加载的文件。为此，控制数组条目将会是：

autoType 参数告诉我们，我们只想包括一个文件。 loadFile 参数告诉我们，我们要加载的是哪个文件。 加载函数文件显然可以通过以上方法来做到。

类似的，如果我们希望“include”一个文件：

我们于是有了一个特殊的“require”类型。initSystem 引入了一个名为 init_scripts 的特殊类的 .php 文件。这些文件保存在 includes/init_includes 目录中。每一个这样的文件包含有少量的可以作为 initSystem 进程的一部分运行的过程编码。把它们分离进一个特殊目录的原因是，可以允许重写那些 init_scripts，这将会在稍后进一步探讨。现在，为了加载一个 init_script 我们使用以下的控制数组结构：

通过一个类文件，我们想加载类文件定义，然后实例化这个类，最后可能运行这个类的一个方法（所有这样运行的，都在 application_top.php 文件范围内）。 通过控制数组，我们有以下的条目来帮助我们。

逐一分析以上选项。

autoType => 'class' 我们在这做的是包括进一个“loadFile”。然后，在本例中我们从 includes/classed （DIR_WS_CLASS）目录提取文件。

autoType => 'classInstantiate' 执行这样形式的代码：objectName = new className();。

根据以上的代码，得到的一个例子：

由此推论，我们可能需要实例化一个与 session 相关的类。例如 shopping_cart 类。从上面的例子中，我们可以得到：

事实上我们更进一步，通常来说我们只想实例化一个 session 对象，如果它还不是一个 session 对象。这种情况下，我们使用了“checkInstantiated”属性，这将会生成以下代码：

最后的例子，autoType => 'objectMethod' 展示了如何在 application_top.php 文件中运行一个类的方法。当写下本教程的时候，还没有传递方法参数的规定。所以产生的代码将会是（基于以上例子）：

1.1.4.1 关于后台自动加载器的注解

v1.3.x 的目标是最终把所有的函数移动和重构进类。更进一步，这些类将会被后台和前台代码通用。

然而这将带来一个问题：自动加载类文件。现在的自动加载器的代码，将会默认的加载来自前台 includes/classes 的类，而不是 admin/includes/classes。

为了从 admin/includes/classes 目录加载后台类文件，在现在这个过渡时期，我们为 'autoType' => class 提供了一个额外的选项。 设想这个：