Loading Plugins

A number of Zend Framework components are pluggable, and allow loading
of dynamic functionality by specifying a class prefix and path to class
files that are not necessarily on the include_path or do
not necessarily follow traditional naming conventions.
Zend_Loader_PluginLoader provides common functionality for
this process.

The basic usage of the PluginLoader follows Zend Framework
naming conventions of one class per file, using the underscore as a
directory separator when resolving paths. It allows passing an optional
class prefix to prepend when determining if a particular plugin class is
loaded. Additionally, paths are searched in LIFO order. Due to the LIFO
search and the class prefixes, this allows you to define namespaces for your
plugins, and thus override plugins from paths registered earlier.

Basic Use Case

First, let's assume the following directory structure and class
files, and that the top level directory and library directory are on
the include_path:

Note:
In some cases, you may use the same prefix for multiple paths.
Zend_Loader_PluginLoader actually registers an
array of paths for each given prefix; the last one registered
will be the first one checked. This is particularly useful if
you are utilizing incubator components.

Note: Paths may be defined at instantiation
You may optionally provide an array of prefix / path pairs (or
prefix / paths -- plural paths are allowed) as a parameter to
the constructor:

Zend_Loader_PluginLoader also optionally allows you to
share plugins across plugin-aware objects, without needing to
utilize a singleton instance. It does so via a static registry.
Indicate the registry name at instantiation as the second parameter
to the constructor:

Other components that instantiate the PluginLoader
using the same registry name will then have access to already loaded
paths and plugins.

Manipulating Plugin Paths

The example in the previous section shows how to add paths to a
plugin loader. What if you want to determine the paths already
loaded, or remove one or more?

getPaths($prefix = null) returns all paths as
prefix / path pairs if no $prefix is provided,
or just the paths registered for a given prefix if a
$prefix is present.

clearPaths($prefix = null) will clear all
registered paths by default, or only those associated with a
given prefix, if the $prefix is provided and
present in the stack.

removePrefixPath($prefix, $path = null) allows
you to selectively remove a specific path associated with a
given prefix. If no $path is provided, all
paths for that prefix are removed. If a $path
is provided and exists for that prefix, only that path will
be removed.

Testing for Plugins and Retrieving Class Names

Sometimes you simply want to determine if a plugin class has been
loaded before you perform an action. isLoaded() takes a
plugin name, and returns the status.

Another common use case for the PluginLoader is to
determine fully qualified plugin class names of loaded classes;
getClassName() provides this functionality. Typically,
this would be used in conjunction with isLoaded():

Getting Better Performance for Plugins

Plugin loading can be an expensive operation. At its heart, it needs
to loop through each prefix, then each path on the prefix, until it
finds a file that matches -- and which defines the class expected.
In cases where the file exists but does not define the class, an
error will be added to the PHP error stack, which is also an
expensive operation. The question then turns to: how can you keep
the flexibility of plugins and also address performance?

Zend_Loader_PluginLoader offers an opt-in feature for
just this situation, a class file include cache. When enabled, it
will create a file that contains all successful includes which you
can then call from your bootstrap. Using this strategy, you can
greatly improve the performance of your production servers.

Example #1 Using the PluginLoader class file include cache

To use the class file include cache, simply drop the
following code into your bootstrap: