|
1
|
<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>
|