Prevent Editor from loosing actionable state onComplete?
Prevent Editor from loosing actionable state onComplete?
In a riff on the discussion you had here:
https://datatables.net/forums/discussion/32665/formoptions-oncomplete-none-clears-s-action
Would it be possible to have an additional "onComplete" member of the formOptions family?
> formOptions: {
> main: {
> onComplete: 'wait' // my idea, not a real option
> }
This option would keep the editor in an open, un-submitted or actionable state (whatever you call it), so that events like "submitSuccess" can be fired over again. The API we're dealing with returns zero or one as a success parameter, so we're trying onComplete: 'none' as a formOption along with
> editor1.on( 'submitSuccess', function ( e, json, data, action ) {
> if(json.success==1){
> toastr.info("Changes submitted.","Success!");
> editor1.close();
> }
> }
> else{
> apiNonSuccessHandler(json); // global toastr/logging thing
> // and the editor stays open
> }
> }
This solution leaves the Editor open if the API returns a fail, but in a state where it cannot be submitted again.
We'll look at the solution presented in the discussion below, but this would mean a considerable rewrite. I was guessing - in my typically novice way - that an option like this in a future release might help more people.
https://datatables.net/forums/discussion/26838/how-do-i-prevent-editor-from-committing-changes-on-ajax-call-during-presubmit
Thanks for reading.
This question has an accepted answers - jump to answer
Answers
Hi,
Its a neat solution, thanks for suggesting it. But wouldn't:
achieve the same thing? You might need to call
create()
instead if you want to have it create a new row, or change how rows are selected, butsubmitComplete
could be effectively used as you describe.Allan
Thanks, but I've been trying that - with both
submitSuccess
andsubmitComplete
. The problem with this approach is that all the form values are reset to those of the original row.In this scenario, the API has returned a success==0 and we've told the user which value failed validation. Leaving the form as-is (for individual correction) is preferred over forcing them to start all over again.
Tacking your suggested
.ids()
on the end produces a form where the inputs are filled with the words "Multiple Values"; the same thing happens if I try toedit()
with a simple object as the item (array taken from the preSubmit package).Thanks again for your answer. I can flesh out the example further if needed.
Ah - Are you using server-side processing perhaps? Or something else that I've missed?
should address that.
Allan
Again, I really appreciate your interest in my problem. Yes, the Editor is making an API call, so a server is processing the contents of the modal form iaw the Editor's
ajax
object.The API returns a 0/1 success bit.
We do not want the modal to close unless success==1, hence the
onComplete: 'none'
setting and firing theeditor.close()
method in thesubmitSuccess
(orsubmitComplete
) handler if this bit is true.If the API returns json.success==0, we display the API message (problem for the user to fix) and leave the form open and able to try again.
But at this point the form is in a "null" mode and won't submit again, the inspiration for my original request.
Applying the code from your April 11 and April 3 suggestions will erase everything the user had accomplished in the modal form, having refreshed the inputs to their original values from the table row. This would lead to a very frustrating UX if the form had lots of elements which were changed by the user. They would need to re-change everything, possibly failing an entirely different validation with their next submission attempt.
Here is a complete citation for you (see lines 104 to 120 for the meat):
I'm with you now - thank you.
Use
postSubmit
to check if the submitted data was good or not - e.g.:Then remove the
onComplete
line, and that will allow Editor to just operate as normal (i.e. it will check if there is an error message, if so, the form retains its current state, if not, it will close). Also remove yoursubmitComplete
event handler.Allan
Ah, so many events. Thanks for pointing me to the right one and it's correct usage.
No wonder you have earned the double-L version of Allan, while I have only achieved the single-L spelling, to date... ;-]
FYI: Here's the corrected version replacing lines 104-120 above, as employed in our app.
(also, the formOptions clause has been removed)