Hoppa till huvudinnehållet

Best practices for customizing the editing experience in VSW



7 kommentarer

  • 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 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:

  • Gareth Finney

    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. 




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

  • 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!

  • 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 



  • Gareth Evans

    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


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

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

  • Gareth Finney

    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!



Du måste logga in om du vill lämna en kommentar.