@vertigis/viewer-spec 58.9.0 → 58.9.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +4 -4
- package/README.md +3 -3
- package/docs/Geocortex Apps.md +311 -311
- package/docs/layout-spec.md +731 -731
- package/docs/presentation.md +105 -105
- package/layout/schema/layout-common.xsd +1240 -1240
- package/layout/schema/layout-mobile.xsd +263 -263
- package/layout/schema/layout-web.xsd +431 -431
- package/layout/schema/schema-reference-example.xml +15 -15
- package/messaging/schema/common-action.schema.json +5 -5
- package/messaging/schema/mobile-action.schema.json +6 -6
- package/messaging/schema/web-action.schema.json +17 -17
- package/package.json +82 -82
- package/version.d.ts +1 -1
- package/version.js +1 -1
package/LICENSE
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
|
-
VertiGIS North America Ltd. ("VERTIGIS NA") hereby grants You, free of charge, a personal, non-exclusive, nontransferable, license to access and use this software and associated documentation files (the "Software") for development purposes only. You shall not deploy the Software into production or use for revenue generating purposes. If You wish to deploy the Software into production, then the use of the Software shall be governed by VERTIGIS NA's Master License Agreement, which can be found at www.geocortex.com/legal and shall supersede all other terms of use.
|
|
2
|
-
|
|
3
|
-
You shall include copyright and this permission notice in all copies or works involving the Software.
|
|
4
|
-
|
|
1
|
+
VertiGIS North America Ltd. ("VERTIGIS NA") hereby grants You, free of charge, a personal, non-exclusive, nontransferable, license to access and use this software and associated documentation files (the "Software") for development purposes only. You shall not deploy the Software into production or use for revenue generating purposes. If You wish to deploy the Software into production, then the use of the Software shall be governed by VERTIGIS NA's Master License Agreement, which can be found at www.geocortex.com/legal and shall supersede all other terms of use.
|
|
2
|
+
|
|
3
|
+
You shall include copyright and this permission notice in all copies or works involving the Software.
|
|
4
|
+
|
|
5
5
|
You acknowledge and agree that Software is provided AS IS and that VERTIGIS NA makes no representations and expressly disclaims any and all warranties of any kind, express or implied, including, but not limited to, any warranties regarding merchantability, fitness for a particular purpose, and noninfringement of intellectual property. In no event shall VERTIGIS NA be liable for any claim, damages, or other liability, whether in contract, tort, or other causes of action, arising from, out of, or in connection with the Software or use or other dealings with the Software. You shall bear all risk and liability regarding Your use of the Software and expressly acknowledge and agree that Your use of the Software is at Your own risk. You shall comply with all applicable laws.
|
package/README.md
CHANGED
|
@@ -1,3 +1,3 @@
|
|
|
1
|
-
# VertiGIS Viewer Specification
|
|
2
|
-
|
|
3
|
-
This package contains specifications for app config JSON, layout XML, and a reference of all commands, operations, and events for VertiGIS Studio Web and Mobile. For more information on extending these products, visit our [Developer Center](https://developers.vertigisstudio.com).
|
|
1
|
+
# VertiGIS Viewer Specification
|
|
2
|
+
|
|
3
|
+
This package contains specifications for app config JSON, layout XML, and a reference of all commands, operations, and events for VertiGIS Studio Web and Mobile. For more information on extending these products, visit our [Developer Center](https://developers.vertigisstudio.com).
|
package/docs/Geocortex Apps.md
CHANGED
|
@@ -1,311 +1,311 @@
|
|
|
1
|
-
# VertiGIS Studio Apps
|
|
2
|
-
|
|
3
|
-
## Introduction
|
|
4
|
-
|
|
5
|
-
A VertiGIS Studio App is a JSON document containing configuration for an application
|
|
6
|
-
that is built on top of the ArcGIS Extensions API. Building on the Esri Web Map
|
|
7
|
-
Specification, VertiGIS Studio Apps enable a declarative approach to working with the
|
|
8
|
-
VertiGIS and Esri APIs. Rather than initializing the properties of API objects
|
|
9
|
-
programmatically in code, you can define all of their settings externally in an
|
|
10
|
-
App JSON document. Then, you can access the configured objects via the
|
|
11
|
-
`AppContainer` class. Here is an example VertiGIS Studio App containing a map
|
|
12
|
-
extension and a menu:
|
|
13
|
-
|
|
14
|
-
```
|
|
15
|
-
{
|
|
16
|
-
"schemaVersion": "1.0",
|
|
17
|
-
"items": [
|
|
18
|
-
{
|
|
19
|
-
"$type": "map-extension",
|
|
20
|
-
"id": "default",
|
|
21
|
-
"title": "LA County",
|
|
22
|
-
"webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
|
|
23
|
-
},
|
|
24
|
-
{
|
|
25
|
-
"$type": "menu",
|
|
26
|
-
"id": "i-want-to",
|
|
27
|
-
"items": [
|
|
28
|
-
{
|
|
29
|
-
"id": "zoom-in",
|
|
30
|
-
"title": "Zoom In"
|
|
31
|
-
},
|
|
32
|
-
{
|
|
33
|
-
"id": "zoom-out",
|
|
34
|
-
"title": "Zoom Out"
|
|
35
|
-
}
|
|
36
|
-
]
|
|
37
|
-
}
|
|
38
|
-
]
|
|
39
|
-
}
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
In code, you would then access the items defined in this App like so:
|
|
43
|
-
|
|
44
|
-
```
|
|
45
|
-
const appJson = ... // Load the JSON from somewhere.
|
|
46
|
-
const container = new AppContainer(appJson);
|
|
47
|
-
const mapX = await container.get("map-extension", "default");
|
|
48
|
-
const iwtm = await container.get("menu", "i-want-to");
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
With the exception of a few special App properties like `$type`, the JSON for
|
|
52
|
-
each item uses the same schema that is supported by the constructor for the
|
|
53
|
-
corresponding API object. For example, this produces the same end result as the
|
|
54
|
-
above code:
|
|
55
|
-
|
|
56
|
-
```
|
|
57
|
-
const mapX = new MapExtension({
|
|
58
|
-
"id": "default",
|
|
59
|
-
"title": "LA County",
|
|
60
|
-
"webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
|
|
61
|
-
});
|
|
62
|
-
const iwtm = new Menu({
|
|
63
|
-
"id": "i-want-to",
|
|
64
|
-
"items": [
|
|
65
|
-
{
|
|
66
|
-
"id": "zoom-in",
|
|
67
|
-
"title": "Zoom In"
|
|
68
|
-
},
|
|
69
|
-
{
|
|
70
|
-
"id": "zoom-out",
|
|
71
|
-
"title": "Zoom Out"
|
|
72
|
-
}
|
|
73
|
-
]
|
|
74
|
-
});
|
|
75
|
-
```
|
|
76
|
-
|
|
77
|
-
## App Items
|
|
78
|
-
|
|
79
|
-
The `items` property of an App contains the set of configured items for an
|
|
80
|
-
application (order is irrelevant). At minimum, each item must have `id` and
|
|
81
|
-
`$type` properties (see [ItemType](apidoc://ItemType/ItemType) for a list of
|
|
82
|
-
default supported types). The combination of type and ID must be unique within
|
|
83
|
-
an App. This means that you are permitted to have two items with an ID of
|
|
84
|
-
`"default"`, but only if they are of different types. IDs must consist of only
|
|
85
|
-
[unreserved URI characters](https://tools.ietf.org/html/rfc3986).
|
|
86
|
-
|
|
87
|
-
Any remaining properties on an item that do not start with "\$" are its
|
|
88
|
-
configured settings, and vary based on the type of item. For example, the map
|
|
89
|
-
extension's `"title"` property in the previous example. These properties will
|
|
90
|
-
get passed in to the appropriate [item factory](#Custom-Item-Types) for that
|
|
91
|
-
item type.
|
|
92
|
-
|
|
93
|
-
### Item URIs
|
|
94
|
-
|
|
95
|
-
Items in an App can be uniquely identified via URIs that use a special `item://`
|
|
96
|
-
scheme, like so:
|
|
97
|
-
|
|
98
|
-
```
|
|
99
|
-
item://<type>/<id>
|
|
100
|
-
```
|
|
101
|
-
|
|
102
|
-
The AppContainer class allows retrieving an item via its `item://` URI:
|
|
103
|
-
|
|
104
|
-
```
|
|
105
|
-
const mapX = await container.get("item://map-extension/default");
|
|
106
|
-
```
|
|
107
|
-
|
|
108
|
-
### Item References
|
|
109
|
-
|
|
110
|
-
The property values for an item can reference other items, using `item://` URIs.
|
|
111
|
-
For example:
|
|
112
|
-
|
|
113
|
-
```
|
|
114
|
-
items: [
|
|
115
|
-
{
|
|
116
|
-
"$type": "layer-extension",
|
|
117
|
-
"id": "incidents",
|
|
118
|
-
"layer": {
|
|
119
|
-
"layerType": "ArcGISFeatureLayer",
|
|
120
|
-
"url": "http://sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/0"
|
|
121
|
-
}
|
|
122
|
-
},
|
|
123
|
-
{
|
|
124
|
-
$type: "map-extension",
|
|
125
|
-
id: "default",
|
|
126
|
-
layerExtensions: [
|
|
127
|
-
"item://layer-extension/incidents"
|
|
128
|
-
]
|
|
129
|
-
}
|
|
130
|
-
]
|
|
131
|
-
```
|
|
132
|
-
|
|
133
|
-
When the `item://map-extension/default` item is requested from the AppContainer,
|
|
134
|
-
it will first create the `item://layer-extension/incidents` object that it
|
|
135
|
-
references, and then substitute it in place of the reference prior to creating
|
|
136
|
-
the map extension.
|
|
137
|
-
|
|
138
|
-
**NOTE**: Regardless of how many times an item is requested or referenced by
|
|
139
|
-
other items, only a single object instance is ever created per unique item.
|
|
140
|
-
|
|
141
|
-
### Custom Item Types
|
|
142
|
-
|
|
143
|
-
By default, AppContainer is pre-configured to understand the various items types
|
|
144
|
-
that are built in the ArcGIS Extensions API, e.g. MapExtension and Menu. However, you
|
|
145
|
-
can work with custom item types in an App by registering custom item factories
|
|
146
|
-
with AppContainer. An item factory is just a method that takes item
|
|
147
|
-
configuration and produces an actual object. For more information, see
|
|
148
|
-
[AppContainer.registerType()](apidoc://AppContainer.registerType).
|
|
149
|
-
|
|
150
|
-
You can also override the built-in factories for ArcGIS Extensions API items with your
|
|
151
|
-
own factories to customize how these items are created.
|
|
152
|
-
|
|
153
|
-
## Settings
|
|
154
|
-
|
|
155
|
-
An App may contain a `settings` block at the top level, which is a place to
|
|
156
|
-
define custom, application-wide settings as a set of key/value pairs. The key is
|
|
157
|
-
a unique name for the setting, and the value is a simple scalar value (string,
|
|
158
|
-
boolean, or number).
|
|
159
|
-
|
|
160
|
-
```
|
|
161
|
-
{
|
|
162
|
-
"schemaVersion": "1.0",
|
|
163
|
-
"settings": {
|
|
164
|
-
"baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest/",
|
|
165
|
-
"defaultMaxResults": 300
|
|
166
|
-
}
|
|
167
|
-
}
|
|
168
|
-
```
|
|
169
|
-
|
|
170
|
-
Settings can be accessed programmatically via the
|
|
171
|
-
[AppContainer.settings](apidoc://AppContainer.settings) property. Setting values
|
|
172
|
-
can also be referenced within an App by using a special URI syntax:
|
|
173
|
-
|
|
174
|
-
```
|
|
175
|
-
setting://<setting-name>.
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
Whenever an item’s property has a value like this, the configuration loader will
|
|
179
|
-
substitute it for the actual setting value. This is useful when a setting is
|
|
180
|
-
used by more than one item in an App, as it gives you a single place to change
|
|
181
|
-
it. You can also insert a setting’s value into a string property or other
|
|
182
|
-
settings, by surrounding the `setting://` URI with `{}` characters within a
|
|
183
|
-
string. For example:
|
|
184
|
-
|
|
185
|
-
```
|
|
186
|
-
{
|
|
187
|
-
"schemaVersion": "1.0",
|
|
188
|
-
"settings": {
|
|
189
|
-
"baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest"
|
|
190
|
-
},
|
|
191
|
-
items: [
|
|
192
|
-
{
|
|
193
|
-
"$type": "layer-extension",
|
|
194
|
-
"id": "hurricanes",
|
|
195
|
-
"layer": {
|
|
196
|
-
"layerType": "ArcGISMapServiceLayer",
|
|
197
|
-
"url": "{setting://baseServiceUrl}/services/Hurricanes/MapServer"
|
|
198
|
-
}
|
|
199
|
-
}
|
|
200
|
-
]
|
|
201
|
-
}
|
|
202
|
-
```
|
|
203
|
-
|
|
204
|
-
## Failure Modes
|
|
205
|
-
|
|
206
|
-
By default, when one item references another and the referenced item cannot be
|
|
207
|
-
created, then the original item cannot be created either. In this case an error
|
|
208
|
-
will occur when you attempt to get the original item from the App container. You
|
|
209
|
-
can adjust this behavior by defining a custom failure mode for an item in the
|
|
210
|
-
top-level `failureModes` property. This property maps an `item://` URI to the
|
|
211
|
-
failure mode value for that item. Possible values are `"error"`, `"warn"`, and
|
|
212
|
-
`"ignore"`, with `"error"` being the default. For example:
|
|
213
|
-
|
|
214
|
-
```
|
|
215
|
-
{
|
|
216
|
-
"schemaVersion": "1.0",
|
|
217
|
-
items: [
|
|
218
|
-
{
|
|
219
|
-
"$type": "layer-extension",
|
|
220
|
-
"id": "broken",
|
|
221
|
-
"layer": {
|
|
222
|
-
"url": "invalid URL"
|
|
223
|
-
}
|
|
224
|
-
},
|
|
225
|
-
{
|
|
226
|
-
$type: "map-extension",
|
|
227
|
-
id: "default",
|
|
228
|
-
layerExtensions: [
|
|
229
|
-
"item://layer-extension/broken"
|
|
230
|
-
]
|
|
231
|
-
}
|
|
232
|
-
],
|
|
233
|
-
"failureModes": [
|
|
234
|
-
"item://layer-extension/broken": "warn"
|
|
235
|
-
]
|
|
236
|
-
}
|
|
237
|
-
```
|
|
238
|
-
|
|
239
|
-
In this example, the item `item://layer-extension/broken` contains an invalid
|
|
240
|
-
URL, and so it cannot be created. Normally this would mean that
|
|
241
|
-
`item://map-extension/default` couldn't be created either, but because of the
|
|
242
|
-
configured failure mode of `"warn"` for the layer extension, the map extension
|
|
243
|
-
can still be created. The AppContainer will remove the invalid URI prior to
|
|
244
|
-
creating the map extension, and will raise a special `configWarning` event
|
|
245
|
-
containing details about the item that could not be created. In this case, the
|
|
246
|
-
host application should handle this event by warning the end user about the
|
|
247
|
-
missing layer.
|
|
248
|
-
|
|
249
|
-
Failure modes are also passed on to the item factories. This means that objects
|
|
250
|
-
that are created by the AppContainer can also respond to failure modes. For
|
|
251
|
-
example, MapExtension will honor a layer extension's failure mode if the layer
|
|
252
|
-
fails to load successfully (e.g. the map service is currently unavailable). The
|
|
253
|
-
exact behavior depends on the type of object.
|
|
254
|
-
|
|
255
|
-
## App Imports
|
|
256
|
-
|
|
257
|
-
An App can import one or more other Apps via the top-level `import` block. This
|
|
258
|
-
is a list of one or more URLs pointing to other Apps to import, like so:
|
|
259
|
-
|
|
260
|
-
```
|
|
261
|
-
{
|
|
262
|
-
"schemaVersion": "1.0",
|
|
263
|
-
"import": [
|
|
264
|
-
"http://some.company.com/apps/default-basemaps.app.json",
|
|
265
|
-
"default-layers.app.json"
|
|
266
|
-
]
|
|
267
|
-
}
|
|
268
|
-
```
|
|
269
|
-
|
|
270
|
-
When an App imports another one, the items, settings, failure modes, etc.
|
|
271
|
-
defined in the referenced app become part of the current App, as though they had
|
|
272
|
-
been defined inline.
|
|
273
|
-
|
|
274
|
-
If the current App contains one or more items that also appear in the imported
|
|
275
|
-
App, then the items' properties are merged, with locally defined property values
|
|
276
|
-
overriding imported ones. Similarly, locally defined settings and failure modes
|
|
277
|
-
override ones that are imported. If multiple Apps are imported, then content
|
|
278
|
-
from Apps that appear later in the list of imports will override the content of
|
|
279
|
-
earlier ones.
|
|
280
|
-
|
|
281
|
-
An imported App can itself contain App imports. In that case, those inner imports
|
|
282
|
-
are resolved first, and the resulting App is then imported into the outer one.
|
|
283
|
-
|
|
284
|
-
## Importing Apps from Portal
|
|
285
|
-
|
|
286
|
-
It is possible to import Apps from a portal instance by using one of the
|
|
287
|
-
following URI patterns:
|
|
288
|
-
|
|
289
|
-
- portal://<portal-id>/<item-id>
|
|
290
|
-
- portal://<item-id>
|
|
291
|
-
|
|
292
|
-
The first version (with _portal-id_) can be used when you want to specify the
|
|
293
|
-
portal instance where the item is located. In order for this portal:// URI to
|
|
294
|
-
successfully be resolved, you must associate _portal-id_ with an instance of
|
|
295
|
-
@arcgis/core/portal/Portal. This can be done using the _portals_ map in
|
|
296
|
-
@vertigis/arcgis-extensions/config.
|
|
297
|
-
|
|
298
|
-
You can import App configuration from a portal instance like this:
|
|
299
|
-
|
|
300
|
-
```
|
|
301
|
-
{
|
|
302
|
-
"schemaVersion": "1.0",
|
|
303
|
-
"import": [
|
|
304
|
-
"portal://test-portal/abcdef0123456789abcdef0123456789,
|
|
305
|
-
]
|
|
306
|
-
}
|
|
307
|
-
```
|
|
308
|
-
|
|
309
|
-
If the imported configuration has any further imports in form
|
|
310
|
-
portal://<item-id>, these will be changed to use the _portal-id_ of the parent
|
|
311
|
-
App.
|
|
1
|
+
# VertiGIS Studio Apps
|
|
2
|
+
|
|
3
|
+
## Introduction
|
|
4
|
+
|
|
5
|
+
A VertiGIS Studio App is a JSON document containing configuration for an application
|
|
6
|
+
that is built on top of the ArcGIS Extensions API. Building on the Esri Web Map
|
|
7
|
+
Specification, VertiGIS Studio Apps enable a declarative approach to working with the
|
|
8
|
+
VertiGIS and Esri APIs. Rather than initializing the properties of API objects
|
|
9
|
+
programmatically in code, you can define all of their settings externally in an
|
|
10
|
+
App JSON document. Then, you can access the configured objects via the
|
|
11
|
+
`AppContainer` class. Here is an example VertiGIS Studio App containing a map
|
|
12
|
+
extension and a menu:
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
{
|
|
16
|
+
"schemaVersion": "1.0",
|
|
17
|
+
"items": [
|
|
18
|
+
{
|
|
19
|
+
"$type": "map-extension",
|
|
20
|
+
"id": "default",
|
|
21
|
+
"title": "LA County",
|
|
22
|
+
"webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
|
|
23
|
+
},
|
|
24
|
+
{
|
|
25
|
+
"$type": "menu",
|
|
26
|
+
"id": "i-want-to",
|
|
27
|
+
"items": [
|
|
28
|
+
{
|
|
29
|
+
"id": "zoom-in",
|
|
30
|
+
"title": "Zoom In"
|
|
31
|
+
},
|
|
32
|
+
{
|
|
33
|
+
"id": "zoom-out",
|
|
34
|
+
"title": "Zoom Out"
|
|
35
|
+
}
|
|
36
|
+
]
|
|
37
|
+
}
|
|
38
|
+
]
|
|
39
|
+
}
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
In code, you would then access the items defined in this App like so:
|
|
43
|
+
|
|
44
|
+
```
|
|
45
|
+
const appJson = ... // Load the JSON from somewhere.
|
|
46
|
+
const container = new AppContainer(appJson);
|
|
47
|
+
const mapX = await container.get("map-extension", "default");
|
|
48
|
+
const iwtm = await container.get("menu", "i-want-to");
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
With the exception of a few special App properties like `$type`, the JSON for
|
|
52
|
+
each item uses the same schema that is supported by the constructor for the
|
|
53
|
+
corresponding API object. For example, this produces the same end result as the
|
|
54
|
+
above code:
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
const mapX = new MapExtension({
|
|
58
|
+
"id": "default",
|
|
59
|
+
"title": "LA County",
|
|
60
|
+
"webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
|
|
61
|
+
});
|
|
62
|
+
const iwtm = new Menu({
|
|
63
|
+
"id": "i-want-to",
|
|
64
|
+
"items": [
|
|
65
|
+
{
|
|
66
|
+
"id": "zoom-in",
|
|
67
|
+
"title": "Zoom In"
|
|
68
|
+
},
|
|
69
|
+
{
|
|
70
|
+
"id": "zoom-out",
|
|
71
|
+
"title": "Zoom Out"
|
|
72
|
+
}
|
|
73
|
+
]
|
|
74
|
+
});
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## App Items
|
|
78
|
+
|
|
79
|
+
The `items` property of an App contains the set of configured items for an
|
|
80
|
+
application (order is irrelevant). At minimum, each item must have `id` and
|
|
81
|
+
`$type` properties (see [ItemType](apidoc://ItemType/ItemType) for a list of
|
|
82
|
+
default supported types). The combination of type and ID must be unique within
|
|
83
|
+
an App. This means that you are permitted to have two items with an ID of
|
|
84
|
+
`"default"`, but only if they are of different types. IDs must consist of only
|
|
85
|
+
[unreserved URI characters](https://tools.ietf.org/html/rfc3986).
|
|
86
|
+
|
|
87
|
+
Any remaining properties on an item that do not start with "\$" are its
|
|
88
|
+
configured settings, and vary based on the type of item. For example, the map
|
|
89
|
+
extension's `"title"` property in the previous example. These properties will
|
|
90
|
+
get passed in to the appropriate [item factory](#Custom-Item-Types) for that
|
|
91
|
+
item type.
|
|
92
|
+
|
|
93
|
+
### Item URIs
|
|
94
|
+
|
|
95
|
+
Items in an App can be uniquely identified via URIs that use a special `item://`
|
|
96
|
+
scheme, like so:
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
item://<type>/<id>
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
The AppContainer class allows retrieving an item via its `item://` URI:
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
const mapX = await container.get("item://map-extension/default");
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
### Item References
|
|
109
|
+
|
|
110
|
+
The property values for an item can reference other items, using `item://` URIs.
|
|
111
|
+
For example:
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
items: [
|
|
115
|
+
{
|
|
116
|
+
"$type": "layer-extension",
|
|
117
|
+
"id": "incidents",
|
|
118
|
+
"layer": {
|
|
119
|
+
"layerType": "ArcGISFeatureLayer",
|
|
120
|
+
"url": "http://sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/0"
|
|
121
|
+
}
|
|
122
|
+
},
|
|
123
|
+
{
|
|
124
|
+
$type: "map-extension",
|
|
125
|
+
id: "default",
|
|
126
|
+
layerExtensions: [
|
|
127
|
+
"item://layer-extension/incidents"
|
|
128
|
+
]
|
|
129
|
+
}
|
|
130
|
+
]
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
When the `item://map-extension/default` item is requested from the AppContainer,
|
|
134
|
+
it will first create the `item://layer-extension/incidents` object that it
|
|
135
|
+
references, and then substitute it in place of the reference prior to creating
|
|
136
|
+
the map extension.
|
|
137
|
+
|
|
138
|
+
**NOTE**: Regardless of how many times an item is requested or referenced by
|
|
139
|
+
other items, only a single object instance is ever created per unique item.
|
|
140
|
+
|
|
141
|
+
### Custom Item Types
|
|
142
|
+
|
|
143
|
+
By default, AppContainer is pre-configured to understand the various items types
|
|
144
|
+
that are built in the ArcGIS Extensions API, e.g. MapExtension and Menu. However, you
|
|
145
|
+
can work with custom item types in an App by registering custom item factories
|
|
146
|
+
with AppContainer. An item factory is just a method that takes item
|
|
147
|
+
configuration and produces an actual object. For more information, see
|
|
148
|
+
[AppContainer.registerType()](apidoc://AppContainer.registerType).
|
|
149
|
+
|
|
150
|
+
You can also override the built-in factories for ArcGIS Extensions API items with your
|
|
151
|
+
own factories to customize how these items are created.
|
|
152
|
+
|
|
153
|
+
## Settings
|
|
154
|
+
|
|
155
|
+
An App may contain a `settings` block at the top level, which is a place to
|
|
156
|
+
define custom, application-wide settings as a set of key/value pairs. The key is
|
|
157
|
+
a unique name for the setting, and the value is a simple scalar value (string,
|
|
158
|
+
boolean, or number).
|
|
159
|
+
|
|
160
|
+
```
|
|
161
|
+
{
|
|
162
|
+
"schemaVersion": "1.0",
|
|
163
|
+
"settings": {
|
|
164
|
+
"baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest/",
|
|
165
|
+
"defaultMaxResults": 300
|
|
166
|
+
}
|
|
167
|
+
}
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
Settings can be accessed programmatically via the
|
|
171
|
+
[AppContainer.settings](apidoc://AppContainer.settings) property. Setting values
|
|
172
|
+
can also be referenced within an App by using a special URI syntax:
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
setting://<setting-name>.
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
Whenever an item’s property has a value like this, the configuration loader will
|
|
179
|
+
substitute it for the actual setting value. This is useful when a setting is
|
|
180
|
+
used by more than one item in an App, as it gives you a single place to change
|
|
181
|
+
it. You can also insert a setting’s value into a string property or other
|
|
182
|
+
settings, by surrounding the `setting://` URI with `{}` characters within a
|
|
183
|
+
string. For example:
|
|
184
|
+
|
|
185
|
+
```
|
|
186
|
+
{
|
|
187
|
+
"schemaVersion": "1.0",
|
|
188
|
+
"settings": {
|
|
189
|
+
"baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest"
|
|
190
|
+
},
|
|
191
|
+
items: [
|
|
192
|
+
{
|
|
193
|
+
"$type": "layer-extension",
|
|
194
|
+
"id": "hurricanes",
|
|
195
|
+
"layer": {
|
|
196
|
+
"layerType": "ArcGISMapServiceLayer",
|
|
197
|
+
"url": "{setting://baseServiceUrl}/services/Hurricanes/MapServer"
|
|
198
|
+
}
|
|
199
|
+
}
|
|
200
|
+
]
|
|
201
|
+
}
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
## Failure Modes
|
|
205
|
+
|
|
206
|
+
By default, when one item references another and the referenced item cannot be
|
|
207
|
+
created, then the original item cannot be created either. In this case an error
|
|
208
|
+
will occur when you attempt to get the original item from the App container. You
|
|
209
|
+
can adjust this behavior by defining a custom failure mode for an item in the
|
|
210
|
+
top-level `failureModes` property. This property maps an `item://` URI to the
|
|
211
|
+
failure mode value for that item. Possible values are `"error"`, `"warn"`, and
|
|
212
|
+
`"ignore"`, with `"error"` being the default. For example:
|
|
213
|
+
|
|
214
|
+
```
|
|
215
|
+
{
|
|
216
|
+
"schemaVersion": "1.0",
|
|
217
|
+
items: [
|
|
218
|
+
{
|
|
219
|
+
"$type": "layer-extension",
|
|
220
|
+
"id": "broken",
|
|
221
|
+
"layer": {
|
|
222
|
+
"url": "invalid URL"
|
|
223
|
+
}
|
|
224
|
+
},
|
|
225
|
+
{
|
|
226
|
+
$type: "map-extension",
|
|
227
|
+
id: "default",
|
|
228
|
+
layerExtensions: [
|
|
229
|
+
"item://layer-extension/broken"
|
|
230
|
+
]
|
|
231
|
+
}
|
|
232
|
+
],
|
|
233
|
+
"failureModes": [
|
|
234
|
+
"item://layer-extension/broken": "warn"
|
|
235
|
+
]
|
|
236
|
+
}
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
In this example, the item `item://layer-extension/broken` contains an invalid
|
|
240
|
+
URL, and so it cannot be created. Normally this would mean that
|
|
241
|
+
`item://map-extension/default` couldn't be created either, but because of the
|
|
242
|
+
configured failure mode of `"warn"` for the layer extension, the map extension
|
|
243
|
+
can still be created. The AppContainer will remove the invalid URI prior to
|
|
244
|
+
creating the map extension, and will raise a special `configWarning` event
|
|
245
|
+
containing details about the item that could not be created. In this case, the
|
|
246
|
+
host application should handle this event by warning the end user about the
|
|
247
|
+
missing layer.
|
|
248
|
+
|
|
249
|
+
Failure modes are also passed on to the item factories. This means that objects
|
|
250
|
+
that are created by the AppContainer can also respond to failure modes. For
|
|
251
|
+
example, MapExtension will honor a layer extension's failure mode if the layer
|
|
252
|
+
fails to load successfully (e.g. the map service is currently unavailable). The
|
|
253
|
+
exact behavior depends on the type of object.
|
|
254
|
+
|
|
255
|
+
## App Imports
|
|
256
|
+
|
|
257
|
+
An App can import one or more other Apps via the top-level `import` block. This
|
|
258
|
+
is a list of one or more URLs pointing to other Apps to import, like so:
|
|
259
|
+
|
|
260
|
+
```
|
|
261
|
+
{
|
|
262
|
+
"schemaVersion": "1.0",
|
|
263
|
+
"import": [
|
|
264
|
+
"http://some.company.com/apps/default-basemaps.app.json",
|
|
265
|
+
"default-layers.app.json"
|
|
266
|
+
]
|
|
267
|
+
}
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
When an App imports another one, the items, settings, failure modes, etc.
|
|
271
|
+
defined in the referenced app become part of the current App, as though they had
|
|
272
|
+
been defined inline.
|
|
273
|
+
|
|
274
|
+
If the current App contains one or more items that also appear in the imported
|
|
275
|
+
App, then the items' properties are merged, with locally defined property values
|
|
276
|
+
overriding imported ones. Similarly, locally defined settings and failure modes
|
|
277
|
+
override ones that are imported. If multiple Apps are imported, then content
|
|
278
|
+
from Apps that appear later in the list of imports will override the content of
|
|
279
|
+
earlier ones.
|
|
280
|
+
|
|
281
|
+
An imported App can itself contain App imports. In that case, those inner imports
|
|
282
|
+
are resolved first, and the resulting App is then imported into the outer one.
|
|
283
|
+
|
|
284
|
+
## Importing Apps from Portal
|
|
285
|
+
|
|
286
|
+
It is possible to import Apps from a portal instance by using one of the
|
|
287
|
+
following URI patterns:
|
|
288
|
+
|
|
289
|
+
- portal://<portal-id>/<item-id>
|
|
290
|
+
- portal://<item-id>
|
|
291
|
+
|
|
292
|
+
The first version (with _portal-id_) can be used when you want to specify the
|
|
293
|
+
portal instance where the item is located. In order for this portal:// URI to
|
|
294
|
+
successfully be resolved, you must associate _portal-id_ with an instance of
|
|
295
|
+
@arcgis/core/portal/Portal. This can be done using the _portals_ map in
|
|
296
|
+
@vertigis/arcgis-extensions/config.
|
|
297
|
+
|
|
298
|
+
You can import App configuration from a portal instance like this:
|
|
299
|
+
|
|
300
|
+
```
|
|
301
|
+
{
|
|
302
|
+
"schemaVersion": "1.0",
|
|
303
|
+
"import": [
|
|
304
|
+
"portal://test-portal/abcdef0123456789abcdef0123456789,
|
|
305
|
+
]
|
|
306
|
+
}
|
|
307
|
+
```
|
|
308
|
+
|
|
309
|
+
If the imported configuration has any further imports in form
|
|
310
|
+
portal://<item-id>, these will be changed to use the _portal-id_ of the parent
|
|
311
|
+
App.
|