Zum Hauptinhalt gehen

Best practices for customizing the editing experience in VSW

Angesagt
Cam Barnard

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.

3

Kommentare

7 Kommentare

Datum Stimmen
  • Gareth Finney

    Thanks for the article Cam Barnard - there's some cool stuff in here. I was wondering though how I could 'intercept' the save option on the OOTB Add Feature command, and present a workflow that prompts the user to select from a preconfigured list of fire/incident names... they choose one, and it populates a field in the backend. We want users to not type incident names as part of the add fire area feature (Add Feature). We do this currently with a custom module in the GVH5, but is there a way to potentially do this with Add Feature/Workflow combo perhaps?

    It seems like it might be possible, using the edit.display-update-feature command, but just finding the  where to 'attach' it is beyond me right now..

    thanks in advance

    Gareth

     

    0
  • Gareth Evans

    Hey Gareth Finney great to hear from another well named person.

    My suggestion here would be to replace the OOTB editing, rather than trying to hijack it.

    You can accomplish this by configuring a Feature Action on your layer, and choosing a Workflow there. Your Workflow would then be configured to present a Display Form that has a picker (probably an Item Picker).  that is populated (on load) dynamically from your list of incident names. This can be based on a query of an ArcGIS Server or other supported data source.

    This configuration would be done in Designer under the Map component > Layer Extensions > (specific layer) > feature actions -  Feature actions docs: Web Designer Help - Map Settings (vertigisstudio.com)

    Workflow docs relevant:

    There's a great example workflow here: VertiGIS Studio Workflow - Add Feature - Overview (arcgis.com) that's the Add Feature workflow from our VSW Sample app: VertiGIS Studio Web Sample Package – VertiGIS Support

    This toolbar item:


    The overview looks like this:


    The dynamic population bit looks like this:

    0
  • Gareth Finney
    Bearbeitet

    Thanks Gareth for the speedy reply - much appreciated. 

    I can see where you're coming from here.. interesting. I'd prefer not to have to code in ALL the required Field values - including domains, dates and all of that. There's a bunch of fields that need populating, and the out of the box tool does a nice job in doing this. Ideally, I only need to capture the one 'extra' input from the user (incident name) and code that in.

    I guess I need a mix of ootb, and custom entries in the one add/update process. If this can't be done, then I'll look at coding all the values, as you've suggested. 

    Again, appreciate the help on this. 

    cheers

    Gareth

     

    If it's not do-able, then I'll look at your suggestion. 

    1
  • Gareth Evans

    You're welcome! I know Cam's OOO right now so thought I'd get you going in the meantime. The Woolies like Owen Parfrey, Francisco, Chris and co are also super well versed here too!

    0
  • Gareth Finney

    The key here also Gareth, and sorry for not being more specific - is that based on the user selecting an Observation type to start with, lets say Natural Values, from the list.

     

    the user then gets presented with the appropriate Domain from the geodatabase.

    There's a combination of geodatabase Subtypes (Main obs area types), and the Domain associated with the subtype chosen. It looks like the web designer picks all this up, which is great, but I'm not sure how I can pick up the Main obs type chosen from the initial editing popup window (first screen grab), so as to pass this into the workflow to start to present the appropriate domains to the user in  my 'derived' editing form...

    I'm hoping all that makes sense?

    Hence I'm desperate for a way to just use the current editing experience, and then hijack the Save button, or expose some sort of edit.add-feature, or edit.update-feature command in there somewhere. 

    again, thanks for the help 

    cheers

    Gareth

    0
  • Gareth Evans
    Bearbeitet

    Hey Gareth Finney - apologies for the delayed response, I missed your initial reply and only found this after stumbling across this thread in a search. You're totally right in not wanting to duplicate effort and use as much OOTB functionality as you can: we absolutely encourage this approach.

    A few thoughts here:
    It's possible to configure the Results Details edit behaviour - this is an event we can hook into as Cam described. You want to, in the Results Details panel you've got, edit the Result Edited command, here:

    If you wanted to pop off a workflow, you edit that and use a custom command like this:


    See this documentation:

    To answer your question about how to get the value of the first dropdown in a workflow, you can access the state of a form generally using syntax like

    ${Display Form ID}.state.{Element ID}.{property name}

    So, if you had a form called form1 with a dropdown called dropDownList1 and you want to get the value of the currently selected item, you can use

    $form1.state.dropDownList1.current


    See these docs:
    - Workflow Help - Access User Inputs (vertigisstudio.com)

    - Workflow Help - Drop Down List Form Element (vertigisstudio.com)

    0
  • Gareth Finney
    Bearbeitet

    Hi Gareth,

    Thanks for the reply on this. 

    I've managed to get this working end-to-end as a standalone Add Feature tool - via workflow only. I found it simpler to just present a defined workflow that enables us to control the values presented, and written to the back-end. Rather than intercepting any editing events, and or Result sets. I was trying to stay clear of the Result set approach. That might come eventually as part of an update Incident type tool, but the initial creation tool is working well for now. We lose the nice UI of  having the symbology types shown to you - where you click on one of the types interactively, but there's a bit more flexibility in defining the whole process, so losing the symbology and replacing it with a simple drop down list of types is fine for us I think. 

    again, thanks for the help on this!

    Gareth

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Sie haben nicht gefunden, wonach Sie suchten?

Neuer Post