knut 2005/02/06 14:15:50
Modified: src/documentation/content/xdocs configurations.xml
Log:
Added example for mapped configurations.
Revision Changes Path
1.14 +42 -15
jakarta-hivemind/src/documentation/content/xdocs/configurations.xml
Index: configurations.xml
===================================================================
RCS file:
/home/cvs/jakarta-hivemind/src/documentation/content/xdocs/configurations.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- configurations.xml 31 Jan 2005 10:10:54 -0000 1.13
+++ configurations.xml 6 Feb 2005 22:15:50 -0000 1.14
@@ -27,7 +27,7 @@
<body>
<p>A central concept in HiveMind is <em>configuration extension
points</em>.
Once you have a set of services, it's natural to want
to configure those
- services. In HiveMind, a configuration point contains
an unordered list of
+ services. In HiveMind, a configuration point contains
an unordered collection of
<em>elements</em>. Each element is contributed by a
module ... any module
may make contributions to any configuration point
visible to it.</p>
<p>There is no explicit connection between a service and a
configuration
@@ -82,7 +82,7 @@
<schema>
<element name="datum">
<attribute name="key" required="true"/>
- <attriute name="value" required="true"/>
+ <attribute name="value" required="true"/>
<conversion class="hivemind.test.config.impl.Datum"/>
</element>
@@ -114,15 +114,13 @@
the exact same schema. By assigning an
id attribute to a &_schema;
element, you may reference the same
schema for multiple configuration
points. For example, the
&hivemind.FactoryDefaults; and &hivemind.ApplicationDefaults;
- configuration points use the same
schema. The hivemind module
+ configuration points use the same
schema. The HiveMind module
deployment descriptor accomplishes this
by defining a schema for one
configuration point, then referencing
it from another:</p>
<source><![CDATA[
<schema id="Defaults">
<element name="default">
-
. . .
-
</element>
</schema>
@@ -156,16 +154,9 @@
</invoke-factory>
</service-point>]]></source>
- <p>As mentioned it is also possible to have the
configuration contributions
- injected as a Map. This requires the schema to
define the attribute of
- the top-level elements which should be used as
the key for the objects
- in the map. This is specified using
&_element;'s <code>key-attribute</code>
- attribute. The identified key attribute is
implicitly marked as
- <em>required</em> and <em>unique</em>. Further
it is the <em>translated</em>
- attribute value which is used as the key in the
map.</p>
- <p>The list / map of elements is always injected as an
<em>unmodifiable</em>
- collection. An empty list / map may be
injected, but never
- <code>null</code>.</p>
+ <p>The collection of configuration elements is always
injected as an
+ <em>unmodifiable</em> collection. An empty list
/ map may be injected,
+ but never <code>null</code>.</p>
<p>The order of the elements in the list is not
defined. If order is
important, you should create a new (modifiable)
list from the injected
list and sort it.</p>
@@ -179,6 +170,42 @@
information contained in a configuration as an
unordered list. A best
practice is to always access the configuration
through a service, which
can organize and validate the data in the
configuration.</note>
+
+ <section>
+ <title>Accessing Configurations as a Map</title>
+ <p>As mentioned it is also possible to have the
configuration contributions
+ injected as a Map. This requires the
schema to define the attribute of
+ the top-level elements which should be
used as the key for the elements
+ in the map. This is specified using
&_element;'s <code>key-attribute</code>
+ attribute. The identified key attribute
is implicitly marked as
+ <em>required</em> and
<em>unique</em>.</p>
+ <p>So the previous configuration point
<em>Simple</em> can also be defined as
+ follows:</p>
+
+ <source><![CDATA[
+<configuration-point id="Simple">
+ <schema>
+ <element name="datum" key-attribute="key">
+ <attribute name="key"/>
+ <attribute name="value" required="true"/>
+
+ <rules>
+ <push-attribute attribute="value"/>
+ <invoke-parent method="addElement"/>
+ </rules>
+ </element>
+ </schema>
+</configuration-point>]]></source>
+
+ <p>The resulting configuration point is now
accessible as a Map, where the
+ translated value of the
<code>key</code> attribute is the key and the
+ translated value of the
<code>value</code> attribute is the value of the
+ Map.Entry elements.</p>
+ <note>It is also possible to access the
elements of this configuration point as
+ a List, but the elements therein are
now the objects (in this case Strings)
+ created by the &_push-attribute;
rule.</note>
+ </section>
+
</section>
<section>
<title>Lazy Loading</title>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
