1
|
<h2>Model-View-Controller design pattern</h2>
|
2
|
|
3
|
<p>
|
4
|
A Mapbuilder configuration file closely follows the Model-View-Controller (MVC)
|
5
|
design pattern.
|
6
|
There are many descriptions of the MVC design pattern
|
7
|
<a href="http://www.google.ca/search?hl=en&q=Model+View+Controller+design+pattern">available;</a>
|
8
|
a brief description of it as it applies to Mapbuilder is provided below.
|
9
|
It is a very useful design pattern for web applications because it provides
|
10
|
good separation between the information content, the presentation of that
|
11
|
information and the application state.
|
12
|
</p>
|
13
|
|
14
|
<div id="mainMapPane" style="float:right">
|
15
|
<img src="http://mapbuilder.sourceforge.net/mapbuilder/docs/design/images/mvc.gif"/>
|
16
|
</div>
|
17
|
|
18
|
<p>
|
19
|
A <span class="regbld">Model</span> represents the information of the application,
|
20
|
typically in the form of an XML document retreived from a web service or in the
|
21
|
the form of a static file at a URL.
|
22
|
Models provide "get" methods to retrieve particular pieces of information or
|
23
|
state and "set" methods to update the information and state of the model.
|
24
|
When set methods are used, views are notified of the change by calling
|
25
|
listeners that can be registered with the model.
|
26
|
</p>
|
27
|
|
28
|
<p>
|
29
|
A <span class="regbld">View</span> is a representation of the information
|
30
|
in a model.
|
31
|
Views can register themselves with a model to be notified of changes in the model
|
32
|
that may affect the view.
|
33
|
This is typically using "listener" callback methods which are called for
|
34
|
various event types.
|
35
|
Views may also provide means to send user gestures (e.g. mouse clicks) to a
|
36
|
controller.
|
37
|
In Mapbuilder, views are called widgets.
|
38
|
</p>
|
39
|
|
40
|
<p>
|
41
|
A <span class="regbld">Controller</span> translates interactions with the view
|
42
|
into actions to be performed by the model.
|
43
|
Controllers modify the information and state of a model.
|
44
|
In Mapbuilder, views are called tools.
|
45
|
</p>
|
46
|
|
47
|
<p>
|
48
|
The separation of model and view allows multiple views to use the same model.
|
49
|
Consequently, model components are easier to implement, test, and maintain,
|
50
|
since all access to the model goes through these components.
|
51
|
This also makes it easy to extend because you can simply write a view and
|
52
|
some controller logic and wire them into the existing application.
|
53
|
</p>
|
54
|
|
55
|
<p>
|
56
|
Mapbuilder can dynamically retrieve and store many different models within the
|
57
|
same web application.
|
58
|
In order to provide some structure to the various models that can be realized,
|
59
|
a model may contain an array of other models in a parent-child replationship.
|
60
|
For example, a WFS DescribeFeatureType response model can be logically represented
|
61
|
as a child of a WFS GetCapabilities model since they are initimately related.
|
62
|
</p>
|
63
|
|
64
|
<p>
|
65
|
In the Mapbuilder object-oriented design, models, widgets and tools are all
|
66
|
realized as object instances in Javascript.
|
67
|
The list of objects to be created and the relationship between them is
|
68
|
specified in the configuration file.
|
69
|
Properties are also optionally assigned to each object in the configuration file.
|
70
|
The actual objects that mapbuilder supports and the properties that can be
|
71
|
assigned to them is detailed in the <a href="docs/register">Component register.</a>
|
72
|
</p>
|
73
|
|
74
|
<p>
|
75
|
</p>
|
76
|
|
77
|
<p align="right">
|
78
|
<a href="?page=config/config">previous</a>
|
79
|
<a href="?page=config/opvRule">next</a>
|
80
|
</p>
|