Grid with server side pagination

[mgrouch]

I can't find an example... Is it supported?

Thanks
--MG

[Isomorphic]

SmartGWT/SmartClient grids are "live grids" - they fetch data as they are scrolled. See the RestDataSource for some examples of how you can receive the startRow and endRow that the grid is requesting.

[mgrouch]

So pagination is not supported?

So pagination is not supported...

How about server side sorting?

Thanks

[Isomorphic]

To clarify, data paging / pagination is supported with a "live grid" (load data on scroll) interface. This means that data will be loaded in pages as the user scrolls, without the need for a separate UI to select pages by clicking on separate navigation controls.

It is also possible to build a web-1.0 style external pager, and an in-depth example is posted here. However this example is in JavaScript and uses some APIs (ResultSet) that aren't exposed in SmartGWT yet, but will be exposed in upcoming nightly builds.

Yes, server-side sorting and filtering is supported, as well as adaptive sorting and filtering in which sorting and filtering occur on the client side when a full cache is obtained. See the ResultSet overview doc from the ordinary SmartClient Reference for the best overview of these capabilities. Not these features are already present in SmartGWT, it's just the ResultSet doc that's missing.

[mgrouch]

Pagination control would be very welcome addition

Pagination control would be very welcome addition.
It helps user to understand on which page of data he is looking,
how many records in total are there, etc.

It is hard to go to a particular page by using just scroll bar
(plus it creates unnecessary queries to DB while user scrolls it).

Thanks,
--MG

[Isomorphic]

SmartClient's LiveGrid waits for the user to hesitate before initiating a fetch, and scales the thumb to help indicate position and relative size of the viewport vs all available records.

If you want a numeric indication of the total rows and currently visible rows, this is easy to add based on getTotalRows(), getVisibleRows() and the ability to add a ToolStrip component to the grid's layout via ListGrid.gridComponents.

Consider also the severe disadvantages of link-based or "pagination bar" paging - we'll just post these here so they're summarized:

1) arbitrary page boundaries can separate two or more records that a user wants to view or edit together

2) conflicts with key grid features: auto-fitting to record content, expanding row interfaces (including the "group by" feature), and variable-height records all imply that *both* the scrollbar and link-based pagination will be need to be used on a single grid, which is confusing and has poor usability.

3) inconsistency: link-based pagers are essentially unusable for large trees (eg a user opens a folder and the child nodes appear on the next page) so the user ends up dealing with large data with two separate mechanisms.

4) less compact: a link-based pager burns additional screen real estate

[mgrouch]

I was talking about AJAX based paging like in GWT-EXT (ExtJs)
with next/previous/last/first and go-to-page functionality.
(not link based one).

I still think it is essential feature that is currently missing in SmartGWT.

Thanks,
--MG

[Xandros]

Live grid with pagination bar

See similar post "Live grid with pagination bar"

[Isomorphic]

Hi mgrouch,

Whether links or next/last buttons are used, paging via external controls has all of the previously mentioned disadvantages relative to scrollbar-based "live grid" paging.

As we mentioned some people have a hard requirement for that kind of pager, and so we'll put together a SmartGWT-specific example at the least, but if you don't have a hard requirement, we highly recommend you switch to "live grid"-style paging.

As an aside, we've seen 3 projects now where supposedly "the users" required link/button-based paging, but when the users actually saw scrollbar-based paging, they preferred it. There's definitely a lot of myths going around about link-based paging being what users prefer or expect. If you have the opportunity to verify user preference using a live user and a live interface, try it and see :)

[hucmuc]

Hi mgrouch,

Whether links or next/last buttons are used, paging via external controls has all of the previously mentioned disadvantages relative to scrollbar-based "live grid" paging.

As we mentioned some people have a hard requirement for that kind of pager, and so we'll put together a SmartGWT-specific example at the least, but if you don't have a hard requirement, we highly recommend you switch to "live grid"-style paging.

As an aside, we've seen 3 projects now where supposedly "the users" required link/button-based paging, but when the users actually saw scrollbar-based paging, they preferred it. There's definitely a lot of myths going around about link-based paging being what users prefer or expect. If you have the opportunity to verify user preference using a live user and a live interface, try it and see :)

I would like to ask a question since my experience with large data sets is different.

The live data set is conceptually good but in our instance impractical for huge datasets. It is not possible to figure out or impractical to extract the real count of the resultSet in the database.

What we have done in the past is to only indicate that there are more records but never give a precise count. Hence, we limit the resultSet to the page size plus one.

What is the suggested approach to the live grid where the total count is not known?

[Isomorphic]

Hello hucmuc,

You handle this in SmartGWT exactly as you describe - indicate that there are more records with providing a precise count. This is discussed in the docs for ResultSet, which don't appear in the SmartGWT docs yet, but will soon:

Paging and total dataset length

When using data paging, the server communicates the total number of records that match the current search criteria by setting DSResponse.totalRows. The ResultSet will then return this number from getLength(), and ListGrids and other components will show a scrollbar that allows the user to jump to the end of the dataset directly.

However, the ResultSet does not require that the server calculate the true length of the dataset, which can be costly for an extremely large, searchable dataset. Instead, the server may simply advertise a totalRows value that is one page larger than the last row loaded. This results in a UI sometimes called "progressive loading", where the user may load more rows by scrolling past the end of the currently loaded rows, but is not allowed to skip to the end of the dataset.

No client-side settings are required to enable this mode - it is entirely server-driven. However, it is usually coupled with disabling sorting, since server-side sorting would also force the server to traverse the entire dataset.

[hucmuc]

The docs make it clear. Thanks.

[jasonzhang2002]

livegrid has it own disadvantage.
For example, 1)you can not select all records without scrolling all record into display first. End user can not understand this. 2) Selecting for live grid is slow. 3) it visually encourages end user to scroll/load unneeded records. End user is not aware that the scrolling will trigger a server loading and it has performance impact. End user only observed that display of scrolled records has some unexpected delay.
On the other hand, paganization-style grid confines the end user on a small set of records. Selecting is fast. Delay from from page to page is well-expected.

[falco]

estimating total number of rows

If counting all matching records is too expensive, you could estimate or simply set a number large enough too allow more scrolling (consider viewport and datapage size, inspect start/end row coming in DSrequest and so on... ).
In such a situation the vertical scrollbar of ListGrid won't reproduce the exact quota of fetched data, and each pagination might "resize" the scroll range.

I agree with Isomorphic that "page/block" pagination is not so ergonomic compared with scrolling, IMHO.

HTH
falco

[sjivan]

livegrid has it own disadvantage.
For example, 1)you can not select all records without scrolling all record into display first. End user can not understand this. 2) Selecting for live grid is slow. 3) it visually encourages end user to scroll/load unneeded records. End user is not aware that the scrolling will trigger a server loading and it has performance impact. End user only observed that display of scrolled records has some unexpected delay.
On the other hand, paganization-style grid confines the end user on a small set of records. Selecting is fast. Delay from from page to page is well-expected.

Are you volunteering to convert the SmartClient pager code to SmartGWT? :)

I'm sure others will find it useful too. It's planned to be added to SmartGWT but if you get to it first, it would be a great addition to smartgwt-extensions for now and perhaps it can be later added to core.

Sanjiv