Zend_Config_Xml.xml 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143
  1. <sect1 id="zend.config.adapters.xml">
  2. <title>Zend_Config_Xml</title>
  3. <para>
  4. <code>Zend_Config_Xml</code> pozwala programistom przechowywać dane
  5. konfiguracyjne w prostym formacie XML a następnie odczytywać je w aplikacji
  6. używając składni zagnieżdżonych właściwości obiektów. Nazwa głównego elementu
  7. pliku XML jest nieistotna i może być dowolna. Pierwsze poziomy elementów
  8. XML odpowiadają sekcjom danych konfiguracyjnych. Format XML obsługuje
  9. hierarchiczne zorganizowanie za pomocą zagnieżdżania elementów XML wewnątrz
  10. elementów poziomu sekcji. Zawartość najbardziej zagnieżdżonego elementu
  11. XML odpowiada wartości danej konfiguracyjnej. Dziedziczenie sekcji jest
  12. obsługiwane za pomocą specjalnego atrybutu XML nazwanego <code>extends</code>,
  13. a wartość tego atrybutu odpowiada nazwie sekcji, której dane mają być
  14. odziedziczone przez rozszerzającą sekcję.
  15. </para>
  16. <note>
  17. <title>Zwracany typ</title>
  18. <para>
  19. Dane konfiguracyjne odczytywane przez <code>Zend_Config_Xml</code> są
  20. zawsze zwracane jako łańcuchy znaków. Konwersja danych z łańcuchów znaków
  21. do innych typów leży w gestii programistów, którzy mogą dopasować to
  22. do własnych potrzeb.
  23. </para>
  24. </note>
  25. <example id="zend.config.adapters.xml.example.using">
  26. <title>Użycie Zend_Config_Xml</title>
  27. <para>
  28. Ten przykład pokazuje podstawowe użycie klasy <code>Zend_Config_Xml</code>
  29. do ładowania danych konfiguracyjnych z pliku XML. W tym przykładzie
  30. znajdują się dane konfiguracyjne zarówno dla systemu produkcyjnego
  31. jak i dla systemu rozbudowywanego. Z tego względu, że dane
  32. konfiguracyjne systemu rozbudowywanego są bardzo podobne do tych dla
  33. systemu produkcyjnego, sekcja systemu rozbudowywanego dziedziczy po
  34. sekcji systemu produkcyjnego. W tym przypadku decyzja jest dowolna
  35. i mogłoby to być zrobione odwrotnie, z sekcją systemu produkcyjnego
  36. dziedziczącą po sekcji systemu rozbudowywanego, chociaż nie może to
  37. być przykładem dla bardziej złożonych sytuacji. Załóżmy, że poniższe
  38. dane konfiguracyjne znajdują się w pliku <code>/path/to/config.xml</code>:
  39. </para>
  40. <programlisting role="xml"><![CDATA[
  41. <?xml version="1.0"?>
  42. <configdata>
  43. <production>
  44. <webhost>www.example.com</webhost>
  45. <database>
  46. <adapter>pdo_mysql</adapter>
  47. <params>
  48. <host>db.example.com</host>
  49. <username>dbuser</username>
  50. <password>secret</password>
  51. <dbname>dbname</dbname>
  52. </params>
  53. </database>
  54. </production>
  55. <staging extends="production">
  56. <database>
  57. <params>
  58. <host>dev.example.com</host>
  59. <username>devuser</username>
  60. <password>devsecret</password>
  61. </params>
  62. </database>
  63. </staging>
  64. </configdata>
  65. ]]>
  66. </programlisting>
  67. <para>
  68. Następnie załóżmy, że programista aplikacji potrzebuje danych
  69. konfiguracyjnych aplikacji rozbudowywanej z pliku XML. Prostą 
  70. sprawą jest załadowanie tych danych określając plik XML oraz
  71. sekcję dla aplikacji rozbudowywanej:
  72. </para>
  73. <programlisting role="php"><![CDATA[
  74. $config = new Zend_Config_Xml('/path/to/config.xml', 'staging');
  75. echo $config->database->params->host; // wyświetla "dev.example.com"
  76. echo $config->database->params->dbname; // wyświetla "dbname"
  77. ]]>
  78. </programlisting>
  79. </example>
  80. <example id="zend.config.adapters.xml.example.attributes">
  81. <title>Używanie atrybutów znaczników w Zend_Config_Xml</title>
  82. <para>
  83. Komponent Zend_Config_Xml obsługuje także dwa inne sposoby
  84. definiowania elementów w pliku konfiguracyjnym. Oba sposoby używają
  85. atrybutów. Z tego względu, że atrybuty <code>extends</code> oraz
  86. <code>value</code> są zastrzeżone (do rozszerzania sekcji oraz do
  87. alternatywnego sposobu użycia atrybutów), nie mogą one być użyte.
  88. Pierwszym sposobem użycia atrybutu jest dodanie go w elemencie
  89. rodzica. Zostanie on automatycznie przełożony jako element dziecko:
  90. </para>
  91. <programlisting role="xml"><![CDATA[
  92. <?xml version="1.0"?>
  93. <configdata>
  94. <production webhost="www.example.com">
  95. <database adapter="pdo_mysql">
  96. <params host="db.example.com" username="dbuser" password="secret" dbname="dbname"/>
  97. </database>
  98. </production>
  99. <staging extends="production">
  100. <database>
  101. <params host="dev.example.com" username="devuser" password="devsecret"/>
  102. </database>
  103. </staging>
  104. </configdata>
  105. ]]>
  106. </programlisting>
  107. <para>
  108. Kolejny sposób tak naprawdę nie zmniejsza objętości pliku
  109. konfiguracyjnego, ale ułatwia zarządzanie nim, ponieważ eliminuje
  110. konieczność pisania nazw znaczników podwójnie. Po prostu tworzysz
  111. pusty znacznik, który zawiera swoją wartość wewnątrz atrybutu
  112. <code>value</code>:
  113. </para>
  114. <programlisting role="xml"><![CDATA[
  115. <?xml version="1.0"?>
  116. <configdata>
  117. <production>
  118. <webhost>www.example.com</webhost>
  119. <database>
  120. <adapter value="pdo_mysql"/>
  121. <params>
  122. <host value="db.example.com"/>
  123. <username value="dbuser"/>
  124. <password value="secret"/>
  125. <dbname value="dbname"/>
  126. </params>
  127. </database>
  128. </production>
  129. <staging extends="production">
  130. <database>
  131. <params>
  132. <host value="dev.example.com"/>
  133. <username value="devuser"/>
  134. <password value="devsecret"/>
  135. </params>
  136. </database>
  137. </staging>
  138. </configdata>
  139. ]]>
  140. </programlisting>
  141. </example>
  142. </sect1>