Skip to end of metadata
Go to start of metadata

Client-side design

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.

Component changes

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.

Server design

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?).

  • No labels


  1. This looks really good overall. Some notes on questions you had:

    We need to store page selected somewhere like we do for tables (session I believe) and restore state when needed.

    DataTables actually handles this all on its own, so we will need to recreate this ourselves. My suggestion would be to follow the model we do for maintaining other component state (check something like disclosure).

    useServerPaging and pageSize

    I would vote for having these on CollectionGroup and reading them where necessary

    I would also vote for note supporting client side paging at this time, and pageClientBufferSize  sounds like a good idea but make it a secondary requirement.

    Creating Pager or Page component

    This sounds like something that would be good to look at, but I wondering about the same things (how would it work with stacked layout and so on). Another possibility might be to create a Pager widget that is used for creating the Bootstrap paging component, and at a later time would good look at making a PagerGroup which would add support for general group paging. 

    Server Design

    Sounds good here. Having the separate ftl and controller method sounds good as well.You might find some reusable code from DataTablesPagingHelper. I think we will be fine with session. If you run the component lifecycle it will update the component in session. In terms of the model data itself this will be the applications responsibility. 

    Another thing I just wanted to mention for you to keep in mind. I am still wondering about table sorting and the colspan/rowspan. One thing I was wondering about is if it would be possible (and beneficial) to not use the data tables pager but to use our own paging component that we are building here. Then it could stream back the html for the page, and we could support the col/row span. Something to think about not only for the functionality, but the consistency of the pager.

    1. On the last thing here, we would likely be able to support colSpan/rowSpan with a large amount of difficulty, but we would break everything else datatable provides us.  I don't think this is feasible.  It sounds like we may be able to get rowSpan working from preliminary investigation, but colSpan not so much (I still fail to see the value of colSpan when we have FieldGroup, which visually and conceptually is the same thing to the user). 

      These were non-trivial changes to get it working in the state it is in now with datatable.  If we are going to investigate/build something like that we might as well build our own table implementation  (which I want to say I am against, because colSpan is a highly trivial feature for the amount of effort required).


  2. What is our long view on using DataTables?  I vote for trying to make our configuration consistent across the two table types to the extent possible.  Perhaps we can model our initial implementation of paging controls on what DataTables provides as well, with the intent of creating a consistent experience to the extent possible?  

    I get what Jerry is suggesting about using our own pager for both, that would solve the consistency issue as well.  I wonder if there are disadvantages of re-initializing the DataTable each time, or if there are ways to avoid it?

    An alternate naming suggestion for pageClientBufferSize: readAheadPages.