PagedTable and PagedList
There are two supported pagination tags in Loom used to generate tables and unordered lists:
Pagination done by the database
The best performance will be obtained by delegating pagination to the database. In this case, only the JPA query is required:
That's it, You don't have to care about pagination and sorting. If your application must use a non-JPA backend, it is quite easy to implement your own query() method.
Pagination done by the web layer
For applications where there is no database, the pagination can be performed at the web layer.
Pagination and sorting will again be transparent as long as all sortable columns implement Sortable.
Be aware that this practice has some drawbacks:
- The entire list of paged data must be allocated in memory. If this list is big enough, it could bring your server down.
- Performance is usually better if pagination is done by the backend.
Internationalization
To translate your pagination components you should include the following entries in your messages.properties file:
If a table must use a specific translation it can specify a "messagePrefix" attribute, which would replace the "paged" default. For example:
These entries use the same translation rules of all Loom components, so you can specify "previous" instead of "paged.previous" and "conversations.previous".
Non-paged collections
We found that paged tags are a convenient way of displaying non-paged data, so we now also accept plain Collections using the "collection" attribute.
More than one container in the same page
If you plan to display more than one table in the same HTML page you should indicate an ID when creating your PagedListRequest instance, otherwise the "next" and "previous" buttons would affect both tables at once:
Ajax paged lists
Paged lists can now be returned as JSON to be used with Ajax interfaces. This will render on the browser the same javascript of the JSP tags including the browsing buttons. Examples of use are:
