Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="note"><ac:parameter ac:name="title">Group effort</ac:parameter><ac:rich-text-body>
<p>Feel free to edit, add, modify whatever you like ...</p></ac:rich-text-body></ac:macro>

<h2>Intro</h2>
<p>How do we want (other people) to configure (our) components? </p>
<ol>
<li><ac:link ac:anchor="style1"><ac:link-body>Array configuration</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="style2"><ac:link-body>Type hints + array configuration</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="style3"><ac:link-body>Config-classes</ac:link-body></ac:link></li>
<li><ac:link ac:anchor="style4"><ac:link-body>Type hints + config-classes</ac:link-body></ac:link></li>
</ol>

<p><ac:macro ac:name="anchor"><ac:default-parameter>style1</ac:default-parameter></ac:macro></p>
<h2>Array configuration</h2>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

]]></ac:plain-text-body></ac:macro>

<h5><span style="color: green;">The good</span></h5>
<ul>
<li>array() is php built-in type</li>
<li>popular in PHP world</li>
<li>maps easily to Zend\Config-style configuration</li>
<li>can silently ignore unknown parameters <sup>used together with adapter-pattern</sup></li>
</ul>

<h5><span style="color: red;">The bad</span></h5>
<ul>
<li>does not hint at what config params are available</li>
<li>(usually) silently ignores unknown parameters</li>
<li>validation may be performed every time instance is created <em>(note: a number of components do not validate config options but rely on native error reporting of PHP functions)</em></li>
<li>requires multiple accessors to manage all config options <em>(note from Matthew: depends on the architecture of the component; not all delegate to accessors)</em></li>
<li>not all config options can be modified at runtime because of lack of accessors (if forgotten/omitted deliberately)</li>
<li>no way to enforce hard-dependencies at language level (inter-component)</li>
<li>Requires accessors to change or read configuration (even for simple, not validated scalar values)</li>
<li>Accessor dependence can result in injecting configured objects into their depedencies to share configuration (breaches single responsibility principle/separation of concerns and Law of Demeter).</li>
</ul>

<p><br class="atl-forced-newline" />
<br class="atl-forced-newline" />
<br class="atl-forced-newline" />
<br class="atl-forced-newline" /></p>

<p><ac:macro ac:name="anchor"><ac:default-parameter>style2</ac:default-parameter></ac:macro></p>
<h2>Type hints + array configuration</h2>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

]]></ac:plain-text-body></ac:macro>

<h5><span style="color: green;">The good</span> </h5>
<ul>
<li>hard-dependencies can be enforced at compiler-level</li>
<li><span style="color: gray;">hinting of config parameters in IDEs (even with detailed usage info)</span></li>
<li><span style="color: gray;">all config-parameters are named and can be given default values</span></li>
<li><span style="color: gray;">config-classes can be subclassed to introduce defaults (or some custom processing)</span></li>
<li><span style="color: gray;">validation is performed by config class, not functional class (SoC)</span></li>
<li><span style="color: gray;">validation is performed once per config (as opposed to once per instance)</span></li>
<li><span style="color: gray;">configuration can be referred (shared) among instances</span></li>
<li><span style="color: gray;">backward-compatible with array configuration</span></li>
<li><span style="color: gray;">easier documentation generation</span></li>
<li><span style="color: gray;">DI-friendly</span></li>
<li><span style="color: gray;">Can be treated as a generic "parameter bag" (configuration not necessarily bound to one object alone. e.g. shareable with adapters).</span></li>
<li><span style="color: gray;">Supports both access styles: public params (which are simple, fast) and setters (if validation is required) (<a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+better+configuration+for+components">examples here</a>)</span></li>
</ul>

<h5><span style="color: red;">The bad</span></h5>
<ul>
<li>component will refuse to work without satisfying hard-dependencies <sup>(no way to include "default adapter" without Dependency Injection)</sup></li>
<li><span style="color: gray;">more memory required per-configuration blob</span></li>
<li><span style="color: gray;">increased code verbosity compared to arrays if using object setters/getters (though this is the same scenario if using setters/getters on the created main object)</span></li>
</ul>

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