Use the paging style/widget provided by bootstrap since jquery ui does not yet provide one. This requires us to fully handle what these links do.
The ftl must output a div with a ul and li structure for this design. Collection size and items per page must be known in advance to output numbering correctly. Dependent on number of pages, we must have conditional way to display the pages for when number of pages becomes very large for example:
< 1 2 3 … 501 502 503 >
Current page would have active style, “…” would have disabled style or alternative.
What is too many to display to be determined, recommendation is about 7-10 page links.
When clicking the links we must send an ajax request (using our standard mechanisms, with page number passed through the data option) to the server to get the next page of content for the stacked layout. It is assumed that the collection is presorted in the order desired by the application and will not be resorted for stacked collections. On return of the content, content should be swapped out (animation?) and active page updated in the links (therefore these links must be selectable by id).
Undetermined whether we should put paging on top or bottom of stacked collection, or both (recommendation is both, or options for configuration of this). Stacked layouts should have some border/shadow, or something to separate their content from the rest of the page content so it is clear what will change when a user clicks a page button.
We need to store page selected somewhere like we do for tables (session I believe) and restore state when needed.
Have variables for:
useServerPaging – this exists on CollectionGroup already (we may consider moving this to avoid the problem described below)
pageSize – this should default to 5 or 10 (recommendation is 5, since stacked is more screen real estate heavy than tables). Where should this variable live??? If in CollectionGroup also, we should push pageSize through to RichTable for TableLayoutManager.
pageClientBufferSize (bad name probably) – additional pages to send along with the first for immediate page change client-side for no delays on the next few pages (was suggested at one point, optional)
startIndex - internal variable for start index in collection data
endIndex - internal variable for end index in collection data
should we support client only paging (this would be have to be handled a bit differently probably delay the scripts til paged to)????
Also, FYI, there is various problems with regards to paging and collections with messaging and validation that currently exist but aren’t high priority or breaking too much (yet). I think there is a jira out there somewhere for this, but it requires some concrete design decisions to be made on how to handle these scenarios – off topic.
New container - Pager or Page Panel
Just a thought, maybe abstract the page idea out to take in a list of groups and it can be used more general purpose than just just used for StackedLayout. If no real need, leave it tightly coupled to the StackedLayout implementation (thoughts??). There are the obvious problems with validation/messages.
Group groupToPage - either a CollectionGroup or a Group with items declared
pagingStyle - numbered vs prev/next
placement - top, bottom, or both
Might be too much for the design to support it standalone as well. Also, it would have a weird relationship with StackedLayout (would StackedLayout contain one of these?) etc. Another alternative it to make it a widget and just pass in how many pages etc to render in it.
Only perform appropriate lifecycle on the page actually being seen (+those in buffer if we implement that) on the first pass, then retrieve additional pages for subsequent requests.
The server would have its own custom ftl for sending back stackedLayout chunks (we could possibly just use componentUpdate however and pass through this information to stackedLayout – recommendation?). Leaning towards it having its own ftl and controller method. Controller method will alter the range that the StackedLayout is performing its lifecycle on. Session will be updated with the current page selected to maintain state (do we need a flag to turn this off? Do we have the ability to turn it off elsewhere?).