ColVis - Prevent Refresh On Serverside Table Unles Re-Sorted or Page Changed?

mparnell

I'm using ColVis to show/hide columns, and it works great. The only issue is that I'm using serverside pagination, as there are thousands of rows, and I don't really find it necessary to reload the ajax every time a column is hidden or shown, since the data and column are there, just hidden.

Is there some way I can prevent ColVis from reloading the table data unless the page is changed or one of the columns is reordered?

Thanks!

allan

For some reason that I can't quite remember, I've got this code in ColVis:

[code]
// Optimisation for server-side processing when scrolling - don't do a full redraw
if ( dt.oFeatures.bServerSide && (dt.oScroll.sX !== "" || dt.oScroll.sY !== "" ) )
[/code]

What i can't remember is why that rule is only applied when scrolling is enabled! Try removing that extra condition from ColVis and let me know how you get on. If it is successful I'll put it in the release version.

Allan

mparnell

Well, I removed that conditional and it partially fixed the issue. Hiding without reloading the ajax now works fine, however showing does not work...it also seems (note I'm using custom CSS, not jQueryUI), that the checkboxes in the dropdown list of columns aren't changing state either.

[code]
that.s.dt.oInstance.fnSetColumnVis( i, showHide, false );
that.s.dt.oInstance.fnAdjustColumnSizing( false );
that.s.dt.oInstance.oApi._fnScrollDraw( that.s.dt );
that._fnDrawCallback();
[/code]

mparnell

Let me rephrase: toggling on works for columns that are loaded with bVisible set to false. Toggling off works on visible columns. Once toggled, you can't change them back to their original visibility status for some reason.

Error output:

TypeError: a.nScrollHead is null
[Break On This Error]

...ad=c;a.nScrollFoot=f;return b}function $a(a){var b=a.nScrollHead.getElementsByTa...

jquery....min.js (line 70)

mparnell

Commenting out the _fnScrollDraw call fixes it... I think something like the below is probably more ideal for release than the original. I'd put in a pull request if I were at home. I run linux exclusively there, and have to deal with windows at work (too lazy to setup here).

Before:
[code]
// Optimisation for server-side processing when scrolling - don't do a full redraw
if ( dt.oFeatures.bServerSide && (dt.oScroll.sX !== "" || dt.oScroll.sY !== "" ) )
{
that.s.dt.oInstance.fnSetColumnVis( i, showHide, false );
that.s.dt.oInstance.fnAdjustColumnSizing( false );
that.s.dt.oInstance.oApi._fnScrollDraw( that.s.dt );
that._fnDrawCallback();
}
else
{
that.s.dt.oInstance.fnSetColumnVis( i, showHide );
}
[/code]

After:
[code]
that.s.dt.oInstance.fnSetColumnVis( i, showHide, false );
that.s.dt.oInstance.fnAdjustColumnSizing( false );

if ( dt.oFeatures.bServerSide && (dt.oScroll.sX !== "" || dt.oScroll.sY !== "" ) )
{
that.s.dt.oInstance.oApi._fnScrollDraw( that.s.dt );
}

that._fnDrawCallback();
[/code]

Thanks for the help! We use datatables a lot here at the university I work for. I may see if they can't kick over a donation of some kind.

mparnell

I forgot I had msysgit kicking around...I put in a pull request (two actually, but closed an erroneous one). I forgot to pull in the upstream before changing the file, so I had to revert before applying the above fix.

https://github.com/DataTables/ColVis/pull/10

More thought may be required, though, since I suppose we could have this conditional adjusted to that it only fires when dt.oFeatures.bServerSide is true...I'm not sure how it would affect browserside tables.

MuthuKumarinfo

In ColVis 1.0.6dev, I've noticed that if 'Enter' is pressed in a textbox input control, AND there are no other submit buttons having positional priority over the ColVis_Button (based on the browser's definition of default submit button priority), then ColVis_Button's 'click' event is triggered, and handled here:
"_fnDomBaseButton": function(text) {
...
$(nButton).bind(sEvent, function(e) {
that._fnCollectionShow();
e.preventDefault();
});
...
}
so the ColVis checkbox list appears and the default submit action is cancelled. Obviously, having over-riding submit button(s) will circumvent this behavior, but I thought I'd mention it, in case you find it helpful.