Table Caching in your JSPX

Task: To render a table in a JSPX page with all rows loaded in it. There should be no "Fetching" statements when the user scrolls up and down the table, which normally appears at row 25 onwards.

Easy, right?

In practice, this was harder than it seemed.

Most blogs will tell you that you simply go to the iterator and set the RangeSize to -1.
This is OK, as it ensures that the UI layer has all the rows from the model; perfect.

Upon testing this however, you still get the "Fetching Data..." or "Going to Row [n]" when scrolling down the list.

Hmm, whats causing this?

Well, first investigation was to print out the iterators rowsize in a backing bean, to ensure I had all the rows in the UI layer:

DCBindingContainer dcBindings = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry(); 

DCIteratorBinding iterBind= (DCIteratorBinding)dcBindings.get("EmployeesIterator");

System.out.println("EmployeesIterator: "+iterBind.getAllRowsInRange().length);

This was printing the expected result: 107 rows (running off the default hr schema).

So, back to the table and I noticed that there is a definition here to control the rows shown:

<af:table value="#{bindings.Employees.collectionModel}" var="row"
    rows="#{bindings.Employees.rangeSize}"
    emptyText="#{bindings.Employees.viewable ? 'No data to display.' : 'Access Denied.'}"
    fetchSize="#{bindings.Employees.rangeSize}" 
    rowBandingInterval="1" id="t1">

So, the table uses the iterators rangeSize to decide how many rows to show.
There must be a behind the scenes conversion that if this is -1, to use a value of 25.

We can dynamically set this value to another property off the iterator, estimatedRowCount, which will return us how many rows it has. Perfect.

My new table definition is now looking like this:
<af:table value="#{bindings.Employees.collectionModel}" var="row"
    rows="#{bindings.Employees.rangeSize}"
    emptyText="#{bindings.Employees.viewable ? 'No data to display.' : 'Access Denied.'}"
    fetchSize="#{bindings.Employees.estimatedRowCount}" 
    rowBandingInterval="1" id="t1">

Upon doing this, the scrollbar could be scrolled to the end and to the top without any further messages interrupting the user.