Column-based and global filtering with multiple words

Column-based and global filtering with multiple words

vsajipvsajip Posts: 17Questions: 2Answers: 0
edited December 2009 in General
Firstly, in this my first post on this forum, a big thank you to Allan for DataTables and particularly for the comprehensive documentation. I was up and running in no time.

Global filtering allows for multiple words in the search string, whereas column filtering does not - the code in _fnFilter explicitly does a .split(' ') whereas the code in _fnFilterColumn does not. Is there a particular reason for this, and is column-based filtering likely to support multiple words in the search string in the (near) future?

Regards,

Vinay Sajip

Replies

  • allanallan Posts: 61,744Questions: 1Answers: 10,111 Site admin
    Hi Vinay,

    Interestingly enough, a similar question cropped up a few days ago: http://datatables.net/forums/comments.php?DiscussionID=940&page=1#Item_2 :-)

    You have your description of who the two types of filtering work exactly right. The reason I did it this way was that I felt these would be the common usage, and the extensibility of DataTables allows other logic combinations to be used. Specifically, if you want to do the split work filtering on columns, then I'd suggest making use of the regular expression filtering that DataTables allows and just use the same code that DataTables makes use of for global filtering (see the other thread).

    I don't currently have an plans to change this behaviour, although I'm more than willing to entertain the idea of making this an option in future versions if it fits in well, and the above option isn't sufficient.

    Regards,
    Allan
  • vsajipvsajip Posts: 17Questions: 2Answers: 0
    I understand your reasoning. I tried to override _fnFilterColumn by doing

    [code]
    $.fn.dataTableExt.oApi._fnFilterColumn = function(...)
    [/code]

    where the function is a copy of your _fnFilterColumn, only with an alert(sInput) at the start just to show that it's being called. However, it doesn't get called, and I'm not sure why. I've tried placing the above statement both before and after the dataTable() call, and in both cases I'm not seeing the modified version of _fnFilterColumn being called. What am I missing?

    BTW DataTables is very extensible already, but IMO it might be useful to have another extensibility point: the mapping from filter input string to regular expression. This would e.g. allow user-defined implementation of and/or and intelligent splitting of the string, e.g. 'term1 term2 "term3 with multiple words" term4'.

    Regards,

    Vinay Sajip
  • allanallan Posts: 61,744Questions: 1Answers: 10,111 Site admin
    Hi Vinay,

    What a very interesting idea - using oApi to override functions! Unfortunately, I don't think it's possible. I've just been playing around with this idea, as it would greatly enhance the flexibility of DataTables, however, there is a good reason that it won't work. The oApi object stores a reference to the functions (in this case _fnFilterColumn is the one of interest), rather than the actual function itself. Therefore when you set oApi._fnFilterColumn to a different function, you are changing it's reference, not the original function. As such, all references to _fnFilterColumn in DataTables core, look for the original function, not your new one.

    The way to change this would be to have DataTables call the function referenced by oApi, rather than the 'static' function in the core. There might be a speed impact from this, and it would be a fair amount of re-engineering needed on the core.

    I'm got ideas to make the core much more extensible in future, and I'll certainly keep this in mind when designing the update (although it might be a little while off yet!).

    It's worth noting that you can use regular expressions in DataTables search strings at the moment. You just need to set the third parameter of fnFilter to false: http://datatables.net/api#fnFilter . So I think it's still possible to do what you want to do :-)

    Regards,
    Allan
This discussion has been closed.