Feature Request: Searchable Field Names
Feature Request: Searchable Field Names
tacman1123
Posts: 199Questions: 46Answers: 1
Version 1.8 has opened up some flexibility in how server-side processing is handled. One of the most complicated things to handle, though, on the server side is searching, because the search fields come in with an indexed field name, requiring all sorts of back-end processing to figure out which field is being searched:
[code]
?sEcho=4&iColumns=22&sColumns=&iDisplayStart=0&iDisplayLength=10&sSearch=test&bRegex=false&sSearch_0=&bRegex_0=false&bSearchable_0=true&sSearch_1=&bRegex_1=false&bSearchable_1=true&sSearch_2=&bRegex_2=false&bSearchable_2=true&sSearch_3=&bRegex_3=false&bSearchable_3=true&sSearch_4=&bRegex_4=false&bSearchable_4=true&sSearch_5=&bRegex_5=false&bSearchable_5=true&sSearch_6=&bRegex_6=false&bSearchable_6=true&sSearch_7=&bRegex_7=false&bSearchable_7=true&sSearch_8=&bRegex_8=false&bSearchable_8=true&sSearch_9=&bRegex_9=false&bSearchable_9=true&sSearch_10=&bRegex_10=false&bSearchable_10=true&sSearch_11=&bRegex_11=false&bSearchable_11=true&sSearch_12=&bRegex_12=false&bSearchable_12=true&sSearch_13=&bRegex_13=false&bSearchable_13=true&sSearch_14=&bRegex_14=false&bSearchable_14=true&sSearch_15=&bRegex_15=false&bSearchable_15=true&sSearch_16=&bRegex_16=false&bSearchable_16=true&sSearch_17=&bRegex_17=false&bSearchable_17=true&sSearch_18=&bRegex_18=false&bSearchable_18=true&sSearch_19=&bRegex_19=false&bSearchable_19=true&sSearch_20=&bRegex_20=false&bSearchable_20=true&sSearch_21=&bRegex_21=false&bSearchable_21=true&iSortingCols=1&iSortCol_0=6&sSortDir_0=asc&bSortable_0=true&bSortable_1=true&bSortable_2=true&bSortable_3=true&bSortable_4=true&bSortable_5=true&bSortable_6=true&bSortable_7=true&bSortable_8=true&bSortable_9=true&bSortable_10=true&bSortable_11=true&bSortable_12=true&bSortable_13=true&bSortable_14=true&bSortable_15=true&bSortable_16=true&bSortable_17=true&bSortable_18=true&bSortable_19=true&bSortable_20=true&bSortable_21=true&_=1308002297568
[/code]
In the same way that headers can now contain ID's for processing in the display -- that is, you no longer need to use an index to get at the other data elements in a row -- it would be MUCH easier if the search fields were named with something derived from the TH elements. So a search / sort request would look like
bSortable_Lastname=true&sSearch_Firstname=Michael&bRegex_Zipcode=\d*
If it's important to maintain numeric support, maybe something that either includes the name in the URL (starting to get absurdly long) or maybe put the number in the field name, e.g. bSortable_3.Lastname=true
Right now, we have to tie the searches to the display, but since the search results can now be in an object form (not numerically indexed as pre-1.8), it makes sense that the search is now the same.
Thanks for considering this.
Tac
[code]
?sEcho=4&iColumns=22&sColumns=&iDisplayStart=0&iDisplayLength=10&sSearch=test&bRegex=false&sSearch_0=&bRegex_0=false&bSearchable_0=true&sSearch_1=&bRegex_1=false&bSearchable_1=true&sSearch_2=&bRegex_2=false&bSearchable_2=true&sSearch_3=&bRegex_3=false&bSearchable_3=true&sSearch_4=&bRegex_4=false&bSearchable_4=true&sSearch_5=&bRegex_5=false&bSearchable_5=true&sSearch_6=&bRegex_6=false&bSearchable_6=true&sSearch_7=&bRegex_7=false&bSearchable_7=true&sSearch_8=&bRegex_8=false&bSearchable_8=true&sSearch_9=&bRegex_9=false&bSearchable_9=true&sSearch_10=&bRegex_10=false&bSearchable_10=true&sSearch_11=&bRegex_11=false&bSearchable_11=true&sSearch_12=&bRegex_12=false&bSearchable_12=true&sSearch_13=&bRegex_13=false&bSearchable_13=true&sSearch_14=&bRegex_14=false&bSearchable_14=true&sSearch_15=&bRegex_15=false&bSearchable_15=true&sSearch_16=&bRegex_16=false&bSearchable_16=true&sSearch_17=&bRegex_17=false&bSearchable_17=true&sSearch_18=&bRegex_18=false&bSearchable_18=true&sSearch_19=&bRegex_19=false&bSearchable_19=true&sSearch_20=&bRegex_20=false&bSearchable_20=true&sSearch_21=&bRegex_21=false&bSearchable_21=true&iSortingCols=1&iSortCol_0=6&sSortDir_0=asc&bSortable_0=true&bSortable_1=true&bSortable_2=true&bSortable_3=true&bSortable_4=true&bSortable_5=true&bSortable_6=true&bSortable_7=true&bSortable_8=true&bSortable_9=true&bSortable_10=true&bSortable_11=true&bSortable_12=true&bSortable_13=true&bSortable_14=true&bSortable_15=true&bSortable_16=true&bSortable_17=true&bSortable_18=true&bSortable_19=true&bSortable_20=true&bSortable_21=true&_=1308002297568
[/code]
In the same way that headers can now contain ID's for processing in the display -- that is, you no longer need to use an index to get at the other data elements in a row -- it would be MUCH easier if the search fields were named with something derived from the TH elements. So a search / sort request would look like
bSortable_Lastname=true&sSearch_Firstname=Michael&bRegex_Zipcode=\d*
If it's important to maintain numeric support, maybe something that either includes the name in the URL (starting to get absurdly long) or maybe put the number in the field name, e.g. bSortable_3.Lastname=true
Right now, we have to tie the searches to the display, but since the search results can now be in an object form (not numerically indexed as pre-1.8), it makes sense that the search is now the same.
Thanks for considering this.
Tac
This discussion has been closed.
Replies
That's a good idea. Not something that I will do for 1.x since it would break backwards compatibility, but certainly something to consider for 2.x. However, one option you have at the moment is to use the sName parameter - which results in a comma separated list of the column names being sent to the server. It does mean you would need to look the index integer up in that list, so an extra step, but the basic idea to separate the index from the data should be possible.
Allan