Replies

• kthorngren Posts: 20,361Questions: 26Answers: 4,777

  May 2020

  I believe what you are seeing is the table being updated for sorting and searching which requires a draw() of the table. Since this is server side processing a request is sent to the server to update the page.

  Kevin
• dlanz38 Posts: 17Questions: 4Answers: 0

  May 2020

  Thank you kthorngren. Why is it trying to search and sort? Nothing besides the single record has changed.

  Is there a way to prevent it from updating for searching and sorting? Only the single record changed, so I don't need to do all that additional processing. Really just need to update the DOM with the new values for the single record.
• kthorngren Posts: 20,361Questions: 26Answers: 4,777

  May 2020

  Take the example you linked to which is sorted by the first name. Update one of the first names by prefixing it with a different letter. The record is sorted into its new position. This is done by requesting the updated page from the server. Do you want to turn this off?

  I'm not sure of a mechanism to stop the draw() from happening after a successful update. It is possible one of the Editor Events may allow for this. Did you search the forum? One of the developers may respond tomorrow with any options you may have.

  Kevin
• dlanz38 Posts: 17Questions: 4Answers: 0

  May 2020

  Hmm, that is a good point you make with that example. I hadn't considered that. However, if the user changes a record and it automatically resorts the table, there is the possibility for the record to jump 100 pages worth of data away. From the user's perspective, they just made a change and now it seems as if the record was deleted.

  I could see the advantages and disadvantages of both methods. However, by not having this behavior be the default, you allow the developer to choose which method suits their particular application best. As you suggest, one could just hook into an event and trigger the reload that way.
• kthorngren Posts: 20,361Questions: 26Answers: 4,777

  May 2020

  The behavior is no different than with client side processing. The row could move out of view. I know similar questions have been asked but not finding anything at the moment.

  As you suggest, one could just hook into an event and trigger the reload that way.

  I meant a way to stop the draw() from happening. I'll post if I find anything otherwise someone smarter than I should respond tomorrow

  Kevin
• dlanz38 Posts: 17Questions: 4Answers: 0

  May 2020

  How would you be able to prevent the draw() from happening by hooking into an event? Isn't anything you add as part of a hooked event executed in addition to the baseline functionality? Not instead of?
• colin Posts: 15,158Questions: 1Answers: 2,587

  May 2020

  However, if the user changes a record and it automatically resorts the table, there is the possibility for the record to jump 100 pages worth of data away. From the user's perspective, they just made a change and now it seems as if the record was deleted.

  It would only do that if the change was made to the column being used for sorting, and in that case, that would be the expected behaviour. If you changed the name of someone from "Ashton" to "William", you wouldn't expect that record to remain in the same place if the table was being sorted by the name column.

  If you want records to remain in the same place, you wouldn't need to disable sorting.

  Colin
• kthorngren Posts: 20,361Questions: 26Answers: 4,777

  May 2020

  I did a forum search and found this thread. Looks like there is a form-option of drawType to stop the draw(). The thread is for inline editing, not helpful yet. Did a search for drawType and found this thread. Looks like you can do something like this:

  editor.on('submitComplete', function () {
    table.draw(false);
  });
  

  Haven't tried it myself but sounds reasonable. Let us know.

  Kevin
• dlanz38 Posts: 17Questions: 4Answers: 0

  May 2020

  Hi @kthorngren, thank you for the link to those threads. I'm going to have to go through this and play around with it, but it seems promising. I'll update once I have something concrete.

  @colin In this particular application, I expect a user to update each record in the list. For some users, it may be easiest for them to sort by date, others it may be by item# or something else even. Point is, the ability to sort is a requirement. With that said, it would be very difficult for the user to keep track of what they've edited and what they haven't if the records keep jumping around. Given that it seems like preventing this is not possible (or at least not without workarounds) while adding a table.draw() to a built in event is relatively simple. We'll have to agree to disagree that this behavior should be the default. But that's just my two cents, and no one has to listen to me

  Still love Datatables at the end of the day
• allan Posts: 61,814Questions: 1Answers: 10,123 Site admin

  May 2020

  Thanks for the feedback - as Kevin says, the drawType option of form-option can be used to stop the draw - you could use it like this in the Editor initialisation options:

  formOptions: {
    main: {
      drawType: 'none'
    }
  }
  

  However... You are using server-side processing which adds an extra complication. In that mode, every draw of the DataTable will always make a request to the server for the data. As noted above it allows for filtering and sorting to be taken account of (e.g. the new record might not match the filtering criteria applied to the table - perhaps unlikely, but perfectly acceptable!) - hence the need for the draw.

  What I'd like to do to resolve this, is have the Editor submit request include DataTables' server-side processing parameters so it can apply the server-side processing immediately and return the data for the draw from that create / edit / delete request, rather than needing a second Ajax call.

  It is in our feature tracker to be implemented, but we've been working on other features and it hasn't been done yet I'm afraid. I don't yet have a time line for when it will be done, since the workaround of the second Ajax call works (if not optimally).

  Allan
• dlanz38 Posts: 17Questions: 4Answers: 0

  May 2020

  Thanks @allen,

  Good to hear it's on the feature tracker can't wait until it hits release. I'm going to be playing around with all the leads I've got here and see if I can get something to work the way I need it in the mean time.

  Much appreciation!
• AnthonyV Posts: 37Questions: 7Answers: 0

  October 2020

  Hello Allan, I ran into the identical issue and my solution based on your comment above was to set the drawType for the inline editing to 'none' as below. To me that is the better behaviour for the moment.

  formOptions: {
    inline: {
      drawType: 'none',
      onBlur: 'submit'
    }                    
  }
  

  Having records jump around while users are editing would be seriously confusing.

  My users are asking me to mimic Excel like behaviour so they would not expect the records to shift while they are editing.