nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

how to avoid auto save of Editor widget

AbdulMateen

how to cancel autosave of Editor widget, on attributechange of attributesinspector .

Editor widget should not save attributes automatically directly to database untill save button is pressed in attributeinspector.

Vind meer berichten getagd met

Accepted answers

All comments

Enguerranddes_Vaux

I do the following :

this._editor.attributeInspector.onAttributeChange = lang.hitch(this, function (evt) { });

this._editor.attributeInspector.on("attribute-change", lang.hitch(this, function (evt) {

//store the updates to apply when the save button is clicked

this._editor.editToolbar._graphic.attributes[evt.fieldName] = evt.fieldValue;

}));

MiriEshel

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

FlávioMelo

Looking for a solution to this also...
How come we can't provide a attriubuteInspector to the Editor Widget and there is no way to avoid this behaviour (auto save)?

We can add buttons to the inspector, we can connect to the layer "onBeforeApplyEdits" and all that.. but the applyEdits is always fired anyways :S

AaronDrake

I am looking to disable this same functionality. I have a feature class that has several attributes (25+). Each time the user updates a value in a textbox or dropdown the form snaps back to the top of the AttributeInspector.

I would love to avoid this situation...

AbdulMateen

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.

The solution provided need some more details like

1.creating own attributeinspector with editor widget again autosave the attributes, can u provide me example editorwidget with createnew feature option with custom attributeinspector
2.if we use undoredo what if the user closes the page after edit there is no option to rollback

DianaBenedict

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.

JohnGravois

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

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.