Changes between Version 6 and Version 7 of MapGuideRfc158

Timestamp:

Apr 20, 2017, 6:03:50 AM (7 years ago)

Author:

jng

Comment:

--

MapGuideRfc158

@@ -28 +28 @@
 == Motivation ==
 
-All JSON responses from the mapagent are verbatim conversions from their XML counterparts. 
+All JSON responses from the mapagent are currently verbatim conversions from their XML counterparts. 
 
 However this conversion process results in JSON that is quite cumbersome to consume:
 
- * All properties are arrays.
- * All properties are string values.
+ * All converted elements are arrays.
+ * All converted element content are arrays of string values.
  
-This is due to the conversion process not taking the content model (and its data types/element cardinality) into account, taking the lowest common denominator approach.
+This is due to the XML to JSON conversion process not taking the content model (and its data types/element cardinality) into account, taking the lowest common denominator approach.
+
+Current client applications that do happen to use the JSON responses provided by the mapagent will most likely be having to employ manual "de-arrayification" of the JSON content and lots of manual string to int/double/boolean parsing to be able to work with the current JSON responses. You can see this in Fusion where there is a lot of initialization work in de-arrayification/{{{parseInt}}}/{{{parseFloat}}} of the ApplicatonDefinition and RuntimeMap JSON responses.
+
+This is work that client applications do not, and should not have to do.
 
 == Proposed Solution ==
 
-The MgJsonConvert class that does the actual XML to JSON conversion will be modified to include a hard-coded list of XML element paths:
+The {{{MgJsonConvert}}} class of the {{{HttpHandler}}} project that does the actual XML to JSON conversion will be modified to include a hard-coded list of XML element paths:
 
  * For elements that contain 0 to many elements
  * For elements that are not string data types
  
-During the conversion process, we check the computed XML element path of the element we're converting and check if it is in one of these two lists
+During the conversion process, we check the computed XML element path of the element/attriubte we're converting and check if it is in one of these two lists
 
  * If it is in the first list, the element is written as a JSON array
@@ -54 +58 @@
 With the new JSON responses, not only are they more simpler to use (not everything is an array and not everything is a string and the content structure is semantically similar to their XML counterparts), but is also much more compact due to the amount of {{{[}}} and {{{"}}} characters we save by not converting everything to string arrays
 
-Fusion will also be updated to take advantage of the new clean JSON responses.
+Fusion will also be partially updated to take advantage of the new clean JSON responses:
+
+ * For initial runtime map creation ({{{CREATERUNTIMEMAP}}})
+ * For its selection/tooltip queries ({{{QUERYMAPFEATURES}}})
+ * ApplicationDefinition parsing will remain as-is because converting this to use clean JSON responses will flow on to having to update *all* current widgets that get created by this parsed appdef to use the clean JSON as well, which is too much effort for the desired payoff.
 
 == GeoJSON output ==
@@ -60 +68 @@
 For the {{{SELECTFEATURES}}} mapagent operation, even with the clean JSON response formatting applied, the JSON response is still near-useless for consumption by client applications.
 
-For this particular operation, if we want the response in JSON, since it includes spatial data for features it is more practical to return this in GeoJSON format, which is more ubiquitous and more practical for client-application consumption.
+For this particular operation, if we want the response in JSON, since it includes geometric data for features it is more practical to return this in GeoJSON format, which is more ubiquitous and more practical for client-application consumption.
 
 To enable this, we'll be adding a new MgGeoJsonWriter utility class to the PlatformBase library to enable easy GeoJSON conversion from feature readers
@@ -2373 +2381 @@
 == Implications ==
 
-Any time a new schema or schema revision is introduced, this hard-coded list will have to be updated to know which elements in these new schemas require special processing.
+Any time a new schema or schema revision is introduced, this hard-coded element path list in {{{MgJsonConvert}}} will have to be updated to know which elements in these new schemas require special processing.
 
 == Test Plan ==