Skip to end of metadata
Go to start of metadata

<h2>Best configuration style for ZF2 components (brainstorm)</h2>
<p>Much have been said about why ZF1 components' are hard to understand and configure without a manual. Additionally, php 5.3 and maturing developers' environment have brought us new tools and ideas on how configuration can be improved.</p>

<p>This discussion will revolve around <a href="http://framework.zend.com/wiki/display/ZFDEV2/Comparison+of+config+styles">Comparison of Config Styles</a>.<br />
The goal is to set up a new ZF2 standard that will be propagated to all current and future components.</p>

<ul>
<li>Did we miss any configuration style?</li>
<li>How other large framework-like projects handle configuration?</li>
<li>Which config style solves most problems?</li>
<li>Which config style is easiest to learn?</li>
<li>Which config style is easiest to implement?</li>
<li>Should configuration be independent of DI? <sup>(can I configure any ZF2 component without using <code>Zend\Di</code>)</sup></li>
</ul>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Component configuration style - Should we discuss this?
Choices Your Vote Current Result: (0 Total Votes) Voters

Yes

(0 votes, 0%)

No

(0 votes, 0%)
All voters:
]]></ac:plain-text-body></ac:macro>

<h2>The fate of "extra" components</h2>
<p>There will be a group of components that do not fit into <strong>Core</strong> nor <strong>MVC</strong> category.</p>
<ul>
<li>Should those be packaged as modules and downloaded by users on-demand?</li>
<li>Should those be packaged together and distributed on Zend Framework website?</li>
<li>Should they live in <code>Zend</code> or in separate namespace? (<code>ZendExtras</code> <code>ZendX</code> ?)</li>
</ul>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Fate of extras - Should we discuss this?
Choices Your Vote Current Result: (0 Total Votes) Voters

Yes

(0 votes, 0%)

No

(0 votes, 0%)
All voters:
]]></ac:plain-text-body></ac:macro>

<h2>Module Manager goals</h2>
<p>Modules are a great way to encapsulate smaller and bigger chunks of reusable code. Modules will be installable on-demand, will be able to depend on each other and extend other modules' capabilities. For this logic we are proposing a module manager component which will take care of that. Below are some goals, proposed by me (Arthur B.) that could be manager's responsibilities. We should discuss this list and add/remove accordingly.</p>

<p>Module Manager goals, functionality:</p>
<ol>
<li>Handle multiple installation methods (Pear/Pyrus package, a phar/zip/tar archive fetched via http/ftp, repo fetched via git/svn)</li>
<li>Handle multiple installation sources (a directory with module's files, Pear/Pyrus repo, Git repo/submodule)</li>
<li>Handle two installation styles: "local installation" and "shared-dir installation".</li>
<li>Perform on-demand loading of modules (via call or combined with spl autoloader)</li>
<li>Handle discovering, registering, loading and merging of:
<ul>
<li>Classmaps / php classes</li>
<li>its own configuration</li>
<li>other module's configuration (i.e. user module provides config for Database?)</li>
<li>EventManager events (which can be listened to by other modules)</li>
<li>DB schemas</li>
<li>DB schemas diff files (assuming <code>alter table</code> is implemented in <code>Db</code>)</li>
<li>MVC routes <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
<li>MVC pages/navigation <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
<li>MVC actions/controllers <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
<li>MVC action helpers/plugins <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
<li>MVC view scripts <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
<li>MVC view helpers/plugins <span style="color: gray;"><sup>(if MVC module is registered)</sup></span></li>
</ul>
</li>
<li>Manage static assets (module's directory is immutable, its assets are copied/linked to application's main <code>public/</code>)</li>
<li>Handle modules registry</li>
<li>Handle <strong>simple</strong> module dependencies <sup>(those which have not been not handled by Pear/Pyrus, i.e. via manual installation)</sup></li>
<li>Respond to registry queries (<code>hasModule()</code> <code>isLoaded()</code> <code>getModuleVersion()</code> <code>provides()</code> etc.)</li>
</ol>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Module Manager's goals - Should we discuss this?
Choices Your Vote Current Result: (0 Total Votes) Voters

Yes

(0 votes, 0%)

No

(0 votes, 0%)
All voters:
]]></ac:plain-text-body></ac:macro>

<h2>Directory structure for packaging and arranging modules' files</h2>
<p>For the sake of consistency, we need a pattern for naming directories inside module's dir.</p>
<ul>
<li>What should it be?</li>
<li>Can the Module\Manager assume and look for files in those dirs by default?</li>
<li>Can those dirs be changed/replaced by module's config?</li>
</ul>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Directory structure for modules - Should we discuss this?
Choices Your Vote Current Result: (0 Total Votes) Voters

Yes

(0 votes, 0%)

No

(0 votes, 0%)
All voters:
]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.