fnDraw suggested changes
fnDraw suggested changes
jamesjburt
Posts: 8Questions: 0Answers: 0
UPDATE 2:
After I posted this, I discovered the code (emplaced by a contractor) to create three filters. Why I never noticed this before also mystifies me (smile). So this explains why three iterations of the filter was performed on the client side prior to the AJAX submission. This effectively renders my suggestion #2 below to be invalid. The code already only performs as many iterations as filters exist. Suggestion #1 and #3 still live though! JB
UPDATE:
I was mistified to discover that even though bServerSide is set to TRUE, the client attempts to filter data on client-side. Even worse, it makes the user wait for this filtering to finish BEFORE submitting the AJAX request for new data (which ironically will replace the just-filtered data). This behaviour is completely against what is expected of bServerSide.
I discovered that we must invoke oTable.fnDraw(false) to suppress client-side filtering. This is not very well documented or explained, I had to trace the code to discover it. The problem is that fnDraw() defaults to fnDraw(true) if no parameter is included. fnDraw(true) then invokes the _fnReDraw() method instead of the _fnDraw() method. This causes client-side filtering to be triggered, and it must be completed BEFORE datatables continues to the step of making an AJAX request (which will replace the entire dataset anyway!)
SUGGESTIONS:
1. if bServerSide is set to true, make fnDraw() default to fnDraw(false). There is no reason to invoke client-side filtering, sorting etc if we are subsequently going to replace the entire data set with server-side data.
2. Modify _fnFlterCustom(). Have it check for the existence of filters BEFORE iterating the entire set of displayed rows three times. There is no reason to iterate the entire set of displayed rows three times attempting to apply a filter when no filters even exist. Perhaps change the nesting of the loops?
3. At the very least, document this effect on the website.
After I posted this, I discovered the code (emplaced by a contractor) to create three filters. Why I never noticed this before also mystifies me (smile). So this explains why three iterations of the filter was performed on the client side prior to the AJAX submission. This effectively renders my suggestion #2 below to be invalid. The code already only performs as many iterations as filters exist. Suggestion #1 and #3 still live though! JB
UPDATE:
I was mistified to discover that even though bServerSide is set to TRUE, the client attempts to filter data on client-side. Even worse, it makes the user wait for this filtering to finish BEFORE submitting the AJAX request for new data (which ironically will replace the just-filtered data). This behaviour is completely against what is expected of bServerSide.
I discovered that we must invoke oTable.fnDraw(false) to suppress client-side filtering. This is not very well documented or explained, I had to trace the code to discover it. The problem is that fnDraw() defaults to fnDraw(true) if no parameter is included. fnDraw(true) then invokes the _fnReDraw() method instead of the _fnDraw() method. This causes client-side filtering to be triggered, and it must be completed BEFORE datatables continues to the step of making an AJAX request (which will replace the entire dataset anyway!)
SUGGESTIONS:
1. if bServerSide is set to true, make fnDraw() default to fnDraw(false). There is no reason to invoke client-side filtering, sorting etc if we are subsequently going to replace the entire data set with server-side data.
2. Modify _fnFlterCustom(). Have it check for the existence of filters BEFORE iterating the entire set of displayed rows three times. There is no reason to iterate the entire set of displayed rows three times attempting to apply a filter when no filters even exist. Perhaps change the nesting of the loops?
3. At the very least, document this effect on the website.
This discussion has been closed.
Replies
Thanks very much for providing feedback and insights on the issues you faced with this - I really appreciate it.
What fnDraw() should do is a full resort and re-filter of the table, while fnDraw(false) will just update the current view. Rather than modify that input parameter based on server-side processing, what I think the correct thing to do here is to modify how the filtering works and takes into account (or doesn't as the case currently is) server-side processing.
So what I've done is to modify the filtering algorithm to effectively skip the client-side filtering if server-side processing is enabled (all the stuff such as actually doing the draw, emitting events etc is still there, but the filtering logic is handed off to the server, as it should be). This I've just committed to the 1.9 development version, which you can download from the downloads page: http://datatables.net/download .
> Modify _fnFlterCustom(). Have it check for the existence of filters BEFORE iterating the entire set of displayed rows three times
It actually does this already - it sounds like you've got three filters in "afnFiltering" if it is running over the display set three times (in fact previously it did a check for afnFiltering.length > 0, but I've actually removed that now since there is a loop that doesn't almost exactly the same thing).
Having said that, due to the changes to the filtering algorithm for server-side processing, the custom filtering isn't hit at all when server-side processing is enabled now :-)
Regards,
Allan
I think you may have made an error in 1.9 while making this fix. The logic of the optional boolean parameter to fnDraw() has been reversed! I.e., fnDraw(true) causes the refiltering and resorting to be *skipped*, while fnDraw(false) [now the default behavior performed by fnDraw()] actually does the refiltering and and resorting!
I've just committed a fix which is now in the nightly on the downloads page, and will be in the 1.9.1 release.
Regards,
Allan