add to $evm.root[attributes], e.g. `calling_ui_element`


Consider a multi-tiered service, with 3 VM's. The VM's themselves can be in different locations, and available templates are location dependent. The template dropdown is dynamic, and populated by code; the code itself is the same, but for knowing where to look up its search criteria. In this example, dialog_N_template is always keyed off dialog_N_location.

Currently, to implement, one would need to create three instances, e.g. list_vms_for_location_1, list_vms_for_location_2, list_vms_for_location_3, which have an instance variable like `fieldid`, calling into list_vms_for_location_n.

If the dynamic dropdown builder environment included the calling elements name, then this indirection would be unnecessary, and N could be found in code.

Alternatively, maybe even better, would be if the service dialog could pass in arbitrary URL args or JSON or something through the form builder.