Out of the box behavior of the Pagination control

Question

Why does the Pagination invoke the PageFactory callback upon page count change?  And when it does invoke it, why is it with currentPageIndex=0?  Should there be an API to remove this listener if this is undesirable behavior?  If we know we may need to alter the Page Count after construction of the Pagination control, would it be best to remove the old one, and construct a new one for display at that point since the current implementation seems to behave inconsistently when one wants to alter the Page Count post-construction and/or callback configuration.
Please consider the following scenario:
The user is viewing a TableView of items.  Below the TableView is a Paginator whose PageFactory callback fetches rows from a database and calls TableView.setItems(<results>).  There are 3 pages and the user is on the 3rd page.  Only 5 rows remain out of a possible page size of 20.  The user decides to delete the 5 remaining rows on page 3 from the table/database.  Now it would seem natural at this point to conclude that page 3 no longer exists and we would want to the user to return to page 2.  If we simply call paginator.setCurrentPageIndex(currentIndex - 1) then we will correctly transition the user to Page 2, however Page 3 will remain displayed in the Pagination control and if the user browses back to that page, he is met with the "There is no content to display" label.  So it would seem natural that we could presume this happening and instead call paginator.setPageCount(2), then paginator.setCurrentPageIndex(currentIndex - 1).  That way the Pagination control reflects an accurate number of pages.  Unfortunately, this results in TWO callbacks to the PageFactory method, one at currentPageIndex=0 and another at the correct index.  Sometimes the widget that is constructed in the PageFactory callback (TableView) doesn't get displayed properly (disclaimer: speculation ahead) probably due to some asynchronous nature of the two competing callbacks (?).
I'm struggling to get a handle on this control.  So far, my experience with TableView has been pretty good.  I love the features you get with this Pagination control out of the box, but some of the choices that were made with regards with what APIs to expose confuse me.  The frustrating thing about callbacks is that sometimes you can get caught in this callback hell where there are all sorts of callbacks being invoked and you don't really know why.  Often times, the Javadoc does not indicate that there is a default listener being applied to certain property that may invoke one of these callback.  I don't mean to sound like a rant.  Overall my experience with JavaFX 8 has been very positive so far.  I can usually always find a workaround if a come across a weird issue with an out of the box control.  Worst comes to worst, I'll write my own Pagination control.
Thanks for your time.

Answer 1

For anyone else that may come across this post.  I was able to find a workaround by simply using a field, boolean pageCountReset, and then bounding all of the logic in my page factory call back with a condition checking for this boolean value i.e. if (!pageCountReset) // continue, else // noop.  Then, if I need to reset the page count, I set my boolean to true so that the page factory callback results in a noop.  Because the pagination control under the hood will make currentPageIndex=0 (as I talked about above) if the page count is reset, I then have to be very explicit and either call my page factory callback manually to refresh the current page if it still valid, or I call pagination.setCurrentPageIndex(<new index>) so that the page factory callback will be invoked and pageCountReset will be false at this point, so I can successfully transition pages.