Successcallback failing when submit not set to 'all'

Successcallback failing when submit not set to 'all'

vg10vg10 Posts: 11Questions: 3Answers: 1

I have an ajax call attached to the Editor which successfully saves the data, and returns the saved data which is then passed to the successCallback method. However, it seems that since I have submit = 'changed' and therefore only pass back the successfully saved data, that the re-painting fails because it wants all the data. If we are only processing 'changed' data, I don't understand why it expects the entire data set back. Considering that I have possibly thousands of records, I don't want to pass all that data across the wire every single time someone tabs through and saves one single field. I thought that setting the drawType to none would fix this, but I still get a re-painting error. I feel like I'm missing some obvious setting that allows the "changed" data to repaint itself without repainting the entire table. Below is my code. Can anyone help?
TIA!

            var editor = new $.fn.dataTable.Editor({
                ajax: function (method, url, data, successCallback, errorCallback)
                {
                    $.ajax({
                        url: window.baseUri + "api/DBEdit/SaveSites",
                        type: "POST",
                        data: data.data,
                        async: true
                    })
                        .done(function (rtnData)
                        {
                            //rtnData is essentially the same as data.data that was passed in
                            
                            //Build proper JS for callback
                            var callbackData = {};
                            callbackData.data = [ rtnData ];
                            callbackData.error = "";
                            callbackData.fieldErrors = "";
                            callbackData.cancelled = "";
                            debugger;
                            successCallback( callbackData );
                        })
                        .fail(function (e)
                        {
                            logError(window.location.href, e.status + " - " + e.statusText + "\n\n" + e.responseText);
                            alert(e.status + " - " + e.statusText + "\n\n" + e.responseText);
                            errorCallback(e);
                        })
                    ;
                },
                table: "#siteListTable",
                idSrc: 'EditID',
                formOptions:{
                    inline:{
                        drawType: 'none',//'full-hold',
                        onFieldError: 'none',
                        submit: 'changed' 
                    }
                },
                fields: [...]
                });

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 61,722Questions: 1Answers: 10,108 Site admin

    If we are only processing 'changed' data, I don't understand why it expects the entire data set back.

    It doesn't expect the full data set (i.e. all rows), but it does expect the full data object for the row that was edited. Are you able to modify your server-side to do that?

    The reason for this is that it allows for server-side or database set fields to be updated. For example an "Update time" field, or "Updated by", etc.

    Having said that, I do recognise that this isn't always useful (it plays to the lowest common denominator, which is why it is done this way), and to plan to look into allowing just partial updates in a future release.

    Regards,
    Allan

  • vg10vg10 Posts: 11Questions: 3Answers: 1

    Ah ok, thank you Allan, that clarifies the problem. Yes, I can update the server-side to return the entire row, and that would be a reasonable amount of data to pass around. It didn't occur to me to try that, but I will now. Thank you!

  • vg10vg10 Posts: 11Questions: 3Answers: 1

    Hi again Allan, I now have the data layer returning the entire row after an update. But I'm having a hard time getting it into the correct format, primarily because I can't reuse the structure that first initializes DataTables. For example, when I serialize my data for DataTables initialization, a list of a single record (keeping it simple) would look something like this:
    [{"EditID":"PKval", "data1":"data1Val", "data2":"data2Val"}]

    Whereas to return it to line 16 above (callbackData.data = [ rtnData ];) then I ~think~ my rtnData is supposed to look like this:
    {{"PKval": {"data1":"data1UpdatedVal", "data2":"data2Val"}}}

    Those are two pretty different formats, and the data layer always returns the former. First, is the latter format correct? If so, do you have any tricks to convert it from the former to the latter?

    As an alternative, even tho I spent quite some time to get the data types to all be string so that the inline:submit:'changed' option would work, I'm thinking I should put it back to 'all' and do my own dirty-checking on the server-side so that I can then pass the whole thing right back. Would that be advisable?

    Thanks,
    -Vanessa

  • allanallan Posts: 61,722Questions: 1Answers: 10,108 Site admin
    Answer ✓

    Try this:

    callbackData.data = rtnData;
    

    Its just an array rather than an object that needs to be returned. The full protocol is described here.

    You are right in that it does submit with the primary key in the object label, but that isn't the case in the return - the plain array should do it.

    Allan

  • vg10vg10 Posts: 11Questions: 3Answers: 1

    Oh thank goodness. Silly me, the original data was not passed as an array, so I should not have done so for the ajax response. Got it! All set now. Thank you so much. :smile:

This discussion has been closed.