View Source

<ac:macro ac:name="note"><ac:parameter ac:name="title">RFC Status: Implemented</ac:parameter><ac:rich-text-body>
<p>This RFC has been implemented as the Zend\Module component .</p>

<p>Please raise any issues encountered on the mailing list or on the issue tracker.</p></ac:rich-text-body></ac:macro>

<p>Following on from this <a href="http://zend-framework-community.634137.n4.nabble.com/ZF2-Modules-Ideas-td3745502.html">mailing list discussion</a>, this RFC describes how modules will work in Zend Framework 2.</p>


<h2>Guiding principles</h2>

<p>The following goals guide this RFC:</p>

<ul>
<li>Make modules as flexible as possible</li>
<li>Encourage following established ZF2 coding and naming standards in 3rd party code targetting or consuming ZF2</li>
<li>Discourage dynamic discovery in preference of installation (which should improve performance over ZF1 modular applications)</li>
<li>Encourage re-use and extension of modules</li>
</ul>


<h2>Definitions</h2>

<p>To avoid any confusion, the following definitions are used (Thanks Ralph!):</p>

<ul>
<li>An <strong>Environment</strong> is the sum of all resources, capabilities and settings that exist in a PHP process. This generally includes what extensions and ini settings are preset for the PHP process.</li>
<li>An <strong>Application</strong> is collection of code that solves a specific business problem. Ideally, applications consume libraries and components to facilitate quicker and more standardized development.</li>
<li>A <strong>Library</strong> is collection of code that solves a less specific problem which is further defined by the libraries target audience and problem area.</li>
<li>A <strong>Component</strong> is a collection of code that solves a more specific problem within a library.</li>
<li>A <strong>Module</strong> is a collection of code and other files that solves a more specific atomic problem of the larger business problem. The sum of all modules within an application attempt the solve the larger business problem.</li>
</ul>


<p>These match with what the ZF community is used to, so care should be taken when using these terms to mean anything else.</p>


<h2>What is a module?</h2>

<ul>
<li>A module is a directory (or phar archive), usually under the <code>module/</code> or <code>vendor/</code> folder, which can be named any valid name. Inside this directory can be any code at all (i.e. it could include, MVC artefacts, standalone classes, JS files, CSS files, images, etc.).</li>
<li>All class files within the module <em>should</em> be namespaced.</li>
<li>A module <em>should</em> contain a file containing a class map for use with the ClassMapAutoloader. However, classes within the module could also be loadable using PSR-0 standards via the StandardAutoloader.</li>
<li>A module tests are expected to be in a folder called test/ and be phpunit compatible.</li>
<li>A module <em>must</em> have meta data containing at least the name, version number and author information.</li>
<li>A developer <em>must</em> never have to ever change a file in a third-party module that they have installed. Instead, they will use extension, hooks and config overrides.</li>
</ul>


<h2>Installing/upgrading modules</h2>

<p>This topic has been expanded into its own RFC: <a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Module+Installation+and+Distribution">Module Installation and Distribution</a></p>

<h2>Configuration of a module</h2>

<p>Modules need two stages of configuration: </p>
<ol>
<li>Bootstrap: happens for every request.</li>
<li>Post-routing: happens only if the module is in use for this request.</li>
</ol>


<p>These requirements are covered by these points:</p>

<ul>
<li>A module <em>should</em> contain a Module class containing methods that are executed during bootstrapping by the ModuleManager. This class could do any of the following:
<ul>
<li>Provide autoloading information to added to the the application's autoloader.</li>
<li>Provide configuration information for DI, routing, views, etc. to be merged with other module's and application-level configuration.</li>
<li>Define application event listeners to register with the StaticEventManager.</li>
<li>etc. (Whatever else the developer chooses to implement!)</li>
</ul>
</li>
</ul>



<h2>Reusing/extending modules</h2>

<ul>
<li>Modules can override/extend other modules.</li>
<li>Modules <em>should</em> integrate with EventManager and provide suitable hooks for extension by other modules.</li>
<li><span style="color: red;">Anything else?</span></li>
</ul>