Zend_Config-TheoryOfOperation.xml 5.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="zend.config.theory_of_operation">
  4. <title>Theory of Operation</title>
  5. <para>
  6. Configuration data are made accessible to the <classname>Zend_Config</classname> constructor
  7. through an associative array, which may be multi-dimensional, in order to support
  8. organizing the data from general to specific. Concrete adapter classes
  9. adapt configuration data from storage to produce the associative array for the
  10. <classname>Zend_Config</classname> constructor. User scripts may provide such arrays directly
  11. to the <classname>Zend_Config</classname> constructor, without using an adapter class, since
  12. it may be appropriate to do so in certain situations.
  13. </para>
  14. <para>
  15. Each configuration data array value becomes a property of the <classname>Zend_Config</classname> object. The key is used
  16. as the property name. If a value is itself an array, then the resulting object property is created as a new
  17. <classname>Zend_Config</classname> object, loaded with the array data. This occurs recursively, such that a hierarchy of
  18. configuration data may be created with any number of levels.
  19. </para>
  20. <para>
  21. <classname>Zend_Config</classname> implements the <code>Countable</code> and <code>Iterator</code>
  22. interfaces in order to facilitate simple access to configuration data.
  23. Thus, one may use the <ulink url="http://php.net/count"><code>count()</code></ulink>
  24. function and PHP constructs such as
  25. <ulink url="http://php.net/foreach"><code>foreach</code></ulink> with
  26. <classname>Zend_Config</classname> objects.
  27. </para>
  28. <para>
  29. By default, configuration data made available through <classname>Zend_Config</classname>
  30. are read-only, and an assignment (e.g.,
  31. <code>$config->database->host = 'example.com'</code>)
  32. results in a thrown exception. This default behavior may be overridden through the constructor,
  33. however, to allow modification of data values. Also, when modifications are allowed, <classname>Zend_Config</classname>
  34. supports unsetting of values (i.e. <code>unset($config->database->host);</code>). The
  35. <code>readOnly()</code> method can be used to determine if modifications to a given <classname>Zend_Config</classname>
  36. object are allowed and the <code>setReadOnly()</code> method can be used to stop any further
  37. modifications to a <classname>Zend_Config</classname> object that was created allowing modifications.
  38. <note>
  39. <para>
  40. It is important not to confuse such in-memory modifications with saving configuration
  41. data out to specific storage media. Tools for creating and modifying configuration
  42. data for various storage media are out of scope with respect to <classname>Zend_Config</classname>.
  43. Third-party open source solutions are readily available for the purpose of creating and
  44. modifying configuration data for various storage media.
  45. </para>
  46. </note>
  47. </para>
  48. <para>
  49. Adapter classes inherit from the <classname>Zend_Config</classname> class since they utilize its functionality.
  50. </para>
  51. <para>
  52. The <classname>Zend_Config</classname> family of classes enables configuration data to be
  53. organized into sections. <classname>Zend_Config</classname> adapter objects may be loaded
  54. with a single specified section, multiple specified sections, or all sections
  55. (if none are specified).
  56. </para>
  57. <para>
  58. <classname>Zend_Config</classname> adapter classes support a single inheritance model that
  59. enables configuration data to be inherited from one section of configuration data
  60. into another. This is provided in order to reduce or eliminate the need for
  61. duplicating configuration data for different purposes. An inheriting section
  62. may also override the values that it inherits through its parent section.
  63. Like PHP class inheritance, a section may inherit from a parent section,
  64. which may inherit from a grandparent section, and so on, but multiple inheritance
  65. (i.e., section C inheriting directly from parent sections A and B) is not supported.
  66. </para>
  67. <para>
  68. If you have two <classname>Zend_Config</classname> objects, you can merge them into a single
  69. object using the <code>merge()</code> function. For example, given <code>$config</code> and
  70. <code>$localConfig</code>, you can merge data from <code>$localConfig</code> to <code>$config</code> using
  71. <code>$config->merge($localConfig);</code>. The items in <code>$localConfig</code> will override
  72. any items with the same name in <code>$config</code>.
  73. <note>
  74. <para>
  75. The <classname>Zend_Config</classname> object that is performing the merge must have been constructed
  76. to allow modifications, by passing <code>true</code> as the second parameter of the constructor.
  77. The <code>setReadOnly()</code> method can then be used to prevent any further modifications
  78. after the merge is complete.
  79. </para>
  80. </note>
  81. </para>
  82. </sect1>
  83. <!--
  84. vim:se ts=4 sw=4 et:
  85. -->