Best practices for customizing the editing experience in VSW

Where to make changes, and why.

By default, you enable editing on the result details component, this adds an edit button to the bottom of your result details views.

Changing the editing behavior, for all features, is done via the Result Edited event in the Events section in the Result Details component.

There are a number of optional settings for edit.display-update-feature that you can use. See https://developers.vertigisstudio.com/docs/web/api-commands-operations-events#definition-DisplayUpdateFeatureArgs.

For example, in the Web GIS – Default template we included a hydrant-specific action to move the hydrant. This was done with the following command.

{
    "name": "edit.display-update-feature",
    "arguments": {
      "editAttributes": false,
      "editAttachments": false,
      "editGeometry": true,
      "editGeometryOptions": {
        "allowRotate": false,
        "allowScale": false
      }
    }
  }

It is possible to insert a pre-edit or a post-edit shim here using a Workflow. For example, for a specific feature layer, after the user completes their standard edits, you want to ask them to associate that feature with a current traffic accident. You could create a workflow that will always be called after the edit takes place, check the context coming in to see if it is the layer you are looking for, and if it is then your workflow could:

• query another feature layer of active traffic accidents within a 10km buffer around the edited feature
• present a list of those traffic accidents to the user using a workflow form
• take the selected feature, and update a specific attribute in the recently edited feature with the incident ID

Here is an example of what the Edited Event might look like:

"edit.display-update-feature",
  {
    "name": "workflow.run",
    "arguments": {
      "id": "get-layer-of-edited-feature-workflow",
      "portalItem": "https://latitudegeo.maps.arcgis.com/home/item.html?id=77e1cf008dbd4e35a52f98735ccc4776",
      "commandArgumentInput": "context"
    }
  }

The workflow follows a standard pattern for Get Workflow Inputs and then conditional checks such as:

=$getWorkflowInputs1.inputs.context[0].source.id==="victoria-fire-hydrants"

The pros of modifying the event in Result Details is that it is done in a single place and you can centralize your configuration. The cons are that if your workflow logic gets complex and takes time, you are paying that penalty on every edit.

---

Sometimes you want a substantially different editing experience for different feature layers. For example,

• for layer A you may want users to modify attributes but not geometry
• for layer B you want users to modify geometry, but not attributes
• for layer C even though it is a feature layer, you don’t want users in this application to edit it at all

When you need different behaviors for different layers, you should turn off feature editing in the Result Details component and begin adding it as a layer-specific feature action. Map > layer > Feature Actions.

In the simple case, you can add the Edit Result tool and it will behave just as the edit button did.

Now you can provide different parameters to different layers, and to optionally run a workflow as in the result details case, except now that workflow is simpler because it is only run for that specific layer.

---

For some features a pre-step or post-step shim isn’t sufficient, you may want to pre-calculate default values and use those for your editing session, and then verify entered data against a non-GIS enterprise system before committing the edits. In such cases you will replace the stock command with a workflow. The workflow is capable of invoking the same viewer command that shows the editing interface, but you now have full access to data and the ability to perform additional work while editing is taking place.

In complex examples you can programmatically do pretty much everything that the UI in VSW allows you to do, but in simpler cases you can pre-do work in your workflow, then use the Run Command to run the edit.display-update-feature viewer command to invoke the UI, then finish up any work before exiting the Workflow.

When you need to interactively work with an editing session, Workflow is your best pattern because the command chain JSON structure of your commands in VSW are not able to pass values or evaluate conditions.