interface/modules/zend_modules/library/Zend/ModuleManager/README.md

   1 ModuleManager Component from ZF2
   2 ================================
   3
   4 This is the ModuleManager component for ZF2.
   5
   6 - File issues at https://github.com/zendframework/zf2/issues
   7 - Create pull requests against https://github.com/zendframework/zf2
   8 - Documentation is at http://framework.zend.com/docs
   9
  10 LICENSE
  11 -------
  12
  13 The files in this archive are released under the [Zend Framework
  14 license](http://framework.zend.com/license), which is a 3-clause BSD license.
  15
  16 Description
  17 -----------
  18 This is a module loader and manager for ZF2.
  19
  20 Currently Implemented
  21 ---------------------
  22
  23 * **Phar support:**
  24   Modules can be packaged, distributed, installed, and ran as phar archives.
  25   Supports both executable and non-executable archives; with and without a stub.
  26   `Module` class must be made available by either Module.php in the root of the
  27   phar or in the stub if it is an executable phar. Below is a list of phar
  28   archive/compression formats that are supported and their respective extensions,
  29   as detected by the module loader:
  30     * **Executable** (can be included directly, which executes stub):
  31         * phar (.phar)
  32         * phar + gz  (.phar.gz)
  33         * phar + bz2 (.phar.bz2)
  34         * tar (.phar.tar)
  35         * tar + gz (.phar.tar.gz)
  36         * tar + bz2 (.phar.tar.bz2)
  37         * zip (.zip)
  38     * **Non-executable** (phar cannot be included directly; no stub can be set):
  39         * tar (.tar)
  40         * tar + gz (.tar.gz)
  41         * tar + bz2 (.tar.bz2)
  42         * zip (.zip)
  43 * **Configuration merging:**
  44     The module manager goes through each enabled module, loads its
  45     `Zend\Config\Config` object via the `getConfig()` method of the respective
  46     `Module` class; merging them into a single configuration object to be passed
  47     along to the bootstrap class, which can be defined inthe config of course!
  48 * **Caching merged configuration:**
  49     To avoid the overhead of loading and merging the configuration of each
  50     module for every execution, the module manager supports caching the merged
  51     configuration as an array via `var_export()`. Subsequent requests will bypass
  52     the entire configuration loading/merging process, nearly eliminating any
  53     configuration-induced overhead.
  54 * **Module init():**
  55     The module manager calls on the `init()` method on the `Module` class of
  56     each enabled module, passing itself as the only parameter. This gives
  57     modules a chance to register their own autoloaders or perform any other
  58     initial setup required. **Warning:** The `init()` method is called for every
  59     enabled module for every single request. The work it performs should be kept
  60     to an absolute minimum (such as registering a simple classmap autoloader).
  61 * **100% unit test coverage:**
  62     Much effort has been put into extensive unit testing of the module loader
  63     and manager. In addition to covering every line of code, further effort was
  64     made to test other use-cases such as nested/sub-modules and various other
  65     behaviors.
  66 * **Module Dependency**
  67     Refactored to now allow self resolution of dependencies. Now provides better access
  68     to all provisions & dependencies within an application. This is opt-in with
  69     the enable_dependency_check option. Modules can declare dependencies on
  70     other modules (and versions of the required modules).
  71
  72 Stuff that still needs work:
  73 ----------------------------
  74
  75 * How to expire the merged config cache in production and/or development.
  76 * ~~Ability for modules to cleanly "share" resources? For example, you have 5 module which all use a database connection (or maybe two: master for writes, slave for reads).~~ Update: see [this thread](http://zend-framework-community.634137.n4.nabble.com/Sharing-resources-across-3rd-party-modules-td3875023.html) on the zf-contributor mailing list.
  77 * How can modules use varying view templating types? For example, one module uses twig, another uses smarty, another mustache, and yet another uses phtml. Does it make sense to have modules for each template library or system, then modules can just declare the respective one as a dependency?
  78 * How to handle static assets such as images, js, and css files ([assetic](https://github.com/kriswallsmith/assetic) has been suggested).
  79 * ~~Should dependencies also be resolved outside of the distribution channel (such as pyrus) to better handle manual / alternate installation methods?~~ [SOLVED]
  80 * Should we, and if so, how would we handle DB schemas for installation, update/migrations, and uninstallation of modules?
  81 * When a module is uninstalled, what's removed, what should stay? Do we put the responsibility of uninstallation in the hands of each module developer?
  82 * When a module is uninstalled, should it check for other modules that are still depending on it? How much is too much, and when do we just leave it up to the developers?