1 |
3032
|
perry
|
<h2>Config file structure</h2>
|
2 |
|
|
|
3 |
|
|
<p>
|
4 |
|
|
A Mapbuilder configuration document follows the Object-Property-Value
|
5 |
|
|
rule which is borrowed from RDF and GML3.
|
6 |
|
|
As a rule of thumb, this means that elements in the config file
|
7 |
|
|
alternate between UpperCamelCase and lowerCamelCase,
|
8 |
|
|
UpperCamelCase is for objects and lowerCamelCase is for properties.
|
9 |
|
|
An object can only contain another object through a property value and the
|
10 |
|
|
property name should reflect the relationship or role that the
|
11 |
|
|
contained Object plays.
|
12 |
|
|
</p>
|
13 |
|
|
|
14 |
|
|
<p>
|
15 |
|
|
A more complete description of the object-property-value rule
|
16 |
|
|
can be found in section 2.1 of the document:
|
17 |
|
|
<a href="http://www.geoconnections.org/developersCorner/devCorner_devNetwork/components/GML_bpv1.3_E.pdf">
|
18 |
|
|
Developing and Managing GML Application Schemas</a>
|
19 |
|
|
</p>
|
20 |
|
|
|
21 |
|
|
<p>
|
22 |
|
|
The benefits of using this naming convention is that it clearly distinguishes
|
23 |
|
|
between Objects and their properties.
|
24 |
|
|
Objects in the configuration file map directly to Mapbuilder Javascript objects
|
25 |
|
|
and it makes the configuration file much easier to parse.
|
26 |
|
|
</p>
|
27 |
|
|
|
28 |
|
|
<p>
|
29 |
|
|
Practically all object properties are optional.
|
30 |
|
|
</p>
|
31 |
|
|
|
32 |
|
|
<p>
|
33 |
|
|
In addition to simple properties, Models may have <models>, <widgets>
|
34 |
|
|
and <tools> properties which list the objects of those types that act
|
35 |
|
|
on that model.
|
36 |
|
|
A Model object will therefore look like:
|
37 |
|
|
</p>
|
38 |
|
|
<pre>
|
39 |
|
|
<Model_a>
|
40 |
|
|
<property_1>pvalue</property_1>
|
41 |
|
|
<property_2>pvalue</property_2>
|
42 |
|
|
...
|
43 |
|
|
<models>
|
44 |
|
|
...(model objects)...
|
45 |
|
|
</models>
|
46 |
|
|
<widgets>
|
47 |
|
|
...(widget objects)...
|
48 |
|
|
</widgets>
|
49 |
|
|
<tools>
|
50 |
|
|
...(tool objects)...
|
51 |
|
|
</tools>
|
52 |
|
|
</Model_a>
|
53 |
|
|
</pre>
|
54 |
|
|
|
55 |
|
|
<p>
|
56 |
|
|
Widgets and Tools only contain simple property values, so these will look like:
|
57 |
|
|
</p>
|
58 |
|
|
<pre>
|
59 |
|
|
<Widget_i>
|
60 |
|
|
<property_1>pvalue</property_1>
|
61 |
|
|
<property_2>pvalue</property_2>
|
62 |
|
|
...
|
63 |
|
|
</Widget_i>
|
64 |
|
|
</pre>
|
65 |
|
|
<p>
|
66 |
|
|
and:
|
67 |
|
|
</p>
|
68 |
|
|
<pre>
|
69 |
|
|
<Tool_x>
|
70 |
|
|
<property_1>pvalue</property_1>
|
71 |
|
|
<property_2>pvalue</property_2>
|
72 |
|
|
...
|
73 |
|
|
</Tool_x>
|
74 |
|
|
</pre>
|
75 |
|
|
|
76 |
|
|
<p>
|
77 |
|
|
Keeping in mind that the config is itself a Model object,
|
78 |
|
|
the basic structure of a Mapbuilder configuration file will look like this:
|
79 |
|
|
</p>
|
80 |
|
|
<pre>
|
81 |
|
|
<MapbuilderConfig>
|
82 |
|
|
<property_1>pvalue</property_1>
|
83 |
|
|
<property_2>pvalue</property_2>
|
84 |
|
|
...
|
85 |
|
|
<models>
|
86 |
|
|
<Model_a>...</Model_a>
|
87 |
|
|
<Model_b>...</Model_b>
|
88 |
|
|
...
|
89 |
|
|
</models>
|
90 |
|
|
<widgets>
|
91 |
|
|
<Widget_i>...</Widget_i>
|
92 |
|
|
<Widget_j>...</Widget_j>
|
93 |
|
|
...
|
94 |
|
|
</widgets>
|
95 |
|
|
<tools>
|
96 |
|
|
<Tool_x>...</Tool_x>
|
97 |
|
|
<Tool_y>...</Tool_y>
|
98 |
|
|
</tools>
|
99 |
|
|
</MapbuilderConfig>
|
100 |
|
|
</pre>
|
101 |
|
|
|
102 |
|
|
<p>
|
103 |
|
|
The actual objects that mapbuilder supports and the properties that can be
|
104 |
|
|
assigned to them is detailed in the <a href="docs/register">Component register.</a>
|
105 |
|
|
</p>
|
106 |
|
|
|
107 |
|
|
<p align="right">
|
108 |
|
|
<a href="?page=config/mvc">previous</a>
|
109 |
|
|
<a href="?page=config/patterns">next</a>
|
110 |
|
|
</p>
|