第三方基于PHP类的库的最佳实践

我目前正在开发一个需要第三方PHP库的模块，该库本质上是一个PHP类。通常，我会将其放置在include /子目录中并添加

files[] = includes/Foo.php

到我的.info文件，并在我执行$foo = new Foo()。时让Drupal 7类自动加载器完成它的工作 。

不过，我有权向公众发布此模块，而不希望将库与模块一起使用。我非常了解许可的复杂性，但是出于这个问题，我想忽略它。

还有一个类似的问题，如何包含PHP库？，但我真的不认为这可以解决我的难题。

这个回答这个问题本质上说，使用库API，但每一个模块，我已经发现，使用这只是做一个libraries_get_path()得到基本路径（包括备用路径时，不可用），然后再执行require或include一些错误检查（或不检查）。都做类似的事情：

if (!class_exists('Foo')) {
  $path = function_exists('libraries_get_path') ?
    libraries_get_path('foo') : 'sites/all/libraries/foo';
  if (!include($path . '/Foo.php')) {
      // handle this error
  }
}

在这种情况下，Libraries API实际上并没有做任何事情。与要求用户下载副本并将其放置在模块文件夹本身中的旧方法相比，我看不出使用此方法的优势。而且，仍然存在模块开发人员仍然需要使用/ 手动进行加载的问题。例如，Facebook模块只是将库加载到中，而HTML Purifier模块具有内部功能，可在每次需要该库时进行检查和加载。includerequirehook_init

这可能是一种普遍的做法，但似乎不是最佳做法。

我的模块应该主动声明一个a hook_libraries_info以便我使用libraries_load('foo')吗？这似乎也很奇怪。

图书馆API模块的分支2.x的允许开发人员定义，通过hook_libraries_info（） ，或一个.info文件的库，下面的信息（参见libraries.api）：

• 库的依赖项
• 对于每个依赖项，与库兼容的版本
• 需要加载的文件列表（CSS，JavaScript或PHP文件）

需要该库时，将使用需要加载的文件列表来加载这些文件。这意味着您的模块无需使用drupal_add_css()或加载CSS和JavaScript文件。drupal_add_js()而Libraries API模块已经完成了此操作。加载依赖项是一项由Libraries API模块完成的任务，无需调用模块执行任何操作。

该模块所做的全部工作是使用以下代码来加载库。（请参阅使用Libraries API 2.x（作为模块开发人员）。）

// Try to load the library and check if that worked.
if (($library = libraries_load($name)) && !empty($library['loaded'])) {
  // Do something with the library here.
}

如果只需要检测是否存在一个库，则该模块应使用类似于以下代码的代码。

if (($library = libraries_detect($name)) && !empty($library['installed'])) {
  // The library is installed.
}
else {
  $error = $library['error'];
  $error_message = $library['error message'];
}

在属性之间hook_libraries_info()可以返回，还有'download url'，即使在分支3.x中也没有实际使用。将来可能会使用它，或者第三方模块可以挂接到Libraries API模块中，并下载所请求但缺少的库。

经过大量的挖掘之后，我仍然不知道最佳实践是什么。受PHPMailer模块的启发，我为基于类的PHP库提供此功能：

function foo_registry_files_alter (&$files, $modules)
{
  if (!class_exists('Foo')) {
    $library_path = function_exists('libraries_get_path') ?
      libraries_get_path('foo') : 'sites/all/libraries/foo';

    $files[$library_path . '/Foo.php'] = array(
      'module' => 'foo',
      'weight' => 0,
    );
  }
}

这使用hook_registry_files_alter来检查类的存在，如果找不到，则将一个文件添加到类注册表中（相当于files[] = ...模块.info文件中的一行）。然后，在foo.php中定义的类将随自动加载器一起提供，因此在使用该类之前无需显式加载文件。

这还会对Libraries API产生一个软要求，并将在可用时使用它，否则使用合理的默认值。

通过hook_requirements添加一些检查以确保文件存在，自动装载器找到类，版本检查等也是一个好主意。

还值得注意的是，在发布队列中正在讨论库API的自动加载方法。

简而言之： 如果您打算将模块发布给公众，并且（第三方）库不是经过GPL授权的，则您将需要使用库作为依赖项，或者要求用户手动下载这些文件（但您将无法从.info文件自动加载）

再过一会儿：

我们之所以需要库模块，基本上是许可。无论是否使用该模块，都将以某种方式包含该文件。

好吧，我认为您没有找到有关此类模块库的很好的例子。检出SMTP模块，它带有GPL中必需的类。（.info文件blob）。

另请参见simplehtmldom模块，该模块仅包含文件，而没有其他内容。

库模块方便使用的地方是，您可以要求用户将文件上传到任何需要的地方。用户将其上传到site / all / libraries文件夹并不明显。可能是site / example.com / libraries或类似的东西。库模块可以通过为您执行目录发现工作来帮助您专注于实际工作。

对于为客户开发的定制模块，通常会在模块文件夹中包含文件，并根据库的使用情况使用require_once或.info文件条目。

同样，许可问题也不是使用库模块的唯一原因。如果第三方库具有快速发布周期并且您的模块开发最少，该怎么办？如果将其包含在模块中，则每次都必须发布一个新版本。您可能不想发布7.x-1.99，它与7.x-1.0非常相似。

看来主要问题是自动加载。

您可以使用库模块加xautoload模块。

然后在您自己的模块中

function mymodule_libraries_info() {

  return array(
    'mymodule-test-lib' => array(
      'name' => 'My test library',
      ..
      'xautoload' => function($api) {
        // Register a namespace with PSR-0 root in <library dir>/lib/
        // Note: $api already knows the library directory.
        // Note: We could omit the 'lib', as this is the default value.
        $api->namespaceRoot('XALib\TestNamespace', 'lib');
      },
    ),
  );
}

此处将
对此进行详细说明：xautoload.api.php
有关$ api参数的更多信息。

注意：您还可以编写自己的“处理程序”，以实现除PSR-0或PEAR以外的更多奇特的老式模式。如果您需要帮助，请在xautoload队列中发布问题。

注意：注册库名称空间有多种方法。如果要在每个请求中注册名称空间，则这是最简单的。