Prevent whole AJAX reload after inline editing, instead redraw from return values?

Prevent whole AJAX reload after inline editing, instead redraw from return values?

marcelvmarcelv Posts: 27Questions: 6Answers: 0
edited April 2015 in Free community support

Hi,

Using datatables editable (currently trial version) I have now succesfully set up editing. But, my requests are a little bit slow since it shows a huge amount of data in the form, joined over several tables.

Using Firebug I discovered that the whole form was reloaded after submitting an inline edit. To me this seems like overkill, in case it is succesfully changed in the database, why not just redraw the input with the return value, rather then performing the whole DB request again.

So basically my question is: can I somehow prevent (maybe in an aftersubmit event or something) the new request to reload the whole table, and instead of this just redraw the input / row I changed? This would save me 3 - 4 secs of waiting every time a value is edited.

Hopefully someone can help me out, thanks a lot!

Answers

  • allanallan Posts: 61,667Questions: 1Answers: 10,096 Site admin

    This is a feature that is going to be added into Editor 1.5 :-). At the moment you would need to use the preSubmit event to remove the data that you don't want to send to the server (you could use initEdit to get a copy of the original data so you know what has changed and what hasn't).

    Allan

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0

    Ok, cool. When will Editor 1.5 be released approx?

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0

    Still one more question.. I`m looking into the preSubmit event now, but in fact I want the changed data submitted to the server, so that event should be fired.

    I now put a breakpoint on the postSubmit event and I see this event is right between where the data is submitted to the server and where the whole form reload is done.

    So I could return false in the postSubmit event to abort further processing, but then my form will keep on showing the inline edit input, so can I call something here to sort of cancel the editing so that the form is not reloaded but the inline editing dissapears?

    Hopefully you understand what I mean, thanks! :)

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0

    One more thing, I actually did put a return false on the postSubmit event now, but still it reloads the entire form. So it does the initial datatables request again.. Can I stop this from happening at all?

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0
    edited May 2015

    Ok, one more last thing..: looking into firebug with your demo: https://editor.datatables.net/examples/inline-editing/simple I can see after an value is edited inline, there is just one request done to staff.php with the newly posted data.

    So why is on my local environment 2 requests done, one to update the data, and one which reloads the whole form?

    Is this because I have different ajax url`s for editor and datatables? Datatables ajax url is ajax_data, and editor ajax url is ajax_data_edit, the reason I have 2 seperate url's is because i'm doing lots of logic behind every url so this was more convenient, but if this is the reason I will put them both into one url...

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0

    Update: I know have put both datatables request and editable ajax url into the same ajax php file, but still no luck, executing 2 requests for every record, on with the edit action and one to retrieve the whole datatable..

  • allanallan Posts: 61,667Questions: 1Answers: 10,096 Site admin

    Ok, cool. When will Editor 1.5 be released approx?

    I hope this month, but possibly next.

    Still one more question.. [...] so can I call something here to sort of cancel the editing so that the form is not reloaded but the inline editing dissapears?

    Call the close() method to remove the editing form. If you are using server-side processing (I don't know if you are), then there is no way to avoid the Ajax call.

    One more thing, I actually did put a return false on the postSubmit event now, but still it reloads the entire form

    Can you link to the page so I can debug it please.

    Allan

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0
    edited May 2015

    Thanks Allen, appreciate your help!

    I am using server side processing since my tables can grow huge (100k+ rows) so I figured that would be the most efficient way to handle sorting, searching etc.

    However, what I still don't quite get is why would this make the extra AJAX request mandatory after each edit? I do get that if I delete a record, the table would need to be redrawn using newly retrieved data, but when I'm just editing a single field (inline) it would be far more efficient to just redraw the single changed field with the new value, instead of redraw the whole page right? Or am I missing something here? :)

    BTW, I'm still not quite sure if I understand correctly what feature is going to be added in 1.5, if it is actually addressing this issue then I'll just wait for that release, but if it's not, I would love to hear any ideas on optimizing my (editing) performance on huge data (complex joined) tables.

    I currently only have the whole setup running locally, but I will deploy a testing environment soon and sent you the link then.

  • allanallan Posts: 61,667Questions: 1Answers: 10,096 Site admin

    Hi,

    You aren't missing anything - your description is absolutely spot on - it would be more efficient to use the Ajax return for Editor and not require a full redraw of the table. However, that isn't currently implemented - it is a feature that is on my to do list! At the moment, the redraw is required.

    BTW, I'm still not quite sure if I understand correctly what feature is going to be added in 1.5

    Only fields which have changed values will be submitted. If there are no changed values, it will not submit (although it could be optionally enabled).

    Server-side processing requiring an extra Ajax request is unlikely to be addressed in 1.5.

    Regards,
    Allan

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0
    edited May 2015

    Hi Allen,

    Ok, all clear then! Thanks and I`ll just await further releases and live with this for now.
    Is it likely that the service side processing issue is going to be implemented in a 1.x release? Since I see in the pricing plans that only 1.x upgrades are free? And do I receive a mail of updates on the editor / can I subscribe for this somewhere?

    Thanks!

  • allanallan Posts: 61,667Questions: 1Answers: 10,096 Site admin

    Is it likely that the service side processing issue is going to be implemented in a 1.x release?

    To be honest I don't know. That particular feature isn't currently on the 1.x roadmap, but it might be included as I update and modify my plans. If it is fundamental to your purchase then I would suggest waiting until it is implemented before purchasing.

    can I subscribe for this somewhere?

    RSS feed available here: http://datatables.net/feeds/releases.xml

    Allan

  • marcelvmarcelv Posts: 27Questions: 6Answers: 0
    edited May 2015

    Hi Allen,

    A bit late, but thanks for your answer. My trial is expired now and I'm going to buy it anyways. It is a great product and at the moment the only big issue I have is the server side processing thing. It would be great if you could put it in a 1.x release, since it is quite important to my product. But still, all the other things I can do now with the editor I could not do before are amazing and thats why im going to be a customer anyways.

    Thanks!

This discussion has been closed.