How does Datatables factor sSearch index for server side processing?

CGRemakes

I'm wondering how Datatables calculates the index for sSearch. Does it factor in whether columns have bVisible set? Whether they're searchable? Does it ignore the column if either the column is not visible or searchable? It doesn't always seem consistent when doing colreorder with individual column searching and server side processing, so I'll need to know how to handle it on the script side. The index value for the iSortCol value seems very consistent with the values I have for the sColumns, but the search does not. Let me know if this does not make sense.

allan

Its the column index - so bSearchable, bVisible etc are not taken into account.

ColReorder will cause the indexes to change (since the column indexes change). You generally need to map from the column index to the `mDataProp_{i}` that is sent to the server.

Allan

CGRemakes

Let me see if I can explain kinda what I'm talking about. I'm currently using the sName approach, rather than mDataProp. If it'll make a difference, I'll try that, but I don't think it will based on the issue I'm having. One major thing to note that seems to factor into this is "submit_date" and "process_date" are both hidden by setting the bVisible value to false for aoClumnDefs at initialization. I'll see if I can get a functioning demo setup in a bit, but for now, I'll just post the variables being passed to my script from DataTables.

These are some of the values from when the table is first generated, the table is sorted on the second column called "invoice_num" (index #1) in sColumns (because there are 47 columns, I'm just going to display part of the output):

[code]
bSearchable_1 true
bSortable_1 true
iSortCol_0 1
iSortingCols 1
mDataProp_1 1
sColumns col_data,invoice_num,submit_date,process_date,ship_date,company_id,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
sSearch_1
sSortDir_0
[/code]

I then drag that "invoice_num" column to the 6th position (index #5). If you notice, the sColumns shifts the "invoice_num" to the correct position, and the iSortCol_0 value is adjusted accordingly.

[code]
bSearchable_5 true
bSortable_5 true
iSortCol_0 5
iSortingCols 1
mDataProp_5 5
sColumns col_data,submit_date,process_date,ship_date,company_id,invoice_num,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
sSearch_5
sSortDir_0
[/code]

In the "invoice_num" column, I type in a search for just that column for "3813", and this is the output:

[code]
bSearchable_5 true
bSortable_5 true
iSortCol_0 5
iSortingCols 1
mDataProp_5 5
sColumns col_data,submit_date,process_date,ship_date,company_id,invoice_num,customer_id,customer_name,zip,line_num,quote_num,location,ord_cde,carrier_partner_id,product_select_code,catalog_number,serial_num,price,actual_cost,recalc_cogs,rebate_ext,rfi,psi,status,original_submit_date,manual_change_date,creation_date,general_status,general_status_description,detail_status,detail_status_description,type_of_sale,brand_original_sales,quote_line_num,quote_type,approved_dist_sell,buy_price,validated_pc,claim_adjustment,claim_num,distributor_gm_per,job_name,notes,best_quote_num,credit_memo_num,credit_memo_date,dealer_sap_num
sSearch_3 3813
sSearch_5
sSortDir_0
[/code]

If you'll notice, the iSortCol_0 value is 5, which is correct. However, the sSearch_5 (the column on which I'm searching) is blank. The value I'm typing appears in the sSearch_3, which would be the column if we ignore the columns that are not visible. If I do the same steps, but don't hide those 2 columns beforehand, it works as expected. I'm using the following:

Chrome 23.0.1271.97 m
DataTables 1.9.4
jquery 1.8.3
jquery ui 1.9.2
FixedColumns 2.5.0.dev
Scroller 1.1.1.dev
ColReorder 1.0.8

Wonder if it could be related to the issue reported here: http://datatables.net/forums/discussion/5363/colreorder-sorting-issue-shown-in-your-demo/p1

allan

Thanks for the detailed description. How are you using fnFilter with the index being passed in? I'm guessing there is a closure in your event handler there and it isn't taking into account the updated column indexing - possibly?

v.1.10 will allow sName to be passed into fnFilter (or rather you'll use `column( selector ).filter( value )` method I think) which will be much more flexible.

Another option is that there is a closure in DataTables somewhere, but since fnFilter for column filtering is called externally, I would guess its the external code.

Allan

CGRemakes

Ah, I bet you're right. The code would just look at what is in the table, so it wouldn't know about the hidden columns. This is what I have:

[code]
$('tfoot input:visible').keyup(function(){

oTable.fnFilter(this.value, $("tfoot input").index(this));
});
[/code]

Any suggestions on how to compensate for when the column is hidden?

EDIT: Well, I have a working solution, though I sense it is probably not the most efficient or eloquent. I get the correct index from sColumns and pass that instead. This is my code:

[code]
var col_search = $(this).attr('id').replace(/_search$/, '');
var oParams = oTable.oApi._fnAjaxParameters(oTable.fnSettings());
var s = String($.param(oParams).match(/&sColumns=(.+?)&/)).substring(10);
var a = s.split("%2C");
a[46] = a[46].replace(/&,col_data/, '');
var sel_index = $.inArray(col_search, a);

oTable.fnFilter(this.value, sel_index);
[/code]

Any pointers are certainly welcome. Thanks again for the help, I've been wracking my brain for quite some time over this!

allan

> Any suggestions on how to compensate for when the column is hidden?

Yes - use this plug-in: http://datatables.net/plug-ins/api#fnVisibleToColumnIndex :-)

Allan

CGRemakes

I've seen that plugin before, but there's not much information on how it works. What value corresponds to iMatch?

EDIT: Nevermind, found the answer here: http://datatables.net/forums/discussion/10147/column-filtering-on-columns-to-the-right-of-hidden-columns-not-working/p1

[code]
$('tfoot input:visible').keyup(function(){

var col_index = oTable.fnVisibleToColumnIndex($("tfoot input").index(this));

oTable.fnFilter(this.value, col_index);
});
[/code]

allan

I think you can probably shorten the parameter passed into the plug-in to `$(this).index()`, but yes, that's the idea.

Allan

CGRemakes

Get an error if I shorten it to that: "JSON data from server could not be parsed". Even in your demo on this page: http://www.datatables.net/examples/api/multi_filter.html, it uses $("tfoot input").index(this). Not a biggie, I'll just leave it as is.

allan

Yeah - demo page is from before I realised `index()` does the short form version :-). I'll update it at some point. However, as long as you've got a working solution, all is good.

Allan