Integrated paging and sorting

MyFaces and Oracle ADF both provide paging and sorting via all-in-one JSF components. When you want to make a list's display table paged and sortable, no Java code has to be written. You just use the new JSP tags, and their component code handles all the rest.

For this to work, the central table-displaying component needs to know both the paging state and the sorting state. ADF therefore includes paging and sorting aspects directly in its one big "af:table" tag. MyFaces puts paging controls into a separate tag, "x:dataScroller", but it needs to be explicitly linked to their extended table tag, "x:dataTable".

There's obvious benefit to letting the table component itself take care of all paging and sorting. The downside is that the entire data list has to be available in memory so that the component can reach it.

The best of all possible JSF worlds for Sakai (and other) developers would be for an all-in-one pageable sortable table to also provide, as an added feature, some way to fill the current view of the data (based on the current paging and sorting states) in external, developer-maintained code (e.g., by doing a DB query that incorporates paging and sorting states). That way, we would have a smoothly incremental development process: 1) Display data in simple vanilla tables. 2) As dictated by usability tests, a simple JSP-only change can make the tables pageable, sortable, or both. 3) As dictated by performance and scalability tests, Java code could be added to take over paging and sorting duties from the component.

ADF engineers are already thinking along these lines. If the data list that lies behind the displayed table is a "CollectionModel", sorting will be handed off to that object rather than being managed internally by the component. ADF also documents a RangeChangeEvent that's fired when paging controls are activated. It may be Oracle's intent that this be used as a hook for developers to handle paging outside the "af:table" component, so that paging can be managed through a DB query rather than in memory.

SHORT TERM

For the Baseline Sakai 2.0 Gradebook, we'll probably start with extremely simple "paging control" and "sortable header" components which pass off all actual data table manipulation to backing bean code, and whose own logic will be almost exclusively devoted to the visual state of the components themselves (e.g., sticking a direction icon beside the column being sorted).

Hopefully we'll be able to move more logic out of our application code and into the components later.

LONG TERM

We suggest that Sakai try to achieve the best of all possible JSF worlds: components that deal equally well with component-managed in-memory paging and sorting, and application-managed paging and sorting.

That means, however, that the paging control component could not be completely separate from the sortable table component. At the very least, we'd have to let paging controls manipulate some state that the table component has access to.