Re-setting the initialization options for columnFilters plug-in?

callahan09

Hi,

I am using the columnFilters plug-in for my DataTables implementation. There are about 10 fields that are visible, and another 10 or so that are invisible to the user. The 10 visible fields have filtering in the footer. The other 10 fields are still filterable, despite not being visible, and their filters are in an additional part of the page under the table, using the sSelector feature of columnFilters. These filters are "select" types.

Now, here's what I'm trying to do which has unorthodox behavior: One of my fields needs to have the option to be changed from a "select" drop-down with some 2500 options in it, to a plain text-box field, at the click of a button that the user can toggle. So I have my columnFilters initialization happening inside a function which is called after the DataTables implementation on document.Ready, and also is called when that button to change the filter input type is clicked. This function has an options parameter, which just lets you pass in whether you want this particular field to be a "select" or "text" type.

So, when I call the initialization for columnFilters the second time, to change the input type of that one filter, it causes a problem.

All of the filter select drop-downs that are in the table footer have their default value changed, and their id changed, by having all of the options available in the drop-down appended to the end of the default value and the element id. This means that my custom CSS styling that I might apply to those element id's will not apply anymore, because the id is changing, as well as the default value having more text appended to it which hurts the aesthetic appearance, but does not seem to effect the functionality of the filter.

Interestingly enough, this bug is only effecting the "select" type filters in the table footer. The "text" type filters in my table footer remain correct, and the "select" type filters in the additional filters div at the bottom of my page even remain correct (id and default value do not have the select options appended).

So I tried to do something like initializing the columnFilters with no options passed in prior to re-initializing, to see if it re-sets everthing, but this just creates other issues (the fields that aren't supposed to have filters at all will now have filters, and the ids and default values do not appear correctly for ANY of the filters, including the ones outside of the table footer).

So is there a way to completely remove the columnFilters prior to re-initializing?

I wonder why only the ids/initial values of the "select" inputs in the table footer are buggy, and the ones outside of the table footer remain fine... Perhaps I can go into the columnFilters source and see if I can find the bug and correct it...

For now, my only solution has been to have a php parameter for the input type of that particular columns filter, and when the toggle button is pressed, reload the page, passing the parameter for the user-defined input type, and every time the page loads and initializes everything it would set it up according to the passed in parameter... This functionality does not seem ideal, however...

If you need me to provide more information on this, or a link of any kind to see the behavior in action, please ask and I shall provide.
Thanks!

callahan09

Actually, after further investigation, it IS any filter input type in the table footer that is effected. I missed it earlier, but the id for those fields is indeed altered as well, but rather than appending values to the end of the id, it removes the column name from the id.

callahan09

Well, it's kind of messy, and it certainly isn't ideal (in my opinion), but I've come up with a solution...

First, the problem is arising because the "label" (which is used for the id and the initial value) acquired by columnFilters is based on the text value of the footer element. When the filter input is placed in the footer, it alters the original footer element, which causes that label, when the filters are re-initialized, to be different than what it was in the original initialization, to buggy effect.

So, I added some code to columnFilters to adjust the label acquisition when the footer element already has an input. It is kind of messy, because it has to check to make sure there is an input element in there, and if so, it has to do another check to see if it's a select or a text input. Then it acquires the correct value from that...

Here's what I added.

[code]
var child = $($(this)[0].cell.firstChild);
if (child[0] != undefined)
child = child[0];
if (child.childNodes.length >= 1)
{
var childChild = child.firstChild;
if (childChild[0] != undefined)
childChild = childChild[0];
if (childChild.innerHTML != '')
label = childChild.innerHTML;
else if (childChild.value != '')
label = childChild.value;
}
[/code]

That line was placed under the line
[code]
label = $($(this)[0].cell).text(); //Fix for ColVis
[/code]

Which is around line 642 in the version of columnFilters.js I'm using.

It works well so far, except that when the filter input type is changed dynamically, the new input does not contain the value of the currently applied filter on that field, which is not ideal, but it's working OK for now. With some code added in my toggle button, I should be able to make it fill that value back into the new input field when it finishes initializing the columnFilters...