Zend_Config-TheoryOfOperation.xml 5.5 KB

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