Scroller bForceFetch idea for fnScrollToRow
Scroller bForceFetch idea for fnScrollToRow
Hello,
I've been working with Scroller for a bit now (large server-side tables) and in general it's wonderful.
I'm looking forward to the fnMeasure() fixes in 1.1.1+. I currently have to feed in a manual row height due to (constant-size) images in some columns. Not what this post is about though.
One interesting change I noticed when upgrading from Scroller 1.0.0 to 1.1.0 was the preservation of scrolled-to row across redraws. I *think* this wasn't happening before the change and now it is. This is useful in the context of the fnStandingRedraw() extra.
I'm doing my own 'pagination' across the server data by selecting a date range. Effectively whenever I select a new date range I'd like to forget the current scroll position (scroll to row 0) AND force a server re-fetch. This is already possible by manually triggering another redraw (e.g. calling the fnStandingRedraw() extra) before or after the scroll-to-row-0. However in the case where scrolling to row 0 triggers a refetch to the server (goes outside the 3x backing boundary Scroller maintains), the manual redraw does another fetch again; an expense I'd like to avoid. Also it's visually disconcerting because you see the old data scrolled to row 0, then the new data eventually pops up (expected outcome: you temporarily see 'processing' indicator just once, then you see the new data, already scrolled to row 0).
Ideally you could fnScrollToRow(iRow, bAnimate, bForceFetch), and avoid doing the manual trigger yourself afterwards.
Since fnScrollToRow() merely sets the scroll position and then allows the event to fire _fnScroll(), there doesn't seem to be a direct way to pass in bForceFetch to override the boundary detection in _fnScroll(). You could possibly store it temporarily in the Scroller or DataTable object, but I would be worried about it getting out of whack with whatever other async things are going on (e.g. new scrolling event while ajax fetch for DataTable redraw outstanding).
Thoughts?
I've been working with Scroller for a bit now (large server-side tables) and in general it's wonderful.
I'm looking forward to the fnMeasure() fixes in 1.1.1+. I currently have to feed in a manual row height due to (constant-size) images in some columns. Not what this post is about though.
One interesting change I noticed when upgrading from Scroller 1.0.0 to 1.1.0 was the preservation of scrolled-to row across redraws. I *think* this wasn't happening before the change and now it is. This is useful in the context of the fnStandingRedraw() extra.
I'm doing my own 'pagination' across the server data by selecting a date range. Effectively whenever I select a new date range I'd like to forget the current scroll position (scroll to row 0) AND force a server re-fetch. This is already possible by manually triggering another redraw (e.g. calling the fnStandingRedraw() extra) before or after the scroll-to-row-0. However in the case where scrolling to row 0 triggers a refetch to the server (goes outside the 3x backing boundary Scroller maintains), the manual redraw does another fetch again; an expense I'd like to avoid. Also it's visually disconcerting because you see the old data scrolled to row 0, then the new data eventually pops up (expected outcome: you temporarily see 'processing' indicator just once, then you see the new data, already scrolled to row 0).
Ideally you could fnScrollToRow(iRow, bAnimate, bForceFetch), and avoid doing the manual trigger yourself afterwards.
Since fnScrollToRow() merely sets the scroll position and then allows the event to fire _fnScroll(), there doesn't seem to be a direct way to pass in bForceFetch to override the boundary detection in _fnScroll(). You could possibly store it temporarily in the Scroller or DataTable object, but I would be worried about it getting out of whack with whatever other async things are going on (e.g. new scrolling event while ajax fetch for DataTable redraw outstanding).
Thoughts?
This discussion has been closed.