| 365 | | For Fusion, it gets a bit more complicated as it makes various calls to assorted PHP scripts (SaveSelection.php, GetSelectionProperties.php, etc). This asynchronous call chain of PHP scripts needs to be refactored so that it only needs to send the new QUERYMAPFEATURES request and process its response as it does all the things that these PHP scripts were previously needed for. In addition, it's client-side selection structure is radically different from that of the AJAX viewer. Given the very early stage of this RFC, discussion with Fusion developers is needed to determine if the sample responses proposed here is enough to replicate the existing client-side selection model and this RFC will be updated accordingly based on developer feedback. |
| | 365 | For Fusion, it gets a bit more complicated as it makes various calls to assorted PHP scripts (SaveSelection.php, GetSelectionProperties.php, etc). This asynchronous call chain of PHP scripts needs to be refactored so that it only needs to send the new QUERYMAPFEATURES request and process its response as it does all the things that these PHP scripts were previously needed for. In addition, it's client-side selection structure is radically different from that of the AJAX viewer. |
| | 366 | |
| | 367 | '''Discussion required: Currently, the following parts of the Fusion selection structure are not set by this new QUERYMAPFEATURES operation:''' |
| | 368 | * '''propertynames (v2.6.0 QUERYMAPFEATURES will return the mapped property name and not the FDO property name if mapped)''' |
| | 369 | * '''metadata (what widgets/functionality use this information?)''' |
| | 370 | * '''metadatanames (what widgets/functionality use this information?)''' |
| | 371 | '''Should v2.6.0 QUERYMAPFEATURE also accomodate for such information?''' |
