This page last changed on Dec 04, 2009 by etj.

Motivation

Existing methods used to retrieve lists of resources may be inefficient when dealing with long lists. We need a way to split resource lists in pieces.

Proposed changes

  • All the methods that return Lists should be "pagified". Should investigate if some of them could be reasonably bounded (ie: workspaces, namespaces)
  • Such pagification should be done by replacing the generic getXXX(params) method with a pair of methods:
    • getXXXCount(params, filters): return the total number of filtered items;
    • getXXXList(params, filters, range, sorting): return a page of the sorted filtered items.

Filter: We may want to have only a subset of the requested resources. We need to define a generic way to filter resources. Such filter would then be applied on the getCount(), as well as to the getList().

Range: Defining the range can be as easy as setting the starting element and the max number of wanted results.

Sorting: We also need a way to define the sorting fieldset.

UI Modification

Once the pagificated Catalog is working, the UI should be rewritten in order to use the new paging methods.

At the moment UI procedures assume that calls to the catalog are low-cost calls. This is no longer the case; Calls should be minimized.
e.g.: The Layers web page calls the getLayers() 7 times in order to show the layer list. Some of the calls could be replaced by the getXXXCount() call.

Document generated by Confluence on May 14, 2014 23:00