| blob | 085af016486c6352177edcc2b82563e819c06e3a |
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');
76 echo $config->database->params->host; // wyświetla "dev.example.com"
77 echo $config->database->params->dbname; // wyświetla "dbname"
78 ]]>
79 </programlisting>
80 </example>
81 <example id="zend.config.adapters.xml.example.attributes">
82 <title>Używanie atrybutów znaczników w Zend_Config_Xml</title>
83 <para>
84 Komponent Zend_Config_Xml obsługuje także dwa inne sposoby
85 definiowania elementów w pliku konfiguracyjnym. Oba sposoby używają
86 atrybutów. Z tego względu, że atrybuty <code>extends</code> oraz
87 <code>value</code> są zastrzeżone (do rozszerzania sekcji oraz do
88 alternatywnego sposobu użycia atrybutów), nie mogą one być użyte.
89 Pierwszym sposobem użycia atrybutu jest dodanie go w elemencie
90 rodzica. Zostanie on automatycznie przełożony jako element dziecko:
91 </para>
92 <programlisting role="xml"><![CDATA[
93 <?xml version="1.0"?>
94 <configdata>
95 <production webhost="www.example.com">
96 <database adapter="pdo_mysql">
97 <params host="db.example.com" username="dbuser" password="secret" dbname="dbname"/>
98 </database>
99 </production>
100 <staging extends="production">
101 <database>
102 <params host="dev.example.com" username="devuser" password="devsecret"/>
103 </database>
104 </staging>
105 </configdata>
106 ]]>
107 </programlisting>
108 <para>
109 Kolejny sposób tak naprawdę nie zmniejsza objętości pliku
110 konfiguracyjnego, ale ułatwia zarządzanie nim, ponieważ eliminuje
111 konieczność pisania nazw znaczników podwójnie. Po prostu tworzysz
112 pusty znacznik, który zawiera swoją wartość wewnątrz atrybutu
113 <code>value</code>:
114 </para>
115 <programlisting role="xml"><![CDATA[
116 <?xml version="1.0"?>
117 <configdata>
118 <production>
119 <webhost>www.example.com</webhost>
120 <database>
121 <adapter value="pdo_mysql"/>
122 <params>
123 <host value="db.example.com"/>
124 <username value="dbuser"/>
125 <password value="secret"/>
126 <dbname value="dbname"/>
127 </params>
128 </database>
129 </production>
130 <staging extends="production">
131 <database>
132 <params>
133 <host value="dev.example.com"/>
134 <username value="devuser"/>
135 <password value="devsecret"/>
136 </params>
137 </database>
138 </staging>
139 </configdata>
140 ]]>
141 </programlisting>
142 </example>
143 </sect1>