ZK Developer's Reference/Performance Tips/Listbox, Grid and Tree for Huge Data/Implement ListModel and TreeModel

The default implementation of models, such as ListModelList and DefaultTreeModel assumes all data are available in the memory. It is not practical if a model has a lot of data. For huge amount of data, it is suggested to implement your own model by loading and caching only one portion of data at a time.

To implement your own model, you could extend from AbstractListModel, AbstractGroupsModel and DefaultTreeModel as described in the Model section. To implement a model that supports sorting, you have to implement Sortable too. Each time an user requires sorting, Sortable.sort(Comparator, boolean) will be called and the implementation usually clears the cache and re-generate the SQL statement accordingly.

Here is some pseudo code:

public class FooListModel extends AbstractListModel implements Sortable {
    private int _size = -1;
    private Object[] _cache;
    private int _beginOffset;
    private String _orderBy;
    private boolean _ascending, _descending;
    private Comparator _sorting;
 
    public int getSize() {
        if (_size < 0)
            _size = /**SELECT COUNT(*) FROM ...*/
        return _size;
    }
    public Object getElementAt(int index) {
        if (_cache == null || index < _beginOffset || index >= _beginOffset + _cache.length) {
           loadToCache(index, 100); //SELECT ... FROM .... OFFSET index LIMIT 100
                //if _ascending, ORDER BY _orderBy ASC
                //if _descending, ORDER BY _orderBy DSC
        }
        return _cache[index - _beginOffset];
    }
    @Override
    public void sort(Comparator cmpr, boolean ascending) {
        _cache = null; //purge cache
        _size = -1; //so size will be reloaded
        _descending = !(_ascending = ascending);
        _orderBy = ((FieldComparator)cmpr).getRawOrderBy();
        _sorting = cmpr;
             //Here we assume sort="auto(fieldName)" is specified in ZUML, so cmpr is FieldComparator
             //On other hand, if you specifies your own comparator, such as sortAscending="${mycmpr}",
             //then, cmpr will be the comparator you assigned
        fireEvent(ListDataEvent.CONTENTS_CHANGED, -1, -1);
    }
    
	public String getSortDirection(Comparator cmpr) {
		if (Objects.equals(_sorting, cmpr))
			return _ascending ?
					"ascending" : "descending";
		return "natural";	
	}
}

The implementation of Sortable.sort(Comparator, boolean) generally has to purge the cache, store the sorting direction and field, and then fire ListDataEvent.CONTENTS_CHANGED to reload the content.

The field to sort against has to be retrieved from the given comparator. If you specify "auto(fieldName)" to Listheader.setSort(String), then the comparator is an instance of FieldComparator, and you could retrieve the field's name from FieldComparator.getRawOrderBy().

If you'd like to use your own comparator, you have to carry the information in it and then retrieve it back when Sortable.sort(Comparator, boolean) is called.

Also notice that we cache the size to improve the performance, since ListModel.getSize() might be called multiple times.

For a real example, please refer to Small Talk: Handling sortable huge data using ZK and/or Small Talk: Handling huge data using ZK.

Version History

Version	Date	Content