the Editor dijit does not have a constructor option to require explicit 'saving' of edits, but you could implement something similar by setting enableUndoRedo to 'true' and specifying a valid UndoManager. this would provide an alternative technique to allow users to revert an undesirable edit.
if you want explicit saving, i am under the impression that you would have to handle the editing yourself using applyEdits on the featureC
John, I believe that he was referring to the innate behavior of the editorWidget�??s AttributeInspector that automatically has the onAttributeChange event connected to Save the edits back to the database (applyedits). This causes a lot of network chatter and also assumes that users always want to save the attributes after each attribute change. There are some sample out there that add a Save Button in order to allow the users to save the attributes when they want. I was going to initially suggest that he adds a dojo.connect for the attributeInspector onAttributeChange event and �??override�?� the functionality but I believe that he would have to disconnect the existing event prior to connecting a new event. Is this a correct assumption? I create my own attributeInspector in my app so therefore I am able to connect the events that I want, not the ones that have been �??predefined�?� by the EditorWidget.
Looking for a solution to this also....
The applyEdits is always fired anyways. It causes two problems at least:
1. Upon closing the page, the feature is already inserted to the DB without clicking on the "Save" or "Delete" buttons.
2. If I want to enable only the Create operation under Feature Access capability, I cannot use the Editor because it uses the Update or Delete operations underneath. If it was the other way around, I would create a graphic on the map, fill the Attributes form and only when I click "Save", it would create a feature in the DB. In that way I could have stayed with only the Create operation.
Thanks,
Miri
I do the following :